Hello,

As many of you know we (Auth and API team) are working hard towards enabling pod security admission (https://kubernetes.io/docs/concepts/security/pod-security-admission/) using the “restricted” profile by default (https://kubernetes.io/docs/concepts/security/pod-security-standards/) for OpenShift 4.11.

We came to a point where we were able to install a cluster successfully and are now working towards passing e2e. We had to submit many changes throughout many repositories and we are very thankful for your quick reviews and merges.
Right now we are focussing on passing e2e tests in origin but we will probably miss quite some corner cases or won’t hit optional e2e tests executed in your environment.

This is where we are asking you to take ownership of changing your manifests to be compliant with the upcoming pod security admission. The following procedure can be used to analyse whether you need to take action:
Verify if your workload needs updates. This can be done by either

introspecting client-go warnings in your log files or
introspecting audit log entries using oc adm must-gather – /usr/bin/gather_audit_logs. Pod Security Admission violations will result in something like:

pod-security.kubernetes.io/audit-violations”: “would violate PodSecurity \“restricted:latest\“: allowPrivilegeEscalation != false (container \“agnhost-container\” must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \“agnhost-container\” must set securityContext.capabilities.drop=[\“ALL\“]), runAsNonRoot != true (pod or container \“agnhost-container\” must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \“agnhost-container\” must set securityContext.seccompProfile.type to \“RuntimeDefault\” or \“Localhost\“)”

This indicates that your workload would violate the “restricted” pod security profile which is going to be enabled in OpenShift 4.11 by default. From here you have the following choices:

If your workload can stay restricted: Most workloads can be made compliant by the following simple changes: https://github.com/openshift/cluster-openshift-controller-manager-operator/pull/240/files (random simple example)
If your workload has to be privileged: Label the namespace of your workload to allow privileged execution, random simple example: https://github.com/openshift/cluster-kube-apiserver-operator/pull/1234/files
If you already labelled your namespace for enforcing a pod security profile, add “audit” and “warn” labels as well to get rid of the warnings, example (same as above): https://github.com/openshift/cluster-kube-apiserver-operator/pull/1234/files
If you are in doubt: Use our tool “psachecker” to assert your workload in a running cluster (using the inspect-cluster subcommand) or a local manifest (using the inspect-workloads subcommand): https://github.com/stlaz/psachecker

QE is going to try to find failing workloads and will submit blocker+ BZs targetted at 4.11.

For more information, don’t hesitate to reach out to us (@team-auth in #forum-apiserver) and have a look at the following enhancements:

https://github.com/openshift/enhancements/blob/master/enhancements/authentication/pod-security-admission.md
https://github.com/openshift/enhancements/blob/master/enhancements/authentication/pod-security-admission-autolabeling.md

Thank you,
Auth and API Team