From d0779881e66c690280ad404c06f930b949f30787 Mon Sep 17 00:00:00 2001 From: Mike Waychison Date: Thu, 19 Jan 2023 15:32:18 -0500 Subject: [PATCH] Further updates to clarify language --- content/en/docs/concepts/security/rbac-good-practices.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md index 621c71e179..b6abde0d74 100644 --- a/content/en/docs/concepts/security/rbac-good-practices.md +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -130,10 +130,10 @@ reading data from other containers, and abusing the credentials of system servic You should only allow access to create PersistentVolume objects for: -- users (cluster operators) that need this access for their work, and who you trust -- the Kubernetes control plane, which creates PersistentVolumes based on PersistentVolumeClaims +- users (cluster operators) that need this access for their work, and who you trust, +- the Kubernetes control plane components which creates PersistentVolumes based on PersistentVolumeClaims that are configured for automatic provisioning. - (Kubernetes usually sets up that access for the control plane when you deploy a cluster). + This is usually setup by the Kubernetes provider or by the operator when installing a CSI driver. Where access to persistent storage is required trusted administrators should create PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage.