--- title: SSO-Backed kubectl Access Across Many Clusters | daily.dev description: A platform engineering walkthrough explains how Kubernetes API servers authenticate kubectl requests via OIDC tokens and authorize them separately via RBAC,... canonical: https://daily.dev/posts/sso-backed-kubectl-access-across-many-clusters-1myvsp9ee twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: SSO-Backed kubectl Access Across Many Clusters | daily.dev og:description: A platform engineering walkthrough explains how Kubernetes API servers authenticate kubectl requests via OIDC tokens and authorize them separately via RBAC,... og:url: https://daily.dev/posts/sso-backed-kubectl-access-across-many-clusters-1myvsp9ee og:image: https://api.daily.dev/og/posts/1MyvSp9Ee.png og:image:alt: SSO-Backed kubectl Access Across Many Clusters og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # SSO-Backed kubectl Access Across Many Clusters **[Teleport](https://daily.dev/sources/teleport)** · 23 min read · 0 upvotes · 0 comments ## Summary A platform engineering walkthrough explains how Kubernetes API servers authenticate kubectl requests via OIDC tokens and authorize them separately via RBAC, using a company SSO setup across development, staging, and production clusters. It demonstrates with Dex and kubelogin that when all clusters share one OIDC audience, a single cached token authenticates everywhere, meaning RBAC alone (not authentication) stops a user from acting in production, and a stolen token could authenticate to every cluster. It then shows how configuring separate audiences (kubectl-development, kubectl-nonproduction, kubectl-production) in each API server's AuthenticationConfiguration makes production reject tokens minted for other environments before RBAC even runs, and covers kubeconfig merge pitfalls where duplicate user entry names silently cause a context to request the wrong audience. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### why does kubectl auth show a Forbidden error with my username instead of Unauthorized when I lack permissions in a namespace Forbidden means the API server already accepted the token and identified the user during authentication, then RBAC denied the specific action during authorization. Unauthorized, by contrast, means the token itself was rejected before any username was assigned, typically because its aud claim did not match an audience the API server trusts. The two errors show which Kubernetes stage rejected the request. _daily.dev helps engineers debugging kubectl auth errors find context on Kubernetes authentication versus RBAC behavior._ ### how do I stop a copied kubectl token from authenticating to my production Kubernetes cluster Give production's API server an OIDC audience that other clusters do not request, configured under jwt.issuer.audiences in its AuthenticationConfiguration with audienceMatchPolicy set to MatchAny. A token minted with a different client ID, such as kubectl-development, fails authentication with Unauthorized before it ever reaches RBAC, so a leaked non-production token cannot be used against production. _teams hardening kubectl SSO across clusters track approaches like this via daily.dev._ ### why did merging two kubeconfig files silently break my staging kubectl login Kubeconfig merging keeps the first value for any duplicate map key, so if two files both name their exec user entry 'oidc', the merge keeps only the first file's user and drops the second. A staging context pointed at that surviving user then requests the wrong OIDC client ID, causing staging to reject the token as Unauthorized even though the context name looks correct. Giving each user entry a unique name fixes it. _daily.dev surfaces practical kubeconfig gotchas for engineers wiring up multi-cluster kubectl access._ ## Similar posts on daily.dev - [How to Authenticate Users in Kubernetes: x509 Certificates, OIDC, and Cloud Identity](https://daily.dev/posts/how-to-authenticate-users-in-kubernetes-x509-certificates-oidc-and-cloud-identity-hxgchmocb) · freeCodeCamp · 1 upvotes · 0 comments - [Kubernetes access via an identity provider: Public client, not confidential](https://daily.dev/posts/kubernetes-access-via-an-identity-provider-public-client-not-confidential-j18kxxmud) · CNCF · 0 upvotes · 0 comments - [Kubernetes User Authentication with Client Certificates and RBAC](https://daily.dev/posts/kubernetes-user-authentication-with-client-certificates-and-rbac-qvbi0zovt) · Towards Dev · 3 upvotes · 0 comments - [Headlamp OIDC login with Tailscale, tsidp, and Kubernetes RBAC](https://daily.dev/posts/headlamp-oidc-login-with-tailscale-tsidp-and-kubernetes-rbac-8hhultrep) · Tailscale · 2 upvotes · 0 comments - [Medium](https://daily.dev/posts/medium-ppeofcz2x) · Medium · 0 upvotes · 0 comments --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#authentication](https://daily.dev/tags/authentication) [View this post on daily.dev](https://daily.dev/posts/sso-backed-kubectl-access-across-many-clusters-1myvsp9ee) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"SSO-Backed kubectl Access Across Many Clusters","url":"https://daily.dev/posts/sso-backed-kubectl-access-across-many-clusters-1myvsp9ee","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/sso-backed-kubectl-access-across-many-clusters-1myvsp9ee"},"datePublished":"2026-10-02T13:06:52.299Z","dateModified":"2026-10-02T13:07:47.503Z","description":"A platform engineering walkthrough explains how Kubernetes API servers authenticate kubectl requests via OIDC tokens and authorize them separately via RBAC,...","image":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","thumbnailUrl":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","isAccessibleForFree":true,"articleSection":"Teleport","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Teleport","logo":"https://media.daily.dev/image/upload/s--Dw-Bbw6O--/c_limit,w_256/f_auto,q_auto/v1787487494/logos/teleport?_a=BAMAMicg0","url":"https://daily.dev/sources/teleport"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/sso-backed-kubectl-access-across-many-clusters-1myvsp9ee","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,authentication","timeRequired":"PT23M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Teleport","item":"https://daily.dev/sources/teleport"},{"@type":"ListItem","position":3,"name":"SSO-Backed kubectl Access Across Many Clusters"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/sso-backed-kubectl-access-across-many-clusters-1myvsp9ee#faq","mainEntity":[{"@type":"Question","name":"why does kubectl auth show a Forbidden error with my username instead of Unauthorized when I lack permissions in a namespace","acceptedAnswer":{"@type":"Answer","text":"Forbidden means the API server already accepted the token and identified the user during authentication, then RBAC denied the specific action during authorization. Unauthorized, by contrast, means the token itself was rejected before any username was assigned, typically because its aud claim did not match an audience the API server trusts. The two errors show which Kubernetes stage rejected the request. daily.dev helps engineers debugging kubectl auth errors find context on Kubernetes authentication versus RBAC behavior."}},{"@type":"Question","name":"how do I stop a copied kubectl token from authenticating to my production Kubernetes cluster","acceptedAnswer":{"@type":"Answer","text":"Give production's API server an OIDC audience that other clusters do not request, configured under jwt.issuer.audiences in its AuthenticationConfiguration with audienceMatchPolicy set to MatchAny. A token minted with a different client ID, such as kubectl-development, fails authentication with Unauthorized before it ever reaches RBAC, so a leaked non-production token cannot be used against production. teams hardening kubectl SSO across clusters track approaches like this via daily.dev."}},{"@type":"Question","name":"why did merging two kubeconfig files silently break my staging kubectl login","acceptedAnswer":{"@type":"Answer","text":"Kubeconfig merging keeps the first value for any duplicate map key, so if two files both name their exec user entry 'oidc', the merge keeps only the first file's user and drops the second. A staging context pointed at that surviving user then requests the wrong OIDC client ID, causing staging to reject the token as Unauthorized even though the context name looks correct. Giving each user entry a unique name fixes it. daily.dev surfaces practical kubeconfig gotchas for engineers wiring up multi-cluster kubectl access."}}]} ```