Kubernetes RBAC analysis
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: ["*"]orresources: ["*"]. - 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
impersonateverb is a stealth privilege escalation vector. Rarely needed, often over-granted. - Escalate. The
escalateverb onrolesorclusterroleslets a principal grant themselves more than they have. - Node proxy or exec.
nodes/proxyandpods/execcan 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 deploymentsthat 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.
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-adminthat is not required. - Enforce via admission control: block new RoleBindings or ClusterRoleBindings that grant dangerous verbs.
Frequently asked about kubernetes rbac analysis
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."
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.