Kubernetes roles that allow command execution inside pods violate the principle of least privilege.

Why is this an issue?

The pods/exec subresource lets a caller run arbitrary commands inside any container of a pod that the role applies to. Granting the create verb on this subresource therefore turns the role into a remote-shell capability for those pods.

In a production cluster, exec access is normally unnecessary: the principle of least privilege says a role should grant only the permissions its holders need to do their job, and containers are typically treated as immutable infrastructure that should be replaced by rebuilding the image rather than mutated in place at runtime.

What is the potential impact?

Unauthorized access and data exposure

A user or service account bound to a role with pods/exec permissions can execute arbitrary commands inside the containers the role applies to. An attacker who compromises such an account can read secrets and other sensitive data accessible from inside those containers, tamper with the running workload, and use the foothold to probe other components reachable from the pod network.

How to fix it

Remove the create verb on the pods/exec resource from the role. If a subset of users genuinely needs to run commands in pods, define a dedicated role bound only to those users instead of granting exec rights to the general-purpose role.

Code examples

Noncompliant code example

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: example-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["pods/exec"] # Noncompliant
    verbs: ["create"]

Compliant solution

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: example-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get"]