chore: move Kiali login-token signing key to AWS Secrets Manager via ESO#51
Merged
Conversation
The kiali-server Helm chart rendered a random 32-byte login_token.signing_key literal into the committed kiali.yaml. Reference it as secret:kiali:signing-key instead, so the chart mounts the key from the ESO-managed Secret "kiali" (ASM usgov-coderdemo/observability/kiali-oauth, key signing-key) and no secret value is committed to git. setup-kiali-oidc.py now stores and preserves the signing key alongside oidc-secret. Rotated live in istio-system and verified: Kiali is healthy on the openid authorization-code flow with the key sourced from ESO. Generated by Coder Agents.
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
1 participant
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
The
kiali-serverHelm chart renders a random 32-bytelogin_token.signing_keyliteral into the committeddeploy/istio/observability/kiali.yaml. That value signs Kiali's session tokens, so it is a real secret and should not live in git.This change references it as
login_token.signing_key: "secret:kiali:signing-key". Chart 2.26.0 detects that pattern and mounts thesigning-keyentry of the ESO-managed Secretkialiat/kiali-override-secrets/login-token-signing-key/value.txt, which overrides the placeholder reference string in the ConfigMap. No secret value is rendered into the repo.Changes
kiali-server-values.yaml: addlogin_token.signing_key: "secret:kiali:signing-key"and document the rationale.kiali.yaml: regenerated (helm template2.26.0). The literal key is gone; the ConfigMap now holds the reference string and the Deployment gains the override-secret volume/mount.externalsecret-kiali-oauth.yaml: the existingdataFrom.extractalready syncs every ASM JSON key, so thekialiSecret now also carriessigning-key; comment updated.setup-kiali-oidc.py: stores a 32-bytesigning-keyin ASMusgov-coderdemo/observability/kiali-oauthalongsideoidc-secret, preserving an existing valid key across re-runs so it is not rotated unnecessarily.Live rotation + verification
A new 32-byte key was written to ASM, ESO synced it into the
kialiSecret, and the regenerated manifest was applied with a Kiali rollout inistio-system. Verified after cutover:Running, ready, 0 restarts; signing-key file mounted (32 bytes).Using authentication strategy [openid], with no "signing key is not 16, 24 nor 32 bytes" downgrade warning (so the authorization-code flow is intact).GET /kiali/api/auth/inforeturns HTTP 200 withstrategy=openidand a validauthorizationEndpoint.The 16/24/32-byte length is required to keep Kiali on the OIDC authorization-code flow; a different length silently downgrades to the implicit flow.
Context: secret-hygiene remediation
This is part of the secret-hygiene pass. The repo-wide secret scan (added in #49) surfaced this committed Kiali signing key, which the earlier manual review had missed. A full sweep found no other inline secrets. Companion work: #50 (rotate + ESO-migrate the synthetic datastore-mcp Postgres credentials) and #49 (gitleaks pre-commit + CI guardrails). Git history purge was intentionally declined; rotation is the remediation.
Generated by Coder Agents, on behalf of @ausbru87.