fix(shield): fail fast when Rapid Response is enabled without a password#2691
Merged
Conversation
When features.respond.rapid_response.enabled is true but no password is
provided (neither features.respond.rapid_response.password nor
password_existing_secret), the chart previously rendered a Host Shield
Secret with an empty password. At runtime the rapid-response subprocess
crash-loops ("Flag \"password\" cannot be empty"), which makes the agent
report UNhealthy on /healthz so the Host Shield pod never becomes Ready
(stuck 0/1) -- even though the agent authenticates and sends metrics fine.
Fail the render instead, with an actionable message pointing at the two
ways to supply the credential. The guard lives in the same block that
generates the self-managed Secret, so it does not affect deployments that
reference a pre-created Secret via password_existing_secret.
Add unit tests covering both the missing-password and empty-password
cases, and bump the chart version.
mateobur
previously approved these changes
Jul 20, 2026
aroberts87
reviewed
Jul 21, 2026
aroberts87
left a comment
aroberts87
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for the PR, @airadier! Just a request to make the error string a bit more concise. LGTM once that change is made and the linting error gets cleared up.
Apply review suggestions to drop the trailing crash-loop sentence.
mateobur
previously approved these changes
Jul 21, 2026
main advanced to 1.46.5; bump to satisfy ct lint version-bump check.
mateobur
approved these changes
Jul 21, 2026
airadier
enabled auto-merge (squash)
July 21, 2026 15:27
aroberts87
approved these changes
Jul 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
When
features.respond.rapid_response.enabled: truebut no password is supplied (neitherfeatures.respond.rapid_response.passwordnorpassword_existing_secret), the chart renders a Host ShieldSecretwith an empty password. At runtime the rapid-response subprocess crash-loops:That unhealthy subprocess makes the agent report UNhealthy on
/healthz, so the Host Shield pod never becomes Ready (stuck0/1) — even though the agent authenticates and sends metrics fine. The failure is silent athelm installtime and only surfaces as a confusing not-Ready pod later.This adds a fail-fast guard in
templates/host/secrets.yaml, in the same block that generates the self-managed Secret, so:password_existing_secretare unaffected (the guard is inside thenot existing_secretbranch);helm template/helm installnow surface the misconfiguration up front instead of at runtime.Error message emitted:
Checklist
shield1.46.4 → 1.46.5)password/password_existing_secretalready exist)tests/host/secrets_test.yaml: missing-password and empty-password cases)