Bug 1977920

https://github.com/awels/hostpath-provisioner-operator/blob/master/pkg/controller/hostpathprovisioner/scc.go#L112 is an affected SCC

Tested in cluster 4.9.0-0.nightly-2021-07-02-002856
1. create new SCC without 'projected' volume type
$ oc get scc hostaccess -o yaml > myscc.yaml
$ sed -i -e "/- projected/d" -e "s/hostaccess/myscc/" myscc.yaml
$ oc create -f myscc.yaml

2. add the new SCC to SA default
$ oc login -u testuser
$ oc new-project test
$ oc adm policy add-scc-to-user myscc -z default -n test --context admin

3. create pod and check whether pod can be launched successfully
$ cat > pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  containers:
  - image: quay.io/openshifttest/hello-pod:latest
    name: testpod
    volumeMounts:
    - mountPath: /host
      name: myvolume
  volumes:
  - hostPath:
      path: /
    name: myvolume
EOF
$ oc create -f pod.yaml 

when using old build, error is returned
Error from server (Forbidden): error when creating "pod.yaml": pods "testpod" is forbidden: unable to validate against any security context constraint: [provider "anyuid": Forbidden: not usable by user or serviceaccount, spec.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount, provider "hostnetwork": Forbidden: not usable by user or serviceaccount, provider "hostaccess": Forbidden: not usable by user or serviceaccount, spec.volumes[1]: Invalid value: "projected": projected volumes are not allowed to be used, provider "node-exporter": Forbidden: not usable by user or serviceaccount, provider "privileged": Forbidden: not usable by user or serviceaccount]

when using new build, pod can be launched with running status
$ oc get pods -n test
NAME      READY   STATUS    RESTARTS   AGE
testpod   1/1     Running   0          33m

add test whether projected volume type is added or not when 'secret' and 'projected' volume type are both removed from the custom SCC yaml
$ oc get scc hostaccess -o yaml > myscc1.yaml
$ sed -i -e "/- projected/d" -e "/- secret/d" -e "s/hostaccess/myscc1/" myscc1.yaml
$ oc create -f myscc1.yaml 
securitycontextconstraints.security.openshift.io/myscc1 created
$ oc get scc myscc1 -o yaml
/****snipped****/
volumes:
- configMap
- downwardAPI
- emptyDir
- hostPath
- persistentVolumeClaim

check the result, projected volume type is not added as expected

(In reply to liyao from comment #6)
> add test whether projected volume type is added or not when 'secret' and
> 'projected' volume type are both removed from the custom SCC yaml
> $ oc get scc hostaccess -o yaml > myscc1.yaml
> $ sed -i -e "/- projected/d" -e "/- secret/d" -e "s/hostaccess/myscc1/"
> myscc1.yaml
> $ oc create -f myscc1.yaml 
> securitycontextconstraints.security.openshift.io/myscc1 created
> $ oc get scc myscc1 -o yaml
> /****snipped****/
> volumes:
> - configMap
> - downwardAPI
> - emptyDir
> - hostPath
> - persistentVolumeClaim
> 
> check the result, projected volume type is not added as expected

What is this test for? I don't believe there was ever an expectation of automatic addition of 'projected' to an scc's volume sources.

(In reply to Maru Newby from comment #7)
> (In reply to liyao from comment #6)
Maru Newby, you're right. I looked at the PR's comment, thought the fix was to automatic support 'projected' by adding it in SCC object when 'secret' is present, thus did not look into the PR code of multiple files. Now looking into pkg/securitycontextconstraints/sccmatching/provider.go & pkg/securitycontextconstraints/util/util.go , got to know original thought is not true after checking the implemented changes in ValidatePodSecurityContext, allowsVolumeType, allowedVolumes functions and IsOnlyServiceAccountTokenSources.

Thus a minor negative test for comment 6 would be: using steps of comment 5 but using SCC of comment 6, the pod would still not be run, as same as before (i.e. this bevior is not affected by the PRs)

No doc update required - this was a bug introduced and fixed in 4.8 prior to release.

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