Kubernetes RBAC Guide: Roles, Bindings and Service Account Permissions

Kubernetes RBAC decides what every user, controller and pod can do against the API server, and a handful of verbs and default bindings quietly turn ordinary permissions into cluster takeover. Most clusters run with dozens of ClusterRoleBindings nobody can explain, service accounts that inherited edit or cluster-admin from an install script, and operators granted wildcards "for now". This guide explains how Role, ClusterRole, RoleBinding and ClusterRoleBinding actually combine, which permissions are equivalent to privilege escalation, how service account tokens are issued and bound, and how to roll out least privilege without breaking workloads. It is written for platform engineers, cluster administrators and security teams who own production Kubernetes, managed or self-hosted.

Key takeaways

• RBAC is additive only. There are no deny rules, so every binding widens access and the only way to remove a permission is to remove or narrow a binding.
• Some verbs are escalation in disguise. list on Secrets, pod creation, escalate, bind, impersonate, get on nodes/proxy and create on serviceaccounts/token each lead to more access than they appear to grant.
• Service accounts are the largest identity population. Each one is a non-human identity with a token; bind roles to application-specific service accounts, never to default or to the system:serviceaccounts group.
• Use bound, short-lived tokens. Projected tokens from the TokenRequest API expire (one hour by default) and are bound to the pod; legacy Secret-based tokens never expired and should be hunted down.
• system:masters bypasses everything. Membership skips RBAC and authorisation webhooks and cannot be revoked by deleting bindings, so treat any credential carrying it as break-glass only.

How Kubernetes RBAC works

The RBAC authoriser uses four objects in the rbac.authorization.k8s.io API group. It is enabled by listing the RBAC authoriser in the file passed to --authorization-config, or in older configurations with --authorization-mode=...,RBAC. Managed services (EKS, AKS, GKE) enable it by default, usually alongside their own cloud IAM authoriser or mapping layer.

• Subjects: users and groups come from the authenticator (client certificates, OIDC, cloud IAM mapping); Kubernetes has no user objects. Service accounts are named system:serviceaccount:<namespace>:<name> and belong to the groups system:serviceaccounts:<namespace> and system:serviceaccounts.
• roleRef is immutable: changing which role a binding points to fails validation; you delete and recreate the binding. This is deliberate, so that update on a binding cannot silently swap in a more powerful role.
• Aggregated ClusterRoles: a ClusterRole with an aggregationRule has its rules filled in by the control plane from every ClusterRole matching a label selector. The built-in admin, edit and view roles aggregate any ClusterRole labelled rbac.authorization.k8s.io/aggregate-to-admin, -edit or -view, which means installing a CRD or operator can silently widen what every edit holder can do.
• Wildcards: "*" in resources or verbs covers object types created in the future, including CRDs added by later installs.

Default roles and what they really grant

API servers create default ClusterRoles and bindings labelled kubernetes.io/bootstrapping=rbac-defaults. On every start-up the API server re-adds missing permissions and subjects to them (auto-reconciliation) unless the annotation rbac.authorization.kubernetes.io/autoupdate is set to false, so hardening edits to system: roles are overwritten unless you opt out, and opting out can break clusters.

Default RBAC grants no permissions to service accounts outside kube-system beyond discovery. Every other service account permission in your cluster was added by someone, usually by a Helm chart, an operator manifest or a quick fix. See the Authorisation Models Guide for how RBAC compares with attribute and relationship-based models.

Privilege escalation paths in RBAC

The RBAC API prevents users from creating a Role or binding that grants permissions they do not already hold, unless they have the escalate verb on roles/clusterroles or the bind verb on the referenced role. That protection is narrow. The Kubernetes RBAC good practices page lists permissions that let a subject reach more than its rules say, and the CIS Kubernetes Benchmark (section 5.1) turns most of them into checks.

Two structural points follow. First, namespace boundaries are weak for anyone who can create workloads: treat "can create pods in namespace X" as "holds every credential in namespace X". Second, a user or service account name that is deleted and later recreated inherits any bindings that still reference it, so remove bindings when identities are deprovisioned. The patch on Namespaces risk is described by Kubernetes but has no dedicated CIS check or ATT&CK technique; enforce it through admission policy. See the Kubernetes Admission Control Guide.

Service accounts as non-human identities

Every namespace gets a default service account and every pod runs as one. That makes service accounts the bulk of identities in a cluster and the ones attackers find first, because a compromised container already holds its token at /var/run/secrets/kubernetes.io/serviceaccount/token unless mounting is disabled. Kubernetes documents five ways to grant service account permissions, from most to least secure:

1. Application-specific service account (best practice): set serviceAccountName in the pod spec and bind a narrow Role to system:serviceaccount:my-namespace:my-sa.
2. The namespace default service account: every pod without serviceAccountName gets these permissions. Avoid; CIS 5.1.5 checks that default service accounts are not actively used.
3. All service accounts in a namespace via the group system:serviceaccounts:my-namespace.
4. All service accounts cluster-wide via system:serviceaccounts (discouraged).
5. cluster-admin to all service accounts (strongly discouraged): Kubernetes warns this gives any user who can read Secrets or create any pod full control of the cluster.

Token types and lifetimes

• Disable automount where the API is not needed: set automountServiceAccountToken: false on the ServiceAccount or the pod (the pod setting wins). Most application pods never call the Kubernetes API. CIS 5.1.6 checks this.
• Cloud credentials ride on the same identity: EKS, AKS and GKE workload identity features exchange the projected service account token for cloud credentials, so a service account bound to a cloud role is a cloud identity too. See the Workload Identity Federation Guide.
• Ownership: record an owner, purpose and expected API calls for every non-system service account, exactly as for any other machine identity. See the Kubernetes NHI Security Guide and the Kubernetes Service Account Token Guide.

Designing roles: patterns that hold up

Pick the pattern by who the subject is and how many clusters you run.

Small versus large estates: a single-team cluster can manage RBAC as reviewed YAML in Git and apply it with kubectl auth reconcile. Multi-tenant and multi-cluster estates need group-based bindings from the identity provider, a policy engine (ValidatingAdmissionPolicy, OPA Gatekeeper or Kyverno) blocking dangerous rules at admission, and a central inventory of bindings across clusters. In managed services, remember that cloud IAM (for example EKS access entries or AKS Entra ID integration) decides who reaches the cluster, while Kubernetes RBAC decides what they can do once there; review both.

Rolling out least privilege

1. Inventory: export all ClusterRoleBindings and RoleBindings with their subjects (kubectl get clusterrolebindings,rolebindings -A -o json), and list who holds cluster-admin, members of system:masters in issued certificates or cloud mappings, and any bindings to system:unauthenticated or system:serviceaccounts.
2. Find escalation holders: for each risky permission in the table above, enumerate subjects with kubectl auth can-i (for example kubectl auth can-i list secrets -n prod --as system:serviceaccount:prod:app-sa) or an RBAC analysis tool. Fix bindings to default service accounts and cluster-wide service account groups first.
3. Turn on audit logging: pass an audit policy with --audit-policy-file (no file means no events). Log at Metadata level broadly, and at RequestResponse for RBAC objects, serviceaccounts/token and webhook configurations. Avoid logging Secret bodies.
4. Derive real usage: collect 30 days of audit events per service account and user, and build replacement Roles from the verbs and resources actually used.
5. Pilot: apply new Roles in one non-production namespace with kubectl auth reconcile -f rbac.yaml --dry-run=client first, then for real. Watch audit logs for 403 responses from the affected subjects.
6. Remove the old grants: once a pilot ring runs clean for a release cycle, apply kubectl auth reconcile with --remove-extra-subjects --remove-extra-permissions, and set automountServiceAccountToken: false on service accounts that never call the API.
7. Prevent regression: enforce admission rules that reject new ClusterRoleBindings to cluster-admin, wildcard rules, and bindings to default service accounts, starting in audit or warn mode before deny.
8. Rollback: keep the previous RBAC manifests in Git and reapply them if a workload breaks; because RBAC is additive, rollback is re-adding a binding, which is instant and does not require restarting pods.

Detection and measurement

RBAC changes and token activity are visible only in API server audit logs, so ship them off the control plane. On managed services enable the provider's control plane audit log export.

• Binding changes: create, update or patch on clusterrolebindings and rolebindings, especially any referencing cluster-admin, admin or edit (ATT&CK T1098.006).
• Token minting: create on serviceaccounts/token by anything other than the kubelet or known controllers.
• Secret enumeration: list or watch on Secrets across namespaces from workload service accounts (T1552.007).
• Discovery from pods: bursts of SelfSubjectAccessReview or SelfSubjectRulesReview requests, which is what kubectl auth can-i --list produces when run by an intruder inside a container (T1613).
• Use from unexpected places: a service account token presented from an IP outside the pod network, or a user agent such as kubectl on a workload identity (T1078.004 where the cluster is a cloud service).

Framework mapping

Common failure patterns

• Mounted tokens with real permissions in exposed workloads: in the Kubeflow cryptomining attacks, Microsoft reported that attackers used the service account mounted in notebook servers to deploy containers after entering through internet-exposed dashboards. An internet-facing pod should have automount off or a service account with no write verbs.
• Cloud keys reachable from the cluster: in the Tesla Kubernetes cryptojacking case, an unauthenticated Kubernetes console led to a pod holding AWS credentials. RBAC that lets a console or pod read Secrets cluster-wide converts one exposed interface into cloud access.
• Granting edit and believing it is safe: teams give edit because it cannot change RBAC, missing that it reads Secrets and runs pods as any service account in the namespace.
• Vendor manifests with cluster-admin or wildcards: agents and operators installed from upstream YAML or charts often ship broad ClusterRoles that nobody reviews. See the Helm Security Guide.
• Treating get nodes/proxy as read-only: monitoring tools are given it for metrics, but it allows exec into pods and bypasses audit logging and admission control.
• Break-glass certificates that never expire: client certificates with O=system:masters issued at cluster creation and copied into laptops and CI cannot be revoked through RBAC at all.

Practitioner checklist

• Export every ClusterRoleBinding and RoleBinding and assign an owner to each non-system subject.
• Remove bindings to system:unauthenticated, system:serviceaccounts and namespace default service accounts.
• Restrict list/watch on Secrets, pod creation, PersistentVolume creation, nodes/proxy, escalate, bind, impersonate, CSR approval, serviceaccounts/token and webhook configuration writes to named subjects.
• Give every workload its own service account and set automountServiceAccountToken: false where the API is not called.
• Find and retire legacy kubernetes.io/service-account-token Secrets; use projected tokens or kubectl create token.
• Keep system:masters credentials offline as break-glass and use impersonation or just-in-time elevation for daily administration.
• Review ClusterRoles labelled for aggregation into admin, edit and view after every CRD or operator install.
• Enable API server audit logging and alert on binding changes, token minting and cross-namespace Secret listing.
• Enforce RBAC rules at admission and run CIS Benchmark section 5.1 checks in CI against every cluster.

Standards and references

• Kubernetes: Using RBAC Authorization
• Kubernetes: Role Based Access Control Good Practices
• Kubernetes: Managing Service Accounts
• Kubernetes: Configure Service Accounts for Pods
• Kubernetes: Auditing
• CIS: Kubernetes Benchmark
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Additional Container Cluster Roles

Related NHI Mgmt Group resources: Kubernetes Security Guide · Kubernetes NHI Security Guide · Kubernetes Service Account Token Guide · Container Runtime Security Guide · Service Account Security Guide