Description of problem: High level: Currently ties between two competing SCCs (i.e. ones that have same priority) are resolved by examining their restriction score based on points. A reason message is generated in event logs to introspect why a given restriction was chosen. We found a bug in the number ranges of restriction scores which leads to wrong tie resolving reason messages. For example, given the following SCC which competes against the out of the box "anyuid" SCC: apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: anyuid-competitor allowHostDirVolumePlugin: false allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegeEscalation: false allowPrivilegedContainer: false allowedCapabilities: null defaultAddCapabilities: null priority: 10 readOnlyRootFilesystem: false fsGroup: type: MustRunAs runAsUser: type: MustRunAsRange seLinuxContext: type: MustRunAs supplementalGroups: type: RunAsAny users: [] volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secret requiredDropCapabilities: - KILL - MKNOD - SETUID - SETGID We get the following actual reasoning: "anyuid-competitor" is most restrictive, not denied, and chosen over "anyuid" because "anyuid-competitor" forbids host volume mounts This assertion is false because both SCCs forbid host volume mounts. What we rather expect is the reasoning to be based on more restricted runAs restrictions in the "anyuid-competitor" SCC.
@surbania it's noticed https://github.com/openshift/apiserver-library-go/pull/60/files is not bumped into 4.9 release, could you help to check?
@liya: please verify your build contains the following commit: https://github.com/openshift/kubernetes/commit/687a5bf8293aad12e1e93eac7bafe58b19ab9b51 The bump happened in openshift/kubernetes.
First tried to reproduce in unfixed version, e.g. 4.8.0-0.nightly-2021-09-22-010115: oc create -f scc_anyuid-competitor.yaml # its content is shown in above comment PROJ=test-proj oc adm new-project $PROJ oc adm policy add-scc-to-user anyuid -z default -n $PROJ oc adm policy add-scc-to-user anyuid-competitor -z default -n $PROJ PATTERN="\"requestURI\":\"[^ ]*/$PROJ/pods\"" MASTERS=`oc get no | grep master | grep -o '^[^ ]*'` NOW=$(date -u "+%s"); echo "$NOW"; echo "$NOW" > now # creating pod against SCCs oc new-app openshift/hello-openshift -n $PROJ # then check the /var/log/kube-apiserver/audit*.log for records of "$PATTERN": for i in $MASTERS; do oc debug no/$i -- chroot /host bash -c "grep -hE '$PATTERN' /var/log/kube-apiserver/audit*.log || true" done | jq -c 'select (.requestReceivedTimestamp | .[0:19] + "Z" | fromdateiso8601 > '"`cat now`)" > var_log_kube-apiserver_audit_pattern.log Open var_log_kube-apiserver_audit_pattern.log, can see: {"kind":"Event",...,"requestURI":"/api/v1/namespaces/test-proj/pods","verb":"create","user":{"username":"system:serviceaccount:kube-system:replicaset-controller",...,"annotations":{...,"securitycontextconstraints.admission.openshift.io/reason":"\"anyuid-competitor\" is most restrictive, not denied, and chosen over \"anyuid\" because \"anyuid-competitor\" forbids host volume mounts",...}} ^^^ This reproduces the issue in unfixed version. Then repeat above steps in 4.9.0-0.nightly-2021-09-21-215600, got: {"kind":"Event",...,"requestURI":"/api/v1/namespaces/non-destructive-test-proj/pods","verb":"create","user":{"username":"system:serviceaccount:kube-system:replicaset-controller",...,"annotations":{...,"securitycontextconstraints.admission.openshift.io/reason":"\"anyuid-competitor\" is most restrictive, not denied, and chosen over \"anyuid\" because \"anyuid-competitor\" permits less runAs strategies",...}} ^^^ The "securitycontextconstraints.admission.openshift.io/reason" is fixed with right reason.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.9.0 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:3759