Skip to main content
Kubernetes RBAC is fragmented across Role, ClusterRole, RoleBinding, ClusterRoleBinding, plus implicit group memberships and the rule expansion behind every binding. Figuring out the effective permissions of a single ServiceAccount usually means three or four kubectl describe invocations and mental rule-set merging. Radar inverts the model: every RBAC-relevant detail page (ServiceAccount, Pod, Workload, Role, RoleBinding, Namespace) shows the reverse-lookup inline, framed as the question you’re actually asking.

​
What you can answer

  • What can this ServiceAccount do? Open the SA detail page. You see direct bindings, the deduplicated flat rule set, and inherited grants from implicit groups (system:authenticated, system:serviceaccounts, system:serviceaccounts:<ns>) bucketed into a collapsed section so direct grants stay front-and-centre.
  • Who is actually running as this SA? A “Used by Pods” section on the SA page lists every Pod whose spec.serviceAccountName matches. Empty state for unused SAs.
  • What’s the blast radius if this Pod is compromised? Pod detail gets a Permissions section listing the most-permissive rules the Pod’s SA grants. An alert banner fires when the SA has verb wildcards, cluster-admin bindings, escalation verbs (escalate / bind / impersonate), or cluster-wide create pods.
  • What about every Pod this workload spawns? Deployment / StatefulSet / DaemonSet detail pages carry the same Permissions section, framed at the workload level - every Pod the workload spawns inherits these grants.
  • Who is bound to this role? Open any Role or ClusterRole. The reverse-lookup section lists every binding that references it, with subjects expanded inline.
  • What does this binding actually grant? RoleBinding and ClusterRoleBinding pages show an inline rules preview from the linked role, plus a warning callout when subjects include wide groups (system:authenticated, system:unauthenticated, system:masters).
  • What’s the RBAC posture of this namespace? The Namespace detail page is no longer a generic fallback - it shows RoleBindings configured in the namespace plus ClusterRoleBindings whose subjects reference it. Group-only cluster bindings are excluded from the cluster binding list since they touch every namespace and would be noise.
  • Why can’t I do X? The header toolbar has a “My Permissions” panel - a live SelfSubjectRulesReview for your current identity in the active namespace. Faster than kubectl auth can-i --list.

​
Severity cues

The Permissions section auto-expands only when the host’s SA has a real blast-radius hit (any of the trigger conditions above). Otherwise it stays collapsed beneath Conditions so day-to-day debugging isn’t dominated by RBAC noise. Resource-only wildcards (e.g. an inherited view listing every fluxcd.io CRD) deliberately do not trigger the alert - they fire on every authenticated SA and would train operators to ignore the banner. Triggers require verb wildcards, cluster-admin, escalation verbs, or cluster-wide create pods.

​
Permissions required

Radar’s own ServiceAccount needs list on rolebindings and clusterrolebindings in rbac.authorization.k8s.io for the reverse-lookup to work. With the Helm chart, enable rbac.viewRBAC=true to get these plus list on roles / clusterroles for rule expansion. When user authentication is enabled, Radar also gates every reverse-lookup read on the calling user’s own permissions:
  • The endpoint returns 403 if the caller cannot list both rolebindings and clusterrolebindings.
  • “Used by Pods” on the SA page is additionally gated on the user’s list pods permission in the SA’s namespace, so a user with binding-list access but no pod-list access cannot enumerate pod names by querying SAs they shouldn’t see.
Without the binding permissions Radar degrades gracefully: the reverse-lookup sections hide and the rest of the detail page renders normally. See Authentication for the auth-enabled setup.

​
AI integration

The MCP server exposes a get_subject_permissions tool with the same data shape. Use it to answer “is this SA over-privileged?” or “blast radius if this Pod is compromised?” via Claude or Cursor. Returns subject identity, bindings (each with inheritedFromGroup attribution and rule count), the deduplicated flat rule list, and for ServiceAccounts the list of consuming Pods.

​
What’s deferred

Visibility ships first. The audit / linting layer is the natural follow-up but isn’t in this release:
  • RBAC audit checks (wildcard grants, cluster-admin assignments, orphan bindings, unused roles) aligned to Kubescape control IDs.
  • A verb x resource matrix view on the SA page (rakkess-style) as a third tab.
  • A “Subject Explorer” top-level page for browsing Users / Groups that have no detail page today.
  • A graph topology view of Subject -> Binding -> Role -> Rule (rbac-tool viz style).
  • In-UI binding edits and a “can-i” free-form query UI.
The current shape covers the reverse-lookup question, which is the one operators hit most often during incidents and access reviews.