user namespaces: clarify PSS privileged requirement for container-in-…

…pod SCC

Signed-off-by: Peter Hunt <pehunt@redhat.com>

enhancements/kubelet/user-namespaces-support.md

@@ -155,7 +155,7 @@ Since user namespaces allow a process to gain access to the capabilities needed
 to the proposal of adding user namespaces generally.
 
 This SCC will largely mirror the `restricted-v2` SCC, but have a couple of changes.
-- SELinux context set to MustRunAs.Type: `container_engine_t`
+- SELinux context set to MustRunAs.SeLinuxOptions.Type: `container_engine_t`
     - This SELinux type has been developed to allow the majority of podman in pod situations, and can
       continue to be adapted without affecting the normal `container_t` which should be more restrictive.
 - RunAsUserStrategy: RunAsAny
@@ -165,6 +165,12 @@ This SCC will largely mirror the `restricted-v2` SCC, but have a couple of chang
       not on the host. Thus, even for a less trusted user, the capabilities should be safe to access.
 - AllowHostUser set to Disallowed
 
+Note: to use this SCC, the namespace must be labeled as `privileged` in Pod Security Standards. This is in part because
+PSS doesn't recognized `container_engine_t` [yet](https://github.com/kubernetes/kubernetes/pull/126165), and in part because
+the baseline policy doesn't allow Unmasked procMount, even if the pod is in a user namespace, [yet](https://github.com/kubernetes/kubernetes/pull/126163).
+
+The goal is to fix these in Kubernetes 1.31, and Openshift 4.18.
+
 #### Feature Gates and Sets
 
 There are three feature gates of note for this enhancement: `UserNamespacesSupport`, `UserNamespacesPodSecurityStandards`, and `ProcMountType`.