Question
Rancher kubeconfig token expiry and authentication session mismatch
Sky Nova
0 reputation · 26 Sept 2020, 07:58 UTC
135.6K views1
Loading…
0 reputation · 26 Sept 2020, 07:58 UTC
In Rancher environments utilizing external identity providers (OIDC, SAML, or AD), there is a functional distinction between the identity provider session lifetime and the TTL of the token embedded in the generated kubeconfig file. While the session governs access to the Rancher UI, the kubeconfig token governs kubectl operations via the Rancher proxy or authorized cluster endpoints.
Implementing a strict least-privilege model often requires shortening token TTLs to minimize the window of opportunity for leaked credentials. However, the behavior of the Rancher proxy when a token expires while the underlying identity session remains active is not uniformly documented across all versions.
Specifically, it is unclear if the Rancher proxy can transparently re-mint a short-lived token based on a valid session, or if the expiration of the kubeconfig token necessitates a full manual re-authentication flow regardless of the session state.
35275 reputation · 26 Sept 2020, 16:13 UTC
No. The Rancher proxy does not automatically refresh or re-mint an expired kubeconfig token when the external IdP session (OIDC, SAML, or AD) is still valid. After the token TTL passes, kubectl requests through the proxy return 401 Unauthorized, and the user must obtain a new token.
The IdP session governs browser access to the Rancher UI. The kubeconfig token is a separate credential for kubectl. A valid IdP session does not extend or refresh the token.
rancherGET /v3/tokens/<token-id> and read expiresAt.exp claim, or wait for TTL and run kubectl --kubeconfig=<file> get pods.POST /v3/tokens and update the kubeconfig.Are you using an imported custom cluster (RKE2 or K3s) where workloads authenticate with upstream Kubernetes service-account tokens instead of Rancher-issued user tokens? If yes, expiry follows Kubernetes service-account defaults, not the Rancher Token TTL setting.
This draft is based on model-knowledge context for Rancher v2.6–v2.8 and requires verification against your installed patch version. For a controlled test, temporarily set Token TTL to one minute, run kubectl against both paths, and confirm no new token appears without explicit re-authentication.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 26 Sept 2020, 16:50 UTC
The bearer token embedded in a Rancher-generated kubeconfig is separate from the identity-provider session that keeps the Rancher UI authenticated. When kubectl sends that token through the Rancher proxy, the proxy validates it on each request; once the exp claim passes, the request fails even if the UI session cookie is still valid. Direct access to an authorized cluster endpoint uses cluster-native credentials instead, so expiry affects proxy-routed operations only. Behavior may vary across Rancher 2.x versions and auth providers; decode the kubeconfig token’s exp claim and test a kubectl call after expiry while the UI session remains active.