b2KIT

Kubernetes RBAC Analyzer

Analyze Kubernetes RBAC configurations (Roles, ClusterRoles, Bindings) for overly permissive or risky access grants.

Tested tool guide Tested browser tools Checked August 16, 2026

What Kubernetes RBAC Analyzer does and how it behaves

Kubernetes RBAC Analyzer connects the rules in Role and ClusterRole objects to the users, groups, and service accounts named by RoleBinding and ClusterRoleBinding objects, then highlights grants that deserve review, such as wildcard permissions, sensitive resource access, or authority to create and modify workloads. It evaluates the configuration pasted into the page and keeps it in the browser. The common surprise is scope: a RoleBinding may reference a ClusterRole but grants those permissions only within its namespace; a ClusterRoleBinding applies its grant cluster-wide.

How the result is produced

1

Rule breadth

The analyzer reads each policy rule's apiGroups, resources, verbs, resourceNames, and nonResourceURLs fields. Named operations and resources describe a narrower request surface; wildcard values such as '*' describe a broader one and warrant closer review. It also distinguishes ordinary resource operations from sensitive RBAC verbs such as bind, escalate, and impersonate. A rule expresses requests Kubernetes may authorize; it does not show whether those requests were ever made.

2

Binding resolution

Each binding's roleRef identifies the permission set, and its subjects identify the users, groups, or service accounts receiving it. The analyzer correlates these objects while preserving Kubernetes scope rules. A RoleBinding can select a Role in its own namespace or a ClusterRole; a ClusterRoleBinding selects a ClusterRole. ServiceAccount namespace is significant, so two accounts with the same name in different namespaces are different subjects.

Good uses

  • Review rendered Helm or Kustomize manifests before deployment to spot an operator or chart that binds wildcard verbs, all resources, secret access, or workload-creation permissions to a service account.
  • Investigate why an application identity appears overprivileged by analyzing its ServiceAccount together with the relevant roles and bindings, then tracing which permission rules reach that subject.
  • Assess an RBAC change during code review, especially when a namespaced RoleBinding becomes a ClusterRoleBinding or a narrowly named verb, resource, or API group becomes a wildcard.

Limits and checks

  • A submitted manifest set may not represent the cluster's effective state. Missing referenced roles, generated bindings, aggregated ClusterRole results, built-in objects, or later mutations can make deployed permissions different from the analyzed configuration.
  • Kubernetes RBAC permissions are additive and do not contain deny rules. A reported grant describes a request category RBAC can authorize, not proof that a request will succeed; admission controls, request details, object state, and other cluster policies can still matter.
  • Risk findings require operational context. A controller may legitimately need broad discovery or reconciliation permissions, while resourceNames restrictions, subresources such as pods/log, and differences among get, list, watch, create, bind, escalate, and impersonate materially affect exposure.

Common questions

Does this show everything a ServiceAccount can do?

Only if the analyzed configuration contains every Role, ClusterRole, RoleBinding, and ClusterRoleBinding contributing to that ServiceAccount's access. The analyzer cannot turn a partial manifest into a complete picture of deployed authorization. It is a static configuration review, not a live authorization query, so compare important findings with the cluster's current state.

Is a ClusterRole referenced by a RoleBinding cluster-wide?

No. The ClusterRole supplies reusable rules, but the RoleBinding grants applicable permissions within the RoleBinding's namespace. Kubernetes uses a ClusterRoleBinding for a cluster-wide grant. This distinction is why the analyzer must consider the binding kind and namespace instead of determining scope from the referenced role's name alone.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools