RBAC under Cloud mode

• Direct resource access is impersonated. Live reads (pods, nodes, etc.), writes, and exec/logs are all sent to the API server impersonated as the user - Kubernetes itself authorizes and enforces them against your in-cluster RBAC. Radar adds no authorization on this path.
• Cached timeline/topology is SubjectAccessReview-authorized, then filtered. The surfaces Radar serves from its own cache (timeline, topology) can’t be impersonated per object, so for each cached object Radar runs a SubjectAccessReview against the user’s identity and filters the results to what that identity may read.

​

The header contract

1. Strips inbound X-Forwarded-* to prevent spoofing.
2. Injects:
   • X-Forwarded-User: <user_id> (e.g. user_01HF...)
   • X-Forwarded-Groups: a comma-separated list of the groups below.

​

The default RBAC

​

Cluster-scoped resources need an extra grant

​

Pod certificate requests are opt-in

• Turn it off for a tier to remove this add-on’s binding. With the default built-in mappings that leaves the tier namespaced-only: clusterScopedRead.viewer: false leaves viewers on the stock view (namespaced read) with no cluster-scoped visibility - the usual choice for a low-trust viewer tier (see security-conscious setups). With a custom *ClusterRole, the tier’s cluster-scoped reach is whatever that role grants - the flag only controls our binding.
• Swapping a tier’s namespaced role does not disable cluster-read. viewerClusterRole/memberClusterRole/ownerClusterRole and clusterScopedRead.* are independent bindings. If you want a custom namespaced role and no infra-read, set that tier’s clusterScopedRead to false too.
• A tier you’ve disabled entirely (viewer: false) gets nothing here either - you own that tier’s RBAC.

​

Overriding the defaults

# values.yaml for the in-cluster Radar
cloud:
  enabled: true
  url: wss://api.radarhq.io/agent
  clusterName: cl_xxx
  existingSecret: radar-cloud-token
  defaultRbac:
    create: true                       # set false to skip all three bindings
    owner: true                        # emit radar:owner binding
    member: true
    viewer: true
    ownerClusterRole: cluster-admin    # ClusterRole each binding maps to
    memberClusterRole: edit
    viewerClusterRole: view
    clusterScopedRead:                 # cluster-scoped infra read, per tier (each default true)
      viewer: true                     # set false → viewer is namespaced-only
      member: true
      owner: true
    nodeOps: false                     # owner cordon/drain (cluster-scoped write); off by default

cloud:
  defaultRbac:
    member: false
    viewer: false

​

Locking down for security-conscious orgs

cloud:
  defaultRbac:
    clusterScopedRead:
      viewer: false        # member + owner still get infra read

cloud:
  defaultRbac:
    clusterScopedRead:
      viewer: false
      member: false
      owner: false

cloud:
  defaultRbac:
    ownerClusterRole: my-restricted-owner   # your ClusterRole
    # clusterScopedRead.owner stays true → owners still see Nodes/PVs/etc.

​

Choosing a governance model

cloud:
  defaultRbac:
    owner: false
    member: false
    viewer: false

# Your platform-team group gets cluster-wide admin - same pattern as any
# other group, just bound to a broad role.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-team-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
  - kind: Group
    name: radar:idp:<platform-team-group-id>
    apiGroup: rbac.authorization.k8s.io

• Cloud roles don’t disappear - they govern the product, not the cluster. Owner/Member/Viewer still control billing, member management, SSO, cluster lifecycle, and owner-only product surfaces. The mental model: Cloud role = control-plane permissions; Kubernetes bindings = cluster access. The tier bindings are merely the default cluster access, and they’re optional.
• The add-on grants ride the tier bindings. Cluster-scoped read, nodeOps, and the Helm add-on roles bind to tier groups - with all tiers disabled, none of them render, and you own those grants in your own ClusterRoles (see the recipe above for the cluster-read set).

​

Per-user bindings

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alice-apps-edit
  namespace: apps-prod
subjects:
  - kind: Group
    name: radar:user:user_01HF...     # user_id from Settings → Tokens or audit log
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

• The audit log row metadata.
• The user’s PAT page (their own ID is shown at the top).
• Owner’s view of Settings → Organization → Members (hover the row).

​

Per-org bindings

​

Auditing what the in-cluster Radar did

​

I can’t see Nodes / PVs / StorageClasses

• That tier’s clusterScopedRead is off - set cloud.defaultRbac.clusterScopedRead.<tier>: true (the default).
• You’re on an older chart that predates the cluster-read add-on - upgrade, or grant the reads directly (below).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: radar-cluster-read-custom
rules:
  - apiGroups: [""]
    resources: ["nodes", "persistentvolumes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingressclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["scheduling.k8s.io"]
    resources: ["priorityclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["node.k8s.io"]
    resources: ["runtimeclasses"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: radar-cluster-read-custom
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: radar-cluster-read-custom
subjects:
  - kind: Group
    name: radar:viewer        # and/or radar:member, radar:owner
    apiGroup: rbac.authorization.k8s.io

​

Things to watch out for

• Default admin is broad within namespaces, but not cluster-wide. It reads Secrets and mutates RBAC in every namespace, but as a namespace role it grants nothing cluster-scoped on its own - no Node read, no node drain (that’s the opt-in nodeOps add-on), no PV/StorageClass. If you have non-admin owners, swap radar:owner to a custom ClusterRole.
• view doesn’t see Secrets. That’s K8s view definition, not ours. If you want viewers to see Secret names without values, use a custom ClusterRole that grants get/list on secrets (which lets them see Secret data too - K8s doesn’t have field-level RBAC). Since Secret data is redacted by Radar before display, this is usually safe but think it through.
• Built-in roles are aggregation targets. view/edit/admin are auto-reconciled and accept aggregate-to-* labels, so third-party charts (metrics-server, kyverno, some operators) can widen what a tier effectively holds - the tier’s scope drifts with cluster contents, not just with this chart. Audit with kubectl auth can-i --list --as-group=radar:viewer --as=x if you need certainty.
• Helm write needs more than edit. Helm install / upgrade / rollback / uninstall need broad write access, including Secrets (Helm releases are Secrets). The chart’s default member → edit is intentionally not enough for Helm writes; opt in via a custom binding if you want members to manage Helm.

​

See also

• Authentication - how proxy / OIDC mode work generally.
• Connecting a cluster - the chart values that enable cloud-mode.
• IdP group-based access - where the radar:idp:<group> subjects come from and how to make your IdP emit them.
• Organizations & roles - the role definitions that drive these groups.