Repository navigation
feat: wire AUTOMATION_KV_SECRET through the automation chart - #1327
Closed
jpshackelford wants to merge 1 commit into
Closed
jpshackelford wants to merge 1 commit into
jpshackelford wants to merge 1 commit into
Conversation
The automation KV store (openhands/automation/kv_router.py) requires AUTOMATION_KV_SECRET to sign per-run JWT KV tokens and encrypt stored values at rest. The chart previously threaded AUTOMATION_SERVICE_KEY, AUTOMATION_WEBHOOK_SECRET, and AUTOMATION_GIT_SYNC_SECRET but had no provision for AUTOMATION_KV_SECRET, so every KV endpoint returns 503 "KV store not configured" on Replicated/OHE and SaaS installs. User- authenticated KV access (OpenHands/automation#445) is also blocked by this on the beta instance. Mirror the AUTOMATION_WEBHOOK_SECRET pattern end to end: new K8s Secret in openhands-secrets, kvSecretFromSecret + env entry in the automation subchart, hidden auto-generated Replicated ConfigOption piped through secrets.yaml and secretsChecksum, support-bundle presence check. AUTOMATION_KV_SECRET is internal signing material; the ConfigOption is hidden: true (same posture as service_key/webhook_secret/git_sync_secret) and never surfaces in the admin console. Chart bumps: openhands 0.74.0 -> 0.74.1, openhands-secrets 0.1.24 -> 0.1.25. Co-authored-by: openhands <openhands@all-hands.dev>
3 tasks done
1 of 3 tasks
Member
Author
|
Closing in favor of #1326 (@hieptl got there ~8h earlier; same problem, same core fix). The useful bits from this PR — Chart.yaml bumps, the This comment was posted by an AI agent (OpenHands) on behalf of @jpshackelford. |
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
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.
Why
The automation KV store (
kv_router.py) needsAUTOMATION_KV_SECRETto sign per-run JWT KV tokens and encrypt stored values at rest. Every other automation secret is threaded through this chart (AUTOMATION_SERVICE_KEY,AUTOMATION_WEBHOOK_SECRET,AUTOMATION_GIT_SYNC_SECRET) butAUTOMATION_KV_SECRETwas never wired. As a result:GET /api/automation/v1/kvreturns HTTP 503 "KV store not configured (missing AUTOMATION_KV_SECRET)" on every install produced by this chart (OHE Replicated and SaaS). Verified on the OHE Beta instance just now, running automation 1.15.1 which already contains the user-auth KV code from feat: add user-authenticated KV access automation#445.AUTOMATION_KV_TOKENenv in a run) silently has no backing store.The only existing production code that sets
AUTOMATION_KV_SECRETis the single-containerOpenHands/OpenHandsdocker/entrypoint.sh(derived fromEFFECTIVE_SESSION_KEY), which doesn't apply here because the automation service runs as its own pod from this chart.Design note on hiding
AUTOMATION_KV_SECRETis internal signing material only — automation scripts never see or supply it, and admins have no reason to tune or rotate it from the UI. The new ConfigOption useshidden: true+{{repl RandomString 32}}, so it's generated once per install, stable across upgrades (unless deliberately rotated through the API), and never shown in the Replicated admin console. Same posture asautomation_service_key/automation_webhook_secret/automation_git_sync_secret.What changed
Full mirror of the
AUTOMATION_WEBHOOK_SECRETwiring, scoped to the layers that actually matter for KV:charts/openhands-secrets/templates/automation-kv-secret.yaml— K8sSecretnamedautomation-kv-secret, keykv-secret, gated on.Values.automation.enabled.values.yaml: newconfig.automation_kv_secret: ""stub.Chart.yaml:0.1.24→0.1.25.charts/openhands/charts/automation/values.yaml: newkvSecretFromSecret: { name: automation-kv-secret, key: kv-secret }.templates/_env.yaml: newAUTOMATION_KV_SECRETenv entry,valueFrom.secretKeyRef(same shape asAUTOMATION_WEBHOOK_SECRET, notoptional: true— if the secret is missing the pod won't start, which is what we want becauseopenhands-secretsalways creates it alongside the automation deployment).charts/openhands/Chart.yaml:0.74.0→0.74.1(subchart values changed).templates/troubleshoot/support-bundle.yaml: addedAUTOMATION_KV_SECRETtoSECRET_PRESENCEso "is KV configured on this install?" is a one-line answer in a bundle.replicated/config.yaml: newautomation_kv_secretConfigOption,type: password,hidden: true,value: '{{repl RandomString 32}}'.secrets.yaml: mapped intoopenhands-secrets.config.automation_kv_secret.openhands.yaml: added to thesecretsChecksumsha256 so rotating the secret rolls the pod. Our new field lands at position 32, safely inside the hashed range — see the sidebar below.Not changed (deliberately):
_env.yaml— unlikeAUTOMATION_WEBHOOK_SECRET(which the main openhands pod needs so it can sign events sent to the automation service), the main pod never signs KV requests. Only the automation pod needs this env.Validation
helm lint charts/openhands-secrets— passes (one pre-existing icon INFO).helm lint charts/openhands --set automation.enabled=true …— passes.helm template charts/openhands-secrets --set automation.enabled=true --set config.automation_kv_secret=test-value— renders the new Secret with the decoded valuetest-value.helm template charts/openhands --set automation.enabled=true …— theautomationandautomation-eventsdeployments both include the newAUTOMATION_KV_SECRETenv entry, right afterAUTOMATION_WEBHOOK_SECRET.python3 scripts/check_secret_checksum.py—OK: all 46 password config fields are covered by secretsChecksum.(was 45).python3 -m pytest scripts/test_openhands_secrets_template.py scripts/test_troubleshoot_secrets_template.py -q— 9 passed.How this fixes Beta
Beta currently serves automation 1.15.1 (post-OpenHands/automation#445) but 503s on
GET /api/automation/v1/kvbecause the KV secret is unset. After this chart ships and the KOTS config renders the new ConfigOption, theautomation-kv-secretK8s Secret will be auto-populated with a 32-char random value, the automation pod will boot withAUTOMATION_KV_SECRETset, and KV endpoints will start returning 401/400/200 instead of 503 (both the JWT path and the new user-auth path in #445).Helm Chart Checklist
helm templateproduces a new K8s Secret and new env entry; no changes to existing resources.values.yamlconfigurations — the newkvSecretFromSecretvalue defaults to a non-nil map so the template always renders the env block, andconfig.automation_kv_secretdefaults to""so pre-existing installs continue to render the Secret (empty value, same as the sibling secrets when unset in a non-Replicated install).Sidebar: pre-existing
secretsChecksumarity bug (fixed in #1328)Inserting
automation_kv_secretat position 32 of thesecretsChecksumarg list shifts everything after it down by one slot. Theprintfformat only has 45%splaceholders, so the trailing args already fell off the hash — this PR pushesexternal_postgres_passwordoff the edge too. No impact onAUTOMATION_KV_SECRETitself (position 32 is inside the hashed range), but worth tracking.Full accounting and fix in #1328. Either PR can land first.
This PR was created by an AI agent (OpenHands) on behalf of the user.