The new PSA controller works by applying labels to namespaces in K8S. Those labels can prevent a user from launching pods onto the cluster that do not conform to the policy indicated in the label. Therefore, confirming that different controls in the benchmark are being followed is pretty much just a question of "are the namespaces all labeled appropriately."
Details on what settings are enforced by a particular policy are given by a the Pod Security Standards page. (Both the benchmark and K8S documentation seem to use "pod security standard" and "policy" interchangeably.)
Ultimately, there are only three policies in off-the-shelf K8S --
privileged, which doesn't restrict what is launched into the namespace at all
baseline, which has some basic controls in place
restricted, which heavily limits what pod settings can be set
So the controls in 4.2.X are all asking the basic question "are all the namespaces properly labeled to either baseline or restricted?" Some controls, though, require a setting that is only enforced by the restricted policy, so functionally, a cluster will only pass the benchmark if all of its namespaces are set to enforce the restricted policy. There do not appear to be exceptions in the benchmark for K8S's default namespaces.
I added a few more inputs to inspec.yaml as well. Two are caveat lists where the user can list namespaces that are allowed to be labeled as privileged or baseline, since that will almost certainly be necessary in a real cluster. There's also an input where the user can indicate that they are using some separate security policy enforcement agent, as @ejaronne and I discussed, because even the K8S docs mention that you might want to do that (and this is probably why the benchmark keeps referring to the general term policies even though default K8S calls them "Pod Security Standards"). If the user sets the input that says they are using a third party enforcement mechanism for pod security, all of the 4.2.X controls become manual checks.
Updated controls to use new Pod Security Admission (PSA) methods from K8S v1.23+.
The new PSA controller works by applying labels to namespaces in K8S. Those labels can prevent a user from launching pods onto the cluster that do not conform to the policy indicated in the label. Therefore, confirming that different controls in the benchmark are being followed is pretty much just a question of "are the namespaces all labeled appropriately."
Details on what settings are enforced by a particular policy are given by a the Pod Security Standards page. (Both the benchmark and K8S documentation seem to use "pod security standard" and "policy" interchangeably.)
Ultimately, there are only three policies in off-the-shelf K8S --
So the controls in 4.2.X are all asking the basic question "are all the namespaces properly labeled to either baseline or restricted?" Some controls, though, require a setting that is only enforced by the restricted policy, so functionally, a cluster will only pass the benchmark if all of its namespaces are set to enforce the restricted policy. There do not appear to be exceptions in the benchmark for K8S's default namespaces.
I added a few more inputs to
inspec.yamlas well. Two are caveat lists where the user can list namespaces that are allowed to be labeled as privileged or baseline, since that will almost certainly be necessary in a real cluster. There's also an input where the user can indicate that they are using some separate security policy enforcement agent, as @ejaronne and I discussed, because even the K8S docs mention that you might want to do that (and this is probably why the benchmark keeps referring to the general term policies even though default K8S calls them "Pod Security Standards"). If the user sets the input that says they are using a third party enforcement mechanism for pod security, all of the 4.2.X controls become manual checks.