Skip to main content

More Info:

The ability to create pods in a namespace can provide a number of opportunities for privilege escalation, such as assigning privileged service accounts to these pods or mounting hostPaths with access to sensitive data (unless Pod Security Policies are implemented to restrict this access)

Risk Level

Low

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify which subjects can create pods
    • Run on any machine with kubectl access:
  2. Inspect the exact permissions granting create on pods
    • Run on any machine with kubectl access:
      • Open /tmp/clusterroles.yaml and /tmp/roles.yaml and search for rules like:
  3. Decide which roles should keep create on pods
    • For each role/clusterrole you found, decide:
      • Is pod creation truly required for this role’s function?
      • Can the ability be restricted to specific namespaces (use Role instead of ClusterRole)?
      • Can pod creation be delegated to a dedicated automation account instead of broad groups like system:authenticated or system:authenticated:oauth?
    • Document which Role/ClusterRole objects must be tightened and which subjects (users/groups/serviceaccounts) should retain pod-creation rights.
  4. Remove or narrow create permissions on pods in roles/clusterroles
    • To edit a ClusterRole:
    • To edit a namespaced Role:
    • In the opened manifest, locate the rules containing resources: ["pods"] and then:
      • Remove "create" from the verbs list, or
      • If the entire rule is only for pod creation, delete that rule block.
    • Save and exit to apply the change.
  5. Adjust bindings so only intended subjects can create pods
    • List bindings:
    • Edit any binding that grants a pod-creating role to overly broad subjects:
    • Under subjects:, remove or replace broad subjects (for example system:authenticated, large groups) with only those users/groups/serviceaccounts that should still be able to create pods.
  6. Verification
    • Confirm that generic authenticated users can no longer create pods:
    • The output should be canCreatePodsAsSystemAuthenticated: no after remediation.
On any machine with kubectl access:
  1. Identify which RBAC bindings currently allow authenticated users to create pods
Then for each ClusterRole/Role you decide should not be able to create pods:
  1. Remove create from the verbs list on pods (declarative edit)
Example: for a ClusterRole named developer that currently has create on pods, first export it:
Edit developer-clusterrole.yaml and in the relevant rule(s) adjust verbs so create is removed, for example change:
to:
Apply the change:
Repeat this export/edit/apply pattern for each Role/ClusterRole where you want to remove pod creation.
  1. Optionally, break unnecessary subject bindings that grant pod creation
If a specific binding should no longer grant whatever ClusterRole/Role still has pod creation, delete that binding:
Or edit bindings declaratively:
  1. Verification
Run the audit command again from any machine with kubectl access: