Skip to main content
Most teams already express “who can touch what” as groups in their identity provider (Entra, Okta, a generic OIDC / SAML IdP). Radar lets you reuse those exact groups to grant Kubernetes access - without re-authoring per-user bindings - on hosted Cloud and on a self-managed hub alike. Your IdP group memberships flow through sign-in and land in your cluster as radar:idp:<group-id> subjects, which you bind in your own Kubernetes RBAC exactly as you already bind your raw IdP groups. This page covers the end-to-end process. It builds on two pages you should read first:
  • SSO - group passthrough rides on top of a working SSO connection.
  • RBAC under Cloud mode - the binding recipes and governance models you’ll use in the final step.
Hosted Cloud and self-managed enable this differently. The subject vocabulary, the binding recipes and the troubleshooting below apply to both, but the setup steps on this page - the SSO setup portal and its attribute mappings - are hosted-Cloud machinery.On a self-managed hub passthrough is on by default and configured through Helm values instead - there is no portal step and nothing to switch on. See Self-Managed authentication → IdP group passthrough, then come back here for the binding recipes.

​
The identity Radar presents to your cluster

When a signed-in user drives a cluster request, the control plane does not forward the user’s raw IdP identity (their IdP email, their real IdP group names) to your cluster. It asserts a Radar-scoped, prefixed identity that you opt into through your own RBAC. On each request the control plane injects a groups header containing:
radar:* is the vocabulary to bind against. Use it for role, organization, user, email, and IdP group subjects.
Why a prefixed identity instead of your raw one? You likely have many existing Kubernetes RoleBindings written over years and keyed to your real IdP identity - some for kubectl, some for CI, some binding a platform admin to cluster-admin. If Radar asserted the raw identity, every one of those bindings would become reachable the moment someone signs into Radar. With the prefixed identity, only the bindings you explicitly grant to a radar:* subject are reachable. You can grep radar: across your RBAC and see the complete, auditable list of what Radar can touch. This is channel isolation - a smaller, deliberately scoped, auditable door - not a blast-radius cap on a control-plane compromise. State it that way to a security team: the value is that Radar can reach only what you bound to radar:*, and that set is greppable and reviewable.

​
The process end to end

  1. Connect SSO. Group passthrough requires a working SSO connection (SSO).
  2. Emit a stable group claim from your IdP so memberships arrive as radar:idp:<group-id>.
  3. Verify the groups arrive as stable IDs before you write any RBAC.
  4. Bind radar:idp:<group-id> in your Kubernetes RBAC, optionally disabling the default role tiers for scoped users.

​
1. Connect SSO

Follow SSO end to end. Group passthrough is enabled per connection as part of SSO onboarding; if groups don’t arrive after you complete the steps below, contact support to confirm passthrough is active on your connection.

​
2. Emit a stable group claim from your IdP

This is two actions: your IdP has to emit a groups claim, and the SSO setup has to map that claim into Radar. Both are required - a claim your IdP emits but no one maps never reaches your cluster.
  1. In your IdP, add a groups claim to the assertion / token it sends (see the provider examples below).
  2. In the SSO setup portal (the “Open SSO setup” link from your SSO connection), open Attribute mappings → Edit attribute mappings, find the groups attribute, and set its IdP field name to the exact attribute name your IdP emits the claim under. Save.
The groups mapping is optional in the setup portal - unlike email / name it has no “Required” badge, so it is easy to skip, and if you skip it the field stays unset and no groups ever flow (with no error anywhere). If group access “just doesn’t work,” this unset mapping is the first thing to check.Enter the IdP field name exactly as your IdP emits it. It is often a bare attribute name, not a namespaced URI - e.g. Entra emits its customized group claim as plain groups, not http://schemas.microsoft.com/ws/2008/06/identity/claims/groups. A near-miss maps nothing.
The group value must be a stable, immutable identifier - a group object ID / GUID, not a display name. Two reasons:
  1. A RoleBinding names the value verbatim. If your IdP emits display names, renaming a group in the IdP silently breaks - or worse, repoints - every binding that named the old string.
  2. As a safety measure, Radar drops any group value containing whitespace, a comma, or a non-ASCII byte (this prevents a crafted group name from injecting an extra subject into the identity). A human-readable name like Platform Admins has a space and is dropped entirely; only a clean identifier such as a 36-character GUID survives.
Configure your IdP to source the groups claim from the immutable group ID. This is usually the default.
Provider examples (illustrative - any OIDC / SAML IdP works the same way):
  • Microsoft Entra: add a groups claim (App registration → Token configuration, or Enterprise App → Single sign-on → Attributes & Claims). Leave the source attribute at its default so the value is the group object ID (GUID), not sAMAccountName or the cloud display name.
  • Okta: emit a groups claim on the SAML / OIDC app and use the immutable group ID as the value, not the group label.
  • Generic OIDC / SAML: expose your IdP’s groups claim and source it from a stable ID.

​
3. Verify before writing RBAC

Before you author a single RoleBinding, confirm your IdP actually sends the groups - as stable IDs. You can check this yourself in the SSO setup portal, no support ticket needed:
  1. In the setup portal, click Test sign-in (or just have a user who belongs to the group sign in normally).
  2. Open the Sessions list, click the sign-in you just made, and expand the SAML response (SAML) or token payload.
  3. Confirm a groups attribute is present and its values are stable IDs (e.g. a1b2c3d4-1234-5678-9abc-def012345678), not display names with spaces.
If the groups attribute is absent, your IdP isn’t emitting it or the attribute mapping is unset (step 2). On a self-managed hub the equivalent causes are auth.oidc.groupsClaim naming a claim your IdP doesn’t emit (it defaults to groups, which suits Okta, Keycloak and Entra but not ADFS), it having been set empty to turn passthrough off, or the groups scope in auth.oidc.scopes not matching what your provider expects. That cuts both ways: Okta and Keycloak may need the scope, and adding one your provider does not define fails the entire sign-in instead of just omitting the groups - see the provider table. If it’s present but the values are display names, they’ll be dropped and the user will see nothing - fix the IdP source attribute so it emits the group object ID. Only once the assertion carries the expected IDs should you write bindings whose subject is kind: Group, name: radar:idp:<group-id>.

​
4. Bind the groups in Kubernetes RBAC

You now bind radar:idp:<group-id> subjects in your own Roles and RoleBindings, exactly as you bind your raw IdP groups today. A minimal example - a vendor group that can edit one namespace:
Two related subjects are available for cases where a group isn’t the right key:
  • radar:email:<lowercased-email> - bind an individual human by email, for RBAC that grants specific people rather than groups.
  • radar:user:<user-id> - bind by opaque, email-independent user ID (see Per-user bindings).
Scoped users should usually get only what their group grants. By default, on top of their group bindings, a Cloud user also gets the Kubernetes tier their Cloud role maps to: radar:viewer → view, radar:member → edit, radar:owner → admin - each with a cluster-scoped infra-read add-on (Nodes, PersistentVolumes, StorageClasses, IngressClasses, PriorityClasses, RuntimeClasses). A user carries one tier, not all three. So to give external or namespace-scoped users no baseline beyond their group, turn off the default bindings for the tier they actually land in. If they land as viewer, turn the viewer tier off so they start from nothing:
defaultRbac.viewer: false on its own already removes both bindings for the tier - the namespaced view and the cluster-scoped infra read; the chart grants a disabled tier nothing. clusterScopedRead.viewer: false is the switch for keeping the tier on but dropping only the infra read. Setting both is harmless.
Match the flags to the tier they land in. The viewer flags only zero out a viewer. If your scoped users land as member - the common default for auto-join and invites - disabling the viewer flags does nothing for them: a member keeps radar:member → edit. Turn off the member tier instead (cloud.defaultRbac.member: false), or land them as viewer first. See SSO for external users for the contractor-specific walkthrough.
Disabling human tier bindings leaves separate grants for background jobs, including cluster-wide Secret read, and alert-triggered investigations. Review those grants separately.
To make IdP groups the default for every new cluster, set cluster access to IdP groups. Existing clusters are never changed; to switch one, follow Switching an existing cluster to IdP groups. The two paths compose: keep the default tiers for your internal operators, and grant scoped external users access exclusively through their radar:idp:<group-id> bindings. The RBAC governance models walk through the mixed and full-IdP setups in depth - this page is the “how the groups get there” half of that.

​
How fresh the groups are

On hosted Cloud, groups come from your organization membership in WorkOS. Without Directory Sync, WorkOS updates that membership from your IdP on an SSO sign-in; emailed codes do not refresh it. Radar picks up the update within about five minutes of that sign-in. Contact us to enable Directory Sync for your organization. Removing someone from an IdP group does not revoke their existing Radar access immediately. To reduce access without waiting for another SSO sign-in:
  • Change the group’s Kubernetes binding. Live operations use the new permissions; cached reads can keep the old permissions for up to two minutes. Other bindings may still grant access.
  • Remove the person under Settings → Organization → Members and revoke their credentials. Removal blocks new browser and PAT requests, but open terminals and streams continue. SSO, auto-join, or an MCP OAuth token that still asserts organization access can add them back; revoke their access in your IdP too. See removing a member.
On a self-managed Hub, groups come from the ID token. Access changes follow that token’s lifetime and refresh settings; see how long group access lasts.

​
How enforcement works

Kubernetes RBAC controls cluster access. Live operations run as the user; cached reads are filtered by Radar. Most cached namespaced reads use namespace-wide access, while Secrets and cluster-scoped resources have separate checks. See Cloud RBAC for the enforcement model and its limits.

​
Troubleshooting

A user signs in fine but sees nothing. When they can’t list Pods or Deployments in any namespace, Radar shows a banner - “You can’t read any namespace in this cluster” - listing the groups the cluster sees for them; check that a radar:idp:* subject is there. Almost always the IdP is emitting group display names instead of stable IDs. Names that contain spaces (or commas / non-ASCII characters) are dropped, so no radar:idp:* subject reaches the cluster and nothing is bound. Point the group claim at the immutable group object ID and have the user sign in again. Secondary causes: no RoleBinding yet names that group’s ID, or group passthrough isn’t enabled on the connection (contact support). Renaming a group in the IdP broke access. You bound a display name rather than the object ID, and the rename changed the string your RoleBinding referenced. Rebind to the group’s immutable ID; renames won’t affect it. An AI investigation cannot read the cluster. Requests you make use your access; alert-triggered turns use a separate group. See AI investigation access for permissions and upgrade requirements. A group with a clean ID still grants nothing. Confirm the RoleBinding subject is exactly radar:idp:<group-id> (the radar:idp: prefix is required - the raw group ID alone won’t match) and that the ID in the binding matches the ID your IdP emits, character for character.

​
See also