# Kubernetes RBAC analysis

> Canonical: https://juliet.sh/kubernetes-security/rbac-analysis
> Category: Core Concepts
> Last reviewed: 2026-03-09

## Short answer

Kubernetes RBAC (Role-Based Access Control) is easy to configure incorrectly. Cluster operators bind ClusterRoles with wildcard verbs, default service accounts inherit broad permissions, and CI/CD bots end up with cluster-admin because it works. RBAC analysis is the practice of continuously auditing every Role, ClusterRole, RoleBinding, and ClusterRoleBinding to find over-permissive grants, unused permissions, and dangerous paths from low-trust principals (pods, automation accounts) to high-value targets (cluster-admin, all secrets, node exec).

## The four Kubernetes RBAC objects

- **Role**: namespace-scoped permissions.

                    - **ClusterRole**: cluster-scoped, or namespace-scoped when used via RoleBinding.

                    - **RoleBinding**: binds a Role or ClusterRole to a subject (user, group, ServiceAccount) within a namespace.

                    - **ClusterRoleBinding**: binds cluster-wide.

## RBAC patterns that cause breaches

- **Wildcard verbs or resources.** `verbs: ["*"]` or `resources: ["*"]`.

                    - **Cluster-admin binding by default.** Common in Helm charts that request more than they need. Review every ClusterRoleBinding to `cluster-admin`.

                    - **Create pods with arbitrary ServiceAccounts.** A principal that can create pods and specify a ServiceAccount can escalate to that ServiceAccount's permissions.

                    - **Impersonation.** The `impersonate` verb is a stealth privilege escalation vector. Rarely needed, often over-granted.

                    - **Escalate.** The `escalate` verb on `roles` or `clusterroles` lets a principal grant themselves more than they have.

                    - **Node proxy or exec.** `nodes/proxy` and `pods/exec` can be pivoted to arbitrary container execution.

                    - **Cluster-wide secret read.** A pod that can read all secrets can read database credentials, kubeconfigs, cloud credentials.

## Graph-based RBAC analysis

Traditional RBAC audit is static: here is a list of ClusterRoleBindings. Graph-based analysis traces paths:

    - **Who can become cluster-admin, and how?** Starting from any Pod, User, or ServiceAccount, find every chain of permissions that reaches cluster-admin.

    - **What can this pod reach?** Given a pod's ServiceAccount, list every verb-resource pair it can invoke and the blast radius of each.

    - **Which permissions are unused?** Cross-reference audit logs. A ServiceAccount granted `list deployments` that has never used it in 90 days is a candidate for removal.

This is the query Juliet's graph engine runs on each cluster. See [attack path analysis](/kubernetes-security/attack-path-analysis).

## Practical hardening steps

- Disable automount of ServiceAccount tokens on pods that do not need the API (`automountServiceAccountToken: false`).

                    - Use projected ServiceAccount tokens with short TTLs (`expirationSeconds`).

                    - Move namespace-scoped work to Roles rather than ClusterRoles.

                    - Replace wildcards with explicit lists.

                    - Audit and remove every ClusterRoleBinding to `cluster-admin` that is not required.

                    - Enforce via [admission control](/kubernetes-security/admission-control): block new RoleBindings or ClusterRoleBindings that grant dangerous verbs.

## Frequently asked

### How is Kubernetes RBAC different from AWS IAM?

Kubernetes RBAC is cluster-scoped, uses verbs (get, list, create, update, delete, exec, impersonate, and more), and is enforced by the API server. AWS IAM is cloud-scoped, uses actions, and is enforced by every AWS service. The two interact via IRSA (IAM Roles for Service Accounts), which is its own attack-path category.

### What is the safest default for pods that do not need the API?

Set `automountServiceAccountToken: false` at the pod spec level. Workloads that do not talk to the Kubernetes API do not need a token mounted.

### Should I use groups or ServiceAccounts for CI/CD?

ServiceAccounts with projected tokens scoped short-lived to the CI job. Handing cluster-admin to a CI bot even temporarily is a common failure mode.

### How often should I audit RBAC?

Continuously. RBAC state changes with every chart install, every operator, every new namespace. A quarterly audit misses weeks of drift. Graph-based platforms re-evaluate on every RoleBinding change event.

### Can I delete ClusterRoleBindings safely?

Check usage first via audit logs. Kubernetes does not warn when you break a running workload's permissions. Some platforms (including Juliet) cross-reference bindings against observed API calls to distinguish "unused and deletable" from "unused but recent."

## Related

- [Attack path analysis](https://juliet.sh/kubernetes-security/attack-path-analysis)
- [Admission control](https://juliet.sh/kubernetes-security/admission-control)
- [Blast radius analysis](https://juliet.sh/kubernetes-security/blast-radius)
- [What is KSPM?](https://juliet.sh/kubernetes-security/what-is-kspm)