Key takeaway: Several innocuous-looking Kubernetes permissions are equivalent to cluster administrator through indirect paths. Reviewing verbs without considering what those verbs enable misses the actual privilege.
The Permissions That Escalate
Pod creation. A user who can create a pod in a namespace can mount any secret in that namespace, attach any service account in it, and specify their own image and command. If a privileged service account exists in the namespace — and one usually does — pod creation is equivalent to holding its token.
Exec into pods. This grants a shell inside a running container with that container’s identity, filesystem and network position. It is remote code execution with the workload’s privileges and bypasses every admission control applied at creation time.
Node access. A pod scheduled on a node can, with the right configuration, read the credentials of every other pod on that node through the kubelet.
Impersonation. The impersonate verb allows acting as any user or group, including cluster administrator. It appears in policies as a single unremarkable line.
Editing workload controllers. Modifying a Deployment or DaemonSet means controlling what runs, which is pod creation with extra steps.
| Permission | Effective privilege |
|---|---|
create pods |
Any secret and service account in the namespace |
create pods/exec |
Code execution as the workload |
create pods/portforward |
Network access to internal services |
impersonate users/groups |
Any identity in the cluster |
update deployments |
Persistent code execution |
escalate on roles |
Grant yourself anything |
get secrets |
The obvious one, often the least dangerous |
The ordering is counter-intuitive. Teams carefully restrict secret reading while granting pod creation freely to developers, which provides the same access with more steps and no audit trail pointing at the secret.
Where Wildcards Hide
Roles written with apiGroups: ["*"] and verbs: ["*"] for convenience during setup remain in place permanently. A wildcard role scoped to a namespace is namespace administrator, and one scoped to the cluster is cluster administrator regardless of how modest its name is.
Default service account tokens compound this. Unless disabled, every pod receives a mounted token for the namespace default service account. If that account has been granted permissions over time, every workload in the namespace inherits them — including any workload an attacker compromises.
Practical Reductions
Disable automatic service account token mounting except where the workload genuinely calls the API. Most applications never do, and the mounted token is pure exposure.
Give each workload a dedicated service account with only the permissions it uses, rather than sharing one across a namespace. Sharing means the union of every workload’s requirements applies to all of them.
Use admission control to constrain what pods may specify — no privileged containers, no host namespaces, no arbitrary host path mounts. That limits what pod creation can accomplish even where the permission is granted.
Audit for the dangerous verbs specifically. Searching role bindings for impersonate, escalate, bind, and pod creation across namespaces finds more real privilege than reviewing secret access.
The Bottom Line
Treat pod creation, exec and impersonation as administrative permissions, because they are. Disable token automounting by default, give each workload its own narrowly scoped service account, and constrain pod specifications through admission policy so that creation rights cannot be leveraged into node-level access.
