Update RBAC Good Practices for PersistentVolumes

The docs previously referred to the reader to the now defunct PodSecurityPolicy
page to explain how PersistentVolumes can be a path of privilege escalation,
burrying the lede.

Now that PodSecurityPolicy is gone, update this bit to actually explain that it
it is unfettered access to creating hostPath-typed PersistentVolumes that are
a problem. Some words lifted from the 1.24 PodSecurityPolicy docs.

Signed-off-by: Mike Waychison <[email protected]>

Author: waych

content/en/docs/concepts/security/rbac-good-practices.md

@@ -121,8 +121,12 @@ considered weak.
 
 ### Persistent volume creation
 
-As noted in the [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/#volumes-and-file-systems)
-documentation, access to create PersistentVolumes can allow for escalation of access to the underlying host.
+Creation of PersistentVolumes includes creation of `hostPath`-typed volumes, providing access to the underlying host filesystem.
+
+There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including 
+reading data from other containers, and abusing the credentials of system services, such as Kubelet.
+
+Only trusted users should be granted permission to create PersistentVolume objects.
 Where access to persistent storage is required trusted administrators should create 
 PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage.