Kubernetes RBAC privilege escalation: technical assessment

Kubernetes RBAC controls the operations an authenticated principal may request through the cluster API. Privilege escalation is not limited to creating a ClusterRoleBinding for cluster-admin. The ability to create workloads, select ServiceAccounts, execute commands in Pods, mint tokens, impersonate identities or modify resources consumed by privileged operators can be equally consequential.

The essential rule is: audit capabilities, not role names. A role called developer may effectively control an entire namespace, while a custom role containing only a few verbs may provide a path to cluster-wide impact. A safe assessment combines a static RBAC graph, workload and admission analysis, and a minimum proof inside a dedicated namespace. It does not require reading production Secrets or launching a privileged container on a production node.

How the Kubernetes RBAC model works

RBAC uses four core objects:

a Role defines rules inside one namespace;
a ClusterRole defines cluster-scoped rules or a reusable set of namespaced rules;
a RoleBinding assigns a role to subjects in one namespace;
a ClusterRoleBinding assigns a ClusterRole across the cluster.

A rule specifies API groups, resources, optional resource names and verbs such as get, list, watch, create, update, patch and delete. The model is additive: RBAC does not provide a general deny rule. If any applicable rule allows an operation, RBAC does not subtract it; a restriction must arise from the absence of permission or from another layer such as admission control.

The official RBAC reference distinguishes resources from non-resource URLs. Subresources require particular attention because pods, pods/log, pods/exec, pods/attach and pods/portforward are separate authorisation targets. Likewise, serviceaccounts/token is not equivalent to merely reading a ServiceAccount object.

Why listing ClusterRoleBindings is insufficient

Effective capability is the composition of several layers:

Layer	What the assessor must establish
Authentication	user, group, ServiceAccount, certificate, OIDC or proxy identity
Bindings	every RoleBinding and ClusterRoleBinding applying to the principal
Rules	apiGroups, resources, subresources, verbs and resourceNames
Mutation	ability to change a role, binding, webhook or operator resource
Workload	ability to create a Pod, Job or Deployment using a selected ServiceAccount
Admission	Pod Security, admission policies and validating or mutating webhooks
Runtime	tokens, Secrets, volumes, capabilities, host access and network reach
Cloud	workload identity and permission outside Kubernetes

This is a graph rather than a spreadsheet. An edge stating “may create Deployment” connects to “Deployment may use a privileged ServiceAccount” unless an admission control or another mechanism prevents that selection. A later edge may reach a cloud role through workload identity.

Special verbs: `escalate`, `bind` and `impersonate`

Kubernetes includes controls against straightforward self-assignment. A user generally cannot create or update a Role or ClusterRole containing permissions they do not already hold unless authorised for the escalate verb. Similarly, binding a role normally requires the permissions represented by that role or explicit bind permission.

These safeguards are only useful when escalate and bind are tightly controlled. The assessment should enumerate every role containing either verb, the covered resource and all principals that can reach it. Wildcards in verbs or resources are especially hazardous because they may include capabilities added later.

impersonate permits a request to be evaluated as another user, group, ServiceAccount or supported attribute, depending on rule scope. Some support systems and control-plane components legitimately require it, but it is a direct trust boundary. Audit evidence must preserve both the original and impersonated identity.

Escalation through workload creation

The Kubernetes RBAC good-practices guidance warns that workload creation can imply access to other resources. A principal able to create a Pod may:

select a ServiceAccount unless admission constrains the choice;
mount permitted Secrets, ConfigMaps and volumes;
execute an image under their control;
inherit network reach available to the namespace;
interact with other Pods and services;
request host settings or Linux capabilities if policy permits them.

“Can create a Deployment” is therefore code-execution authority in a trust zone, not merely permission to submit declarative YAML. It must be evaluated with Kubernetes and container security, Pod Security Standards, network policy and node configuration.

A safe proof creates a Pod or Job only in a dedicated namespace, under a test ServiceAccount with one harmless permission. It does not mount hostPath, use host networking or retrieve a real Secret. The purpose is to verify the API and admission decision, not compromise a node.

ServiceAccounts and tokens are a critical trust boundary

Every namespace has a default ServiceAccount, but that account should not receive unnecessary rights. A workload may select a ServiceAccount, and the kubelet can provide a projected, time-limited token unless automounting is disabled. The ServiceAccount documentation describes the TokenRequest API and short-lived projected tokens as the preferred mechanism.

Review:

workloads using default instead of a dedicated account;
automountServiceAccountToken remaining enabled without an API requirement;
principals allowed to create tokens through serviceaccounts/token;
token audience and lifetime;
legacy long-lived tokens and service-account-token Secrets;
cloud rights acquired through IRSA, Workload Identity or the provider equivalent;
the ability of a workload creator to select a stronger account.

Rotating a token does not repair an over-broad role. Remove the unnecessary binding and identity-selection path first, then rotate credentials through a controlled secrets-management process.

Subresources that change risk materially

Permission for pods/exec or pods/attach allows interaction with a running container. It may expose environment variables, a mounted token, configuration files and the Pod’s network access. pods/portforward can undermine assumptions about service exposure, although it remains subject to API authorisation and audit. pods/log may reveal credentials, customer data or tokens accidentally emitted by the application.

Other high-risk permissions include:

updating deployments, daemonsets, statefulsets, jobs and cronjobs;
modifying mutatingwebhookconfigurations and validatingwebhookconfigurations;
creating certificatesigningrequests or approving selected signers;
changing nodes/proxy, operator resources and powerful CRDs;
reading or changing secrets;
patching status or finalisers where a controller trusts those fields.

Every cluster has different operators. A CRD may represent a database, bucket, user or cloud policy. The assessor must understand resource semantics rather than treating all custom YAML as low risk.

Aggregated ClusterRoles and permission drift

Kubernetes can aggregate a ClusterRole from other roles carrying selected labels. This supports extension APIs but creates a transitive dependency: adding one labelled role may automatically broaden an aggregated role already assigned to many developers. Monitor roles with aggregationRule, permission to create or label ClusterRoles, and changes introduced by Helm charts or operators.

Default roles and bindings marked kubernetes.io/bootstrapping=rbac-defaults may be auto-reconciled when the API server starts. Editing system objects without understanding that lifecycle is not a reliable remediation strategy.

Safe RBAC audit and penetration-test methodology

1. Establish boundaries and tenant assumptions

Document clusters, contexts, distributions, namespaces, administrators, workload-identity systems, excluded workloads and permitted operations. A namespace is not automatically a strong multi-tenant boundary. Where tenants do not trust one another, assess nodes, networking, admission, storage and shared operators as well.

2. Build the effective-permission graph

Collect Roles, ClusterRoles, bindings, ServiceAccounts, aggregation rules and authentication configuration. SelfSubjectAccessReview and SelfSubjectRulesReview help confirm the perspective of a principal, but the documented limitations of rule enumeration remain. The graph must include the ability to mutate resources and launch workloads.

3. Classify high-impact capabilities

Prioritise cluster-admin, system:masters, wildcards, bind, escalate, impersonate, Secrets, tokens, CSRs, webhooks, nodes, exec/attach/port-forward and workload creation with arbitrary ServiceAccounts. Distinguish direct capability from a path requiring a second condition.

4. Validate admission in a test namespace

Create test Roles, ServiceAccounts and harmless workloads. Verify that a prohibited account, securityContext, volume or image source is rejected. Do not attempt a container escape on a production node. The useful evidence is the API decision and corresponding audit record.

5. Retest the entire path

After remediation, evaluate RBAC, admission, workload controls and cloud identity. Deleting one binding is ineffective if the principal belongs to a second group with equivalent access or can recreate the relationship through an operator.

For managed clusters, place the retest inside a broader AWS, Azure or GCP penetration test, because workload identity, provider management planes and control-plane roles can extend the graph beyond the Kubernetes API.

Audit logging and escalation detection

Kubernetes auditing records a chronological sequence of API activity. The audit policy should capture metadata or appropriate request detail for sensitive changes without unnecessarily storing Secret material. Send logs outside the cluster or to a strongly protected backend.

High-value events include:

create, update or patch of Role, ClusterRole, RoleBinding and ClusterRoleBinding;
use of bind, escalate or impersonation;
ServiceAccount TokenRequest outside the expected workload pattern;
Pod creation with privileged context, host namespaces or hostPath;
pods/exec, attach and portforward by an unusual principal;
changes to admission webhooks, policy or Pod Security namespace labels;
creation or approval of a CSR;
a burst of Forbidden responses followed by a successful privileged operation.

Correlation should retain user, groups, source IP, user agent, impersonation metadata and subsequent calls from the newly available identity. Incident response includes revoking source credentials, removing unauthorised bindings, inspecting workloads and rotating every reachable secret.

Kubernetes RBAC hardening

Grant permissions in a namespace and treat ClusterRoleBinding as an exception.
Create dedicated ServiceAccounts and disable automount where no API access is needed.
Avoid resource and verb wildcards, particularly for CRDs.
Restrict bind, escalate and impersonate to controlled components.
Separate the person deploying a workload from the person assigning its ServiceAccount.
Enforce Pod Security Standards and additional admission rules for accounts, images and volumes.
Restrict exec, attach and port-forward, and audit administrative sessions.
Scan and verify images through a mature container-image security process.
Apply network policy because RBAC does not authorise direct Pod-to-Pod connections.
After critical advisories such as IngressNightmare CVE-2025-1974, assess the effective permission of the compromised controller identity.