Repository navigation
oidc: expire cached JWKS based on cache headers - #143401
yashaggarwal85d wants to merge 1 commit into
Conversation
kubernetes-prow
Bot
added
release-note
kubernetes-prow
Bot
added
needs-triage
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
kubernetes-prow
Bot
added
needs-priority
|
Hi @yashaggarwal85d. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: yashaggarwal85d The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
kubernetes-prow
Bot
added
area/apiserver
sig/api-machinery
What type of PR is this?
/kind feature
/sig auth
What this PR does / why we need it:
go-oidc's RemoteKeySet keeps keys forever and only refetches when it sees an unknown kid, so a key the provider has removed is still trusted as long as tokens use its kid. This wraps the key set and starts over with a fresh one once the JWKS response's Cache-Control max-age (or Expires) has passed. Responses without cache headers behave like before. Short lifetimes are clamped to 1 minute so we stay under the existing JWKS rate limit.
Which issue(s) this PR is related to:
Fixes #142100
Special notes for your reviewer:
Only covers the JWKS metrics path (beta, on by default), since that's where we build the RemoteKeySet ourselves. After expiry the next request waits on the refetch, and if that fetch fails the token is rejected rather than falling back to the stale keys. Open to keeping stale keys on fetch errors if that's preferred.
Does this PR introduce a user-facing change?
AI usage disclosure:
YES. This PR was written in part with the assistance of generative AI (it helped draft the key set wrapper and tests). I reviewed and tested the change and I'm responsible for it.