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

- name: Example task
  kubernetes.core.k8s:
    state: present
    definition:
      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

- name: Example task
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        namespace: default
        name: example-role
      rules:
        - apiGroups: [""]
          resources: ["pods"]
          verbs: ["get"]

Resources

Documentation

Standards