Leader freshness (runtime-secret tracking + JWKS refresh) #9
No reviewers
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lab/authz-bridge!9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/leader-freshness"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #5
Implements issue #5 — Leader freshness (runtime-secret tracking + JWKS refresh).
What
OauthClientcontroller now.Watches(Secrets), fanning a Secret event out to the Clients that reference it (Builder.SecretReferencers). Add/delete of a referenced Secret rebuilds the Registry promptly — thesecretReadyflag and the CRDDegradedstatus flip without waiting for the next TTL refresh (the gap the code review of #3 deferred to this ticket). Unreferenced Secrets produce no requests (no over-triggering).RefreshLoopTTL (no CRD change) re-writes the managed Registry Secret with the fresh keys; a failed refresh (simulated IdP outage) keeps the last-good keys, with the App staying in the Registry and Available (ADR-0006; the per-replica 5xx side is untouched and leader-independent).Testing
Builderswapped per spec;RefreshLooprun as the same runnablecmd/main.goregisters.secretReady=false+ Degraded with no RefreshLoop and no CRD change (provably the watch); secret recreate →secretReady=true+ Available; JWKS v1→v2 on CRD change; JWKS v1→v2 on the TTL; outage → refresh attempts still happen, last-good (v1) keys kept, App Available.GOTOOLCHAIN=go1.26.0 make lint/make test: clean;go test -raceon the touched package: clean.No RBAC or generated-file changes (the
secretslist/watch verb was already granted by the pre-existing marker).