SSO and RBAC Without Passing Around Kubeconfigs

A contractor starts Monday. They need read-only access to your staging cluster for a four-week engagement. Nothing more.

Without something better than kubeconfigs, this is a ticket that bounces between you, IT, and security for a week. Someone generates a kubeconfig. Someone else argues about whether to create a dedicated ServiceAccount or reuse one. Security asks how you'll revoke when the contract ends. Nobody has a clean answer. The contractor spends their first three days reading docs.

Radar Cloud's access model is built around a different split:

• Cloud authenticates the human and decides which org they belong to.
• The in-cluster Radar pod impersonates that human's Cloud role against the Kubernetes API.
• Kubernetes RBAC decides what the request can actually do.

No shared kubeconfig to pass around.

Why kubeconfig falls apart at team scale

Kubeconfig wasn't designed for this. It was designed for an operator with a laptop talking to a cluster. Everything that's awkward about it for teams is a consequence of using it past that point.

• Client certificates are long-lived by default. Once minted, they sit in someone's ~/.kube/config until they expire. Revoking a leaked cert means rotating the cluster CA, which nobody does.
• Scoping is a RoleBinding exercise. You can do it, but you end up with a matrix of ServiceAccounts, Roles, and RoleBindings across clusters. For a fleet of ten clusters, that's ten places to update when someone changes teams.
• No native link to your IdP. Your company already has Okta or Entra ID. Kubeconfig doesn't know anything about it. You can wire OIDC into the API server, but that's per-cluster plumbing, and it still doesn't give you group-to-role mapping for free.
• Audit trails are thin. API server audit logs tell you that kubernetes-admin did a thing. They don't tell you which human that was, unless you've done the OIDC work above.

This isn't a criticism of Kubernetes. Kubeconfig is fine for what it is. It's just that "onboard a contractor in an hour with scoped, revocable, auditable access" isn't what it's for.

How Radar Cloud handles it

Two ideas, both boring on purpose.

SSO is the front door. Radar Cloud uses WorkOS as its identity-provider abstraction. SAML and OIDC, including Okta, Entra ID, Google Workspace, OneLogin, and any spec-compliant SAML / OIDC provider. The setup is self-serve: an owner clicks Set up SSO in the dashboard, lands in the WorkOS Admin Portal, configures the IdP there, and saves. We don't sit between you and your IdP for setup. SSO is available on every plan, including Free - it's not an "enterprise upsell" gate.

Cloud roles map to standard Kubernetes RBAC via impersonation. This is the part that surprised some early users in a good way. Radar Cloud doesn't invent a parallel permission system. It maps each user's Cloud role (owner, member, viewer) to a Kubernetes group and lets the in-cluster Radar pod impersonate the user when it talks to the API server.

The Helm chart ships three default ClusterRoleBindings out of the box:

Standard K8s built-in ClusterRoles. Nothing custom. If you trust view, you trust Viewer. If edit is too broad for your members, swap the binding to a custom ClusterRole - it's two lines in values.yaml.

cloud:
  defaultRbac:
    create: true                     # emit the default bindings
    member: true                     # keep the cloud:member binding
    memberClusterRole: my-edit       # but map it to your custom ClusterRole

To disable a tier entirely (e.g. owners only, no members or viewers), set the flag to false:

cloud:
  defaultRbac:
    member: false
    viewer: false

What the request actually looks like

When a Cloud user clicks into a cluster, the control plane strips inbound X-Forwarded-* headers (so they can't be spoofed) and injects:

X-Forwarded-User: user_01HF...
X-Forwarded-Groups: cloud:viewer,cloud:org:org_01H...,cloud:user:user_01HF...

The in-cluster Radar pod runs in proxy auth mode, sees those headers, and impersonates the user against the K8s API. Whatever permissions you've granted the cloud:viewer group (or that specific user via the cloud:user:... group) is exactly what they can do. K8s does the gatekeeping. We don't.

If you need finer control - say, "Alice can edit Deployments only in the apps-prod namespace" - you bind directly to her per-user group:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alice-apps-edit
  namespace: apps-prod
subjects:
  - kind: Group
    name: cloud:user:user_01HF...
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

That's a regular K8s RoleBinding. kubectl get rolebindings works, your existing RBAC tooling works, audit policies on the apiserver capture impersonated calls with the user ID and groups intact.

The blast radius is also easy to reason about: the Radar pod's ServiceAccount is the upper bound, and Kubernetes impersonation narrows each request to the user or role that made it.

The contractor, end to end

Monday morning:

1. IT adds the contractor to your Okta tenant. They get JIT-provisioned into your Radar org on first SSO sign-in - that's WorkOS doing the work.
2. Owner sets their role to Viewer. That's one click in Settings → Members, or automatic via domain auto-join + default role.
3. The contractor signs in. They land on the cluster list, see the staging cluster you've granted them access to, and can read - resources, topology, events, audit findings, Helm releases. They cannot exec, cannot edit, cannot delete. K8s says no, because cloud:viewer is bound to view.
4. Four weeks later, IT removes them from Okta. Their next sign-in attempt 403s. Existing sessions die at cookie expiry; if you need an immediate cut, Settings → Members → Remove kills the server-side session right away.

Total Radar work for this onboarding: zero, after the initial setup. Everything else is an IdP operation IT already knows how to run.

SCIM and time-bounded access

Two things worth being explicit on.

SCIM 2.0 directory sync ships on Enterprise. JIT provisioning works on every plan - the first SSO sign-in creates the Cloud user and adds them to the org if domain auto-join is configured. For teams that need directory-driven user and group lifecycle from their IdP (often for compliance or procurement), SCIM is the upgrade path.

Time-bounded access ("Admin for the next four hours, then auto-revert") isn't shipped natively yet. The workaround is the IdP one - add to a group, remove when done. It works. It's just not as clean as a one-click ephemeral grant. On the roadmap.

Audit

Every authentication event, scope change, and write operation lands in the Cloud audit log. Retention scales with plan: 7 days on Free, 30 days on Team, 1 year on Enterprise. K8s audit policies capture the impersonated calls separately, so you can correlate "user X did Y in Cloud" against "user X impersonation hit endpoint Z in the apiserver" if you need full provenance.

What's not in the audit log: every read click. We log write operations, scope changes, sign-ins, and SSO config changes. We don't log "Alice opened the Pods view and scrolled."

The shape of it

Onboarding a teammate to a Kubernetes cluster should be an IdP operation, not a kubeconfig-distribution project. The reason it usually isn't is that most teams layered their access tooling on top of ~/.kube/config and never went back to reconsider.

Radar Cloud moves the decision to where your identity already lives - your IdP - and lets standard K8s RBAC do the gatekeeping in the cluster, not a parallel permission system in the dashboard. Less novel infrastructure, fewer places for things to drift, and a cleaner answer when someone asks "who has access to prod, and how do you revoke it?"

If you want to try it, the Free tier covers up to three clusters and includes SSO. Set it up in Settings → Organization → SSO - the WorkOS portal walks you through your IdP from there.