Question
Does Gardener automatically revoke or rotate expired OIDC credentials in shoot kubeconfigs?
Kavi Atlas
0 reputation · 24 Nov 2022, 05:20 UTC
35.7K views1
Loading…
0 reputation · 24 Nov 2022, 05:20 UTC
I want to operate Gardener-managed clusters with least-privilege authentication: OIDC-issued, short-lived tokens mapped to narrowly scoped Kubernetes RBAC roles, with expired or stale credentials becoming unusable without manual cleanup.
My understanding is that Gardener's OIDC integration lets token claims map to RBAC bindings, and that kubeconfigs can carry credentials with an expiration time, after which the API server rejects requests. What I cannot confirm from the documentation is whether Gardener itself plays any active role in the credential lifecycle — for example, revoking tokens early, forcing rotation, or enforcing that issued credentials stay below a maximum lifetime or privilege level — or whether all of that is delegated entirely to the external identity provider and cluster admin processes.
I am also unsure whether there is any supported way to express per-cluster or per-user privilege ceilings centrally, rather than relying on each team to craft minimal RBAC bindings on their own. Assume a current Gardener release as of late 2026; if behavior differs by version, that distinction matters.
33275 reputation · 24 Nov 2022, 16:38 UTC
Gardener does not automatically revoke or rotate OIDC credentials that are embedded in shoot kubeconfigs. The only enforcement that occurs is the Kubernetes API server rejecting a request once the bearer token’s exp claim is in the past.
Gardener’s OIDC integration is a thin pass‑through: it embeds the client configuration (issuer, client ID, JWKS URL, etc.) in the kubeconfig so that the shoot API server can validate tokens. The platform deliberately leaves token lifecycle management – including revocation, early rotation, and maximum lifetime enforcement – to the external identity provider (IdP) and to the operator’s RBAC configuration.
gardenerspec.provider.oauth section of a Shoot resource contains no fields such as maxTokenLifetime or revocationEndpoint that would trigger early revocation or forced rotation.401 Unauthorized if the token is expired; there is no Gardener‑side pre‑emptive revocation.1. Verify the IdP’s token policies: confirm that the IdP is configured to issue tokens with a short lifespan (e.g., 15–30 min) and that it supports revocation endpoints if you need to invalidate a token before expiry.
2. Keep the shoot’s RBAC bindings as restrictive as possible – create dedicated ServiceAccounts or RBAC rules that match the exact scope of the token’s claims.
3. Optionally, monitor the shoot’s audit logs for 401 responses to confirm that expired tokens are being rejected by the API server.
Which identity provider (IdP) are you using to issue the OIDC tokens? Certain IdPs expose additional hooks (e.g., token revocation endpoints or short‑lived refresh tokens) that could influence how you manage credential lifecycles.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.