Skip to main content

More Info:

Create access to PersistentVolume objects can be used to mount host paths and access node data. Restrict this permission to trusted administrators only.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS EKS

Triage and Remediation

Remediation

Manual Steps

  1. List all principals with PV create rights
    • Run on: any machine with kubectl access
    • Command:
    • Save the resulting ClusterRole names for review.
  2. Review each ClusterRole’s permissions and intended use
    • Run for each ClusterRole name from step 1:
    • Manually confirm:
      • Why this role needs to create persistentvolumes (if at all).
      • Whether it is intended only for cluster administrators or for broader use.
  3. Identify which subjects are bound to those ClusterRoles
    • Run:
    • Or, per role for clarity:
    • Manually assess whether each user/group/service account truly requires PV creation.
  4. Decide and implement RBAC tightening
    For each ClusterRole / subject combination where PV creation is not strictly required:
    • Option A – Remove the binding for non-admin subjects (preferred when only some subjects should lose access):
      • Edit binding:
      • Remove untrusted subjects from .subjects.
    • Option B – Remove PV create from the ClusterRole (only if no remaining subject needs it):
      • Edit role:
      • In rules, remove persistentvolumes from resources or create from verbs, as appropriate.
  5. Optionally create a dedicated admin-only PV role
    • If PV creation is needed only for cluster admins, define a narrowly scoped role and bind it only to trusted administrators:
    • Bind it only to your administrator group or user:
  6. Verify current PV create access after changes
    • Re-run the discovery from step 1 to ensure only intended ClusterRoles retain PV create:
    • Confirm that every remaining role with PV create is explicitly justified and bound only to trusted administrators.
Problem indication: Any ClusterRole or namespaced Role in this list grants create (or *) on persistentvolumes. These are candidates for review; broad or non-admin sounding names (e.g. developer, ci, default, edit, view) are usually problematic.
Problem indication: In the rules section, look for:
  • resources: ["persistentvolumes"] with verbs including create or *.
  • Very wide resources/verbs (e.g. resources: ["*"], verbs: ["*"]) assigned to non-admin use cases.
Problem indication: In each binding’s subjects:
  • Non-admin users/groups (e.g. generic app teams, CI service accounts, default service accounts) bound to roles that can create persistentvolumes.
  • Wildcard or overly broad groups (e.g. system:authenticated) having such roles.
Problem indication: Any role/clusterrole that allows create on persistentvolumes and is bound to non-trusted administrator identities should be flagged for human review and potential restriction.
How to use and what indicates a problem
  • Run the script on any machine with kubectl and access to the cluster.
  • Focus on:
    • ClusterRoles/Rules that include resources: ["persistentvolumes"] and verbs including create.
    • Bindings where those roles are granted to:
      • Wide groups like system:authenticated, system:serviceaccounts, or system:unauthenticated.
      • Namespace default service accounts (e.g. kind: ServiceAccount, name: default).
      • Regular users/groups that are not trusted cluster administrators.
Any such combination (privileged role + broad/non-admin subject) is the condition that needs manual review and likely restriction, per the benchmark.