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
MediumAddress
SecurityCompliance Standards
- CIS EKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all principals with PV create rights
- Run on: any machine with kubectl access
- Command:
- Save the resulting ClusterRole names for review.
-
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.
- Why this role needs to create
- Run for each ClusterRole name from step 1:
-
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.
- Run:
-
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.
- Edit binding:
- Option B – Remove PV create from the ClusterRole (only if no remaining subject needs it):
- Edit role:
- In
rules, removepersistentvolumesfromresourcesorcreatefromverbs, as appropriate.
- Edit role:
- Option A – Remove the binding for non-admin subjects (preferred when only some subjects should lose access):
-
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:
- If PV creation is needed only for cluster admins, define a narrowly scoped role and bind it only to trusted administrators:
-
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.
- Re-run the discovery from step 1 to ensure only intended ClusterRoles retain PV
Using kubectl
Using kubectl
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.rules section, look for:resources: ["persistentvolumes"]withverbsincludingcreateor*.- Very wide resources/verbs (e.g.
resources: ["*"],verbs: ["*"]) assigned to non-admin use cases.
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.
create on persistentvolumes and is bound to non-trusted administrator identities should be flagged for human review and potential restriction.Automation
Automation
- Run the script on any machine with
kubectland access to the cluster. - Focus on:
- ClusterRoles/Rules that include
resources: ["persistentvolumes"]andverbsincludingcreate. - Bindings where those roles are granted to:
- Wide groups like
system:authenticated,system:serviceaccounts, orsystem:unauthenticated. - Namespace default service accounts (e.g.
kind: ServiceAccount,name: default). - Regular users/groups that are not trusted cluster administrators.
- Wide groups like
- ClusterRoles/Rules that include

