RBAC(RBAC)
Role-Based Access Control — Kubernetes's authorization mechanism that grants permissions through role bindings.
Also known as: RBAC
What is RBAC?
Role-Based Access Control (RBAC) is the Kubernetes authorization system that controls which users, groups, and ServiceAccounts can perform which actions on which API resources. RBAC is enabled by default in all modern Kubernetes distributions and replaces the older ABAC system. Every API request carries a principal identity, and RBAC determines whether that principal is permitted to perform the requested verb (get, list, create, update, patch, delete, watch) on the target resource (pods, secrets, deployments, etc.) in the target namespace.
RBAC has four core object types: Role (namespace-scoped permissions), ClusterRole (cluster-scoped or cross-namespace permissions), RoleBinding (grants a Role or ClusterRole to a principal within a namespace), and ClusterRoleBinding (grants a ClusterRole cluster-wide). Permissions in Kubernetes are additive — there is no explicit deny mechanism. Once a permission is granted through any binding, it cannot be overridden by another policy.
Least-privilege RBAC configuration is a foundational security practice: ServiceAccounts should receive only the permissions they actually need, with no wildcard verbs or resources. The cluster-admin ClusterRole — which grants unrestricted access to everything — should be granted to as few principals as possible and audited regularly. Unused RoleBindings and ClusterRoleBindings pointing to deleted subjects are a security risk and a compliance finding.
Example
# View all ClusterRoleBindings granting cluster-admin
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name == "cluster-admin") | {name: .metadata.name, subjects: .subjects}'
# Check what a specific ServiceAccount can do
kubectl auth can-i --list --as=system:serviceaccount:production:my-app -n production
# Find all RoleBindings in a namespace
kubectl get rolebindings -n production -o wideCost & Waste Implications
RBAC misconfigurations don't directly incur cloud costs but enable cost-generating attacks: a compromised cluster-admin-level ServiceAccount can provision expensive GPU nodes, mine cryptocurrency using cluster compute, or exfiltrate data to external storage incurring egress charges. Orphaned RoleBindings to deleted subjects create dangling permissions that become exploitable if the subject name is reused.
How KorPro Helps
KorPro audits RBAC configurations for overly permissive bindings, orphaned RoleBindings pointing to deleted ServiceAccounts, and ServiceAccounts with cluster-admin grants in production namespaces.
Scan Your Cluster FreeRelated Terms
Role and ClusterRole
SecurityRBAC objects that define a set of permitted API verbs on specified resources, scoped to a namespace (Role) or cluster-wide (ClusterRole).
Read definitionServiceAccount
SecurityAn identity for Pods to authenticate to the Kubernetes API and cloud provider services, with tokens automatically mounted.
Read definitionPod Security
SecurityKubernetes controls that restrict what Pods can do at the OS level — capabilities, root access, host namespaces, and file system permissions.
Read definitionNamespace
Core ConceptsA virtual partition within a cluster that isolates resources, access control, and networking between teams or environments.
Read definitionStop Wasting Money on Orphaned Kubernetes Resources
KorPro connects to your clusters across GCP, AWS, and Azure — no agents, no installation — and surfaces every orphaned resource with its monthly cost estimate.