add more information on SCC->PSa level mapping

Author: stlaz

enhancements/authentication/pod-security-admission-autolabeling.md

@@ -193,6 +193,74 @@ Given the need for human interaction with PSa check functions when creating the
 SCC-\>PSa mapping, and the complexity of this task, each OpenShift version should
 always ever consider the "latest" PSa checks.
 
+#### Deriving PSa Level from SCC fields
+
+The SCC fields perform different tasks for fields of a security context:
+
+1. restrict the values to a certain value domain
+2. modify the field value in case the field is unset
+3. combination of the above
+4. restrict the values of an already allowed set (e.g. `AllowedFlexVolumes` only
+   further restricts flex volumes allowed by `Volumes` but upstream makes no
+   difference there)
+
+For the conversion between SCC and PSa levels, we are only interested in fields
+that do 1. and 3. The conversion itself needs to make sure that the values allowed
+by SCCs are a subset of the values allowed by the given PSa level in order for the
+SCC to match the PSa level.
+
+**Caveats and Gotchas Found During SCC Mapping Investigation**
+
+1. Currently, there exists no default SCC supplied with the platform that would
+match any PSa level more restricted than `baseline`
+    - the `restricted` (and any dependent) SCC needs to be modified to match the
+      pod security standards of today:
+        - `RequiredDropCapabilities` should now contain just one value - `ALL`
+        - `AllowPrivilegeEscalation` should now be `false`
+2. The SCC to PSa conversion depends on a namespace for the conversion
+    - the `MustRunAs` strategy of `RunAsUser` allows setting an empty range and
+      its evaluation for a given pod retrieves the range from the pod's namespace
+      annotations
+3. The upstream checks can be updated at any time and there is nothing that would
+   allow a simple machine conversion between SCC and PSa levels, this is all human driven
+4. PSa is designed in a way that allows improving security with time if such a need
+   arises
+    - this could mean that our SCCs might slip to less restrictive PSa levels in
+      time
+    - we will need to have a process to tighten SCC permissions that would match
+      the PSa capabilities in this regard
+
+From the above points, we can safely skip 2. as that is just an interesting observation.
+We are evaluating the PSa levels on namespace level anyway when we are checking the
+SCC-related permissions for each of the SA, which are namespaced by nature.
+
+**Addressing 1.** might be a bit hard in order to make sure we prevent workloads from
+breaking. There is no way to add another SCC for the same groups as `restricted`
+has because that would achieve no further enforcement (the `restricted` SCC is
+usable by the `system:authenticated` group).
+
+The above 1. required changes have been requested by the podman team in the past,
+though, and any current reasonable workload should still work even if these more
+restrictive policies are implemented. It is impossible to tell which workloads
+might be broken by this step because most of the platform users very likely just
+went with the platform defaults and did not perform further steps in order to
+tighten their workloads to their actual needs. The proposed solution is therefore
+to simply perform the changes to the SCC. We ship the SCC with the "create-only"
+manifest mode and so the customers might revert them back to the state that's
+working for them as a mitigation.
+
+**For 3**, a process needs to be introduce that allows to simply check the changes to
+the `k8s.io/pod-security-admission/policy` folder during k8s.io rebases. The
+repository containing the SCC conversion should include the commit hash of the
+latest checked version of the `k8s.io/pod-security-admission/policy` folder that
+the current mapping corresponds to and developers will need to manually check that
+no significant changes happened to the folder in between the two rebases that would
+cause updates to checks. If there were, the conversion needs to be updated. In both
+cases, the commit hash should be updated to match the latest checked version of the
+folder.
+
+The **process for 4.** should be drawn in a follow-up enhancement.
+
 ### API Extensions
 
 A new `Namespace` label is being introduced - `security.openshift.io/scc.podSecurityLabelSync`.
@@ -203,6 +271,7 @@ section.
 
 ### Risks and Mitigations
 
+#### PSa Label Synchronization Risks
 Turning on the PSa to restricted level enforcing even with the namespace label
 synchronization described in this enforcement brings the risk of breaking direct
 pod application for pods that don't rely on SA permissions, i.e. pods created
@@ -218,6 +287,19 @@ the labels are properly synchronized on their namespace. There is no way to
 mitigate that, the pods will eventually succeed to be created if the given
 service account running them has the correct permissions.
 
+#### Restricted SCC Change Risks
+
+The `restricted` SCC and its variations (e.g. `nonroot`) need to be changed
+in order to match the current pod security standards (see [Deriving PSa Level from SCC fields](#deriving-psa-level-from-scc-fields)
+for details on the changes).
+
+This may cause some workloads to break. Such failures should however be very rare
+since most restricted workloads have been adjusted through time to being able
+to work without the privilege escalation bit and with all capabilities being dropped.
+
+The SCCs we provide allow modifications and so if this is causing workloads to break,
+users should be able to turn the change back as a mitigation.
+
 ## Design Details
 
 ### Open Questions