Notifications
Clear all
Topic starter
01/08/2026 10:50 pm
TL;DR: Headlamp login failed because the Kubernetes API server did not trust the same OIDC issuer as the dashboard, showing that authentication succeeds only when the browser, identity provider, app, API server, and RBAC all agree on trust and claims, according to Tailscale. In identity terms, the weak point is not the token itself but the trust chain that makes the token meaningful.
NHIMG editorial — based on content published by Tailscale: Fixing Headlamp OIDC login with Tailscale and tsidp
Questions worth separating out
Q: How should teams troubleshoot OIDC login failures in Kubernetes?
A: Start by separating authentication from authorization.
Q: Why do Kubernetes OIDC deployments fail even when the user can sign in?
A: Because the sign-in flow can complete before the cluster accepts the token.
Q: What do teams get wrong about RBAC with external identity providers?
A: They often treat RBAC as if it follows automatically from login.
Practitioner guidance
- Validate issuer trust on the API server Confirm that kube-apiserver trusts the exact OIDC issuer used by the application, not a near match or alias.
- Standardise claim-to-identity mappings Decide which token claims represent username and groups before wiring RBAC.
- Test RBAC separately from login success Use a known subject and a minimal role binding to prove that authentication and authorization both work.
What's in the full article
Tailscale's full blog post covers the configuration detail this analysis intentionally leaves for the source:
- The exact kube-apiserver OIDC flags used to trust the issuer and map claims.
- The step-by-step debugging path that shows why the login loop happened in the first place.
- The Kubernetes RBAC binding example that turns the OIDC identity into cluster-admin access.
- The author’s practical notes on when the API proxy approach becomes more awkward than OIDC.
👉 Read Tailscale's walkthrough of OIDC trust and Kubernetes RBAC →
Kubernetes OIDC trust chains: what IAM teams need to watch?
Explore further
01/08/2026 10:58 pm
OIDC login in Kubernetes is a trust-chain problem, not a single sign-in problem. The browser, dashboard, identity provider, API server, and RBAC layer all have to agree on identity before access becomes real. If any hop uses a different issuer or claim model, authentication can appear to work while authorization fails. Practitioners should evaluate Kubernetes login as an end-to-end identity path, not as a point integration.
A question worth separating out:
Q: What is the difference between authentication and authorization in Kubernetes login flows?
A: Authentication proves who the user is, while authorization decides what that identity can do. In Kubernetes, OIDC and the API server establish the identity, then RBAC turns that identity into permissions. If the trust chain is incomplete, authentication may succeed while authorization still fails.
👉 Read our full editorial: Kubernetes OIDC trust breaks when the API server does not
