SSO, SCIM, and Scoped RBAC: Team Access Without YAML Wrestling

A contractor starts Monday. They need read-only access to two namespaces in your staging cluster - payments and checkout - for a four-week engagement. Nothing more.

Without Radar, 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 an existing one. The security team asks how you'll revoke access when the contract ends. Nobody has a clean answer. The contractor spends their first three days reading documentation.

Why kubeconfig distribution 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 makes it awkward 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.
• Namespace 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.

The mental model

In Radar, access is scoped along three axes:

1. Which clusters a user can see (one, some, or all)
2. Which namespaces within those clusters (any, or an explicit list)
3. What operations they can perform (read, write, exec, port-forward, Helm ops, agent config)

Roles bundle combinations of those three axes. SSO groups map to roles. When you add someone to the platform-admins group in your IdP, they get the Admin role in Radar the next time they sign in. When you remove them, SCIM pushes the change and they lose access.

That's the whole model. The complexity that used to live in kubeconfig files and RoleBindings now lives in your identity provider, which is where your company already manages people.

SSO, the part you care about first

Radar supports SSO via Okta, Google Workspace, Entra ID, and any SAML 2.0 or OIDC provider that follows the spec. The Team plan includes Google Workspace and GitHub as identity sources plus full SAML/OIDC SSO with group mapping. SCIM 2.0 provisioning ships on the Enterprise plan.

Group mapping is where the ergonomics pay off. In the Radar dashboard, under Settings - Identity, you map IdP groups to roles:

# What you configure in the dashboard (shown here as config for clarity)
identityProvider: okta
domain: acme.okta.com
groupMappings:
  - group: platform-admins
    role: Admin
    scope: all-clusters
 
  - group: sre-oncall
    role: Operator
    scope:
      clusters: [prod-us-east, prod-eu-west]
      namespaces: all
 
  - group: dev-payments
    role: Viewer
    scope:
      clusters: [staging]
      namespaces: [payments, checkout]
 
  - group: staging-readers
    role: custom/readonly-scoped
    scope:
      clusters: [staging]
      namespaces: [payments, checkout]

Users authenticate through the IdP. Radar reads the group claims off the SAML assertion or OIDC token, walks the mapping table, and grants the union of matching roles. No local passwords. No service accounts to rotate. If your IdP goes down, nobody logs in, which is the correct behavior.

SCIM 2.0: the part that keeps you out of trouble

SSO handles login. It doesn't handle deprovisioning. A departing employee whose account is disabled in Okta can still hold a valid session, and whatever you have cached locally keeps working until the session expires.

SCIM 2.0 solves that. Your IdP pushes user and group membership changes to Radar as they happen. When someone leaves, their account in Radar is disabled within seconds of the IdP change. When they move from the sre-oncall group to platform-admins, their role updates automatically.

The SCIM endpoint looks like this:

https://scim.radarhq.io/v2/tenants/acme
Authorization: Bearer <scim-token>

You paste that URL and a token into the Okta/Entra provisioning panel, tick the box for user and group sync, and you're done. The sync is one-way (IdP to Radar); we don't push changes back. SCIM ships on the Enterprise plan; SAML/OIDC SSO itself is available on Team.

The four built-in roles

A couple of notes that matter in practice:

• Admin is the only role with organization-level powers. Adding/removing clusters, changing SSO config, rotating enrollment tokens, viewing billing - Admin only. Operator is deliberately capped there; you want your on-call engineers to be able to fix things without being able to delete the tenant.
• Viewer is genuinely read-only. No exec, no port-forward, no logs. If you want logs-on but exec-off, that's Custom.
• Custom lets you build a permission matrix. Pick operations (read, write, exec, port-forward, logs, Helm ops) times resource kinds (Pods, Deployments, Secrets, CRDs by group, etc.), then apply cluster and namespace scope on top. It's the escape hatch for the 10% of cases where the three built-ins don't fit.

The contractor, end to end

Monday morning. The contractor is starting. Here's the flow:

1. IT adds them to Okta. In the company's Okta tenant, they land in the default all-employees-contractor group plus a newly-created staging-readers group. The staging-readers group was mapped to a Radar Custom role called readonly-scoped six months ago and has been sitting there ready.
2. SCIM syncs within seconds. Okta pushes the user and the group membership to scim.radarhq.io. The user shows up in Radar with no clusters visible yet, because the all-employees-contractor group isn't mapped to anything. The staging-readers group gives them their actual scope.
3. The readonly-scoped role resolves to: cluster scope [staging], namespaces [payments, checkout], operations [read resources, read events, read Helm releases, read logs]. No exec. No port-forward. No write of any kind.
4. The contractor logs in. They click the Radar URL, hit the Okta login page they already know, and land in the dashboard. They see one cluster (staging), filtered to two namespaces. Everything else in the UI is hidden, not grayed out - if they can't see it, it doesn't appear.
5. Four weeks later, the contract ends. IT removes them from both Okta groups. SCIM pushes the change. Their next attempt to load Radar hits a 403. No kubeconfig to revoke. No ServiceAccount to clean up. No forgotten RoleBinding lurking in a namespace.

The total Radar work you did for this onboarding: zero. You did it once, six months ago, when you set up the readonly-scoped role and the group mapping. Everything since has been an IdP operation, run by IT.

Audit logs

Every tenant gets a per-action audit log (retention scales with tier: 7 days on Free, 30 days on Team, 1 year on Enterprise). What's in it:

• Authentication events (successful login, failed login, SSO assertion failures)
• Scope changes (role mapping edits, SCIM-driven group membership changes)
• Write operations through Radar (resource edits, Helm install/upgrade/rollback, exec session start/end, port-forward start/end)
• Agent configuration changes (enrollment, permission scope changes, deletion)

What's not in it: individual read clicks. If someone opens the Resources view and scrolls through Pods, we don't log that. There's too much noise and it's not useful for compliance. You can see that they authenticated and what they had permission to see; the exact scroll pattern isn't interesting.

Audit logs are retained for 7 days on Free, 30 days on Team, and 1 year on Enterprise. They're exportable via the REST API or shipped to S3 if you want them in your own SIEM.

What Radar's RBAC cannot do

Two honest limitations.

The agent's ServiceAccount is the ceiling. Radar's permissions are additive on top of what the in-cluster agent can do. If you deployed the agent with a read-only ClusterRole, granting a user "write" on Radar still doesn't let them write, because the agent itself can't. The Radar role says "this human is allowed to ask for writes"; whether the write actually lands depends on the agent's RBAC in that cluster. This is intentional. It means a compromised Radar account can never exceed the permissions you granted the agent, which is how defense-in-depth is supposed to work.

Time-bounded access isn't shipped yet. Occasionally you want "give this engineer Admin for the next four hours while we debug an incident, then revoke automatically." That's on the roadmap, not in the product today. For now, the workaround is the same one most teams use: add them to the group, remove them when you're done. It works; it's just manual.

The shape of it

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

Radar moves the model to where your identity already lives. You define roles once, map groups once, and the day-to-day churn of "who has access to what" becomes your IT team's existing workflow instead of a platform-engineering side quest.

If you want to try it against your own cluster and IdP, the Team plan includes Google Workspace, GitHub, and full SAML/OIDC SSO at a published price (no sales call required). SCIM 2.0 provisioning, advanced namespace-scoped RBAC, 1-year audit retention, and BYOC / on-prem deployment live on Enterprise.