fix(vault-seed): seed OIDC client/cookie secrets from the SOPS bootstrap source#1989
Merged
Merged
Conversation
…rap source
dex's staticClients and oauth2-proxy consume ${dex_client_secret} /
${flux_web_client_secret} / ${oauth2_proxy_cookie_secret} straight from
the variables-cluster SOPS secret via Flux post-build substitution —
while headlamp, actual-budget and the OpenBao OIDC auth method read the
SAME logical secrets back from the vault paths, which were seeded by an
INDEPENDENT Password generator. Two unrelated random values for one
client secret: dex rejects every vault-sourced consumer (verified live:
sha256(variables-cluster.dex_client_secret) != sha256(vault-synced
dex-client-secret)).
Replace the three generator-based pushes with seed-* PushSecrets that
mirror the variables-cluster keys into the same vault paths (hourly,
like every other SOPS-sourced seed), and drop their now-unused Password
generators and cache ExternalSecrets. The truly generated secrets
(umami / fleetdm) keep the cache pattern.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
ℹ️ The 🧪 System Test failure here is the pre-existing repo-wide CI breakage (OpenBao service-registration label updates rejected with HTTP 422 → |
This was referenced Jun 10, 2026
![botantler[bot]](https://avatars.githubusercontent.com/in/1025824?s=60&v=4){kind=small}
Contributor
|
🎉 This PR is included in version 1.49.5 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.
Root cause
The same logical secret has two unrelated values:
${dex_client_secret}/${flux_web_client_secret}/${oauth2_proxy_cookie_secret}directly from thevariables-clusterSOPS secret via Flux post-build substitutioninfrastructure/oidc/{dex,flux-web,oauth2-proxy}— which were seeded by an independent Password generatorVerified live on prod just now:
sha256(variables-cluster.dex_client_secret) ≠ sha256(vault-synced dex-client-secret)→ dex rejects every vault-sourced consumer. This predates the 2026-06-10 incident (the generator never knew about the SOPS value), and the post-incident regeneration (#1981) re-rolled the dice.Fix
Replace the three generator-based pushes with
seed-*PushSecrets that mirror thevariables-clusterkeys into the same vault paths (hourly, like every other SOPS-sourced seed). Drop the now-unused Password generators and cache ExternalSecrets (Flux prunes them; the cache Secrets are GC'd with their owners). The truly generated secrets (umami / fleetdm) keep the #1981 cache pattern — they have no external system of record.After merge I'll re-run the vault-config Job once so the OpenBao OIDC auth method picks up the corrected
oidc_client_secret.Validation
kubectl kustomizelocal + prod ✅🤖 Generated with Claude Code