Review SCC(Security Context Constraints) based on RBAC in OpenShift v4

As of OpenShift v4.5, SCC(Security Context Constraints) is managed by RBAC, so I review how to work the SCC with RBAC(Role Based Access Control) on OpenShift.

I will check the “users:” sections are not modified after adding “nonroot” SCC to “user1” login account and “test-sa” serviceaccount. And then check if the related RoleBindings or ClusterRoleBinding created for “nonroot” SCC after that. We can see the SCC is managed by RBAC through this test.

And we will verify that a pod can run with “nonroot” with each of “user1” regular account and “test-sa” service account. At that time we does not use cluster-admin granted account which is allowed to use all SCCs for accurate testing.

Let’s check how to SCC is managed by RBAC using above testing details.

WATCH OUT: Don’t customize the default SCCs on OCPv4, it causes unexpected issues on deployment of pods and upgrade process.

Create test Project: “scc-test” and test ServiceAccount: “test-sa”

$ oc whoami
Kube:admin

$ oc new-project scc-test

$ oc create sa test-sa

$ oc get sa test-sa -n scc-test
NAME      SECRETS   AGE
test-sa     2         22s

We can see the current “users:” section of the “nonroot” SCC resource is empty before SCC is configured.

$ oc get scc nonroot -o json | jq '.users'
[]

Grant “nonroot” SCC to “test-sa” service account in a specific project and “user1” regular user in the cluster scope.

$ oc adm policy add-scc-to-user nonroot -z test-sa -n scc-test
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:nonroot added: "test-sa"
$ oc adm policy add-scc-to-user nonroot user1
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:nonroot added: "user1"

Check again whether the “nonroot” SCC resource is changed after changes, we can see no changes there.

$ oc get scc nonroot -o json | jq '.users'
[]

Let’s verify RoleBinding and ClusterRoleBinding which is related with “nonroot” for “test-sa” and “user1” at the next step, we can see the SCC is managed by RBAC.

SCC granted to Service Account in a specific namespace scope

In the case of “test-sa” service account in “scc-test”, it’s binding with “nonroot” through RoleBinding. Because its scope was configured in a specific namespace.

$ oc get rolebinding system:openshift:scc:nonroot -n scc-test
NAME                           ROLE                                       AGE
system:openshift:scc:nonroot   ClusterRole/system:openshift:scc:nonroot   8m38s

$ oc get rolebinding system:openshift:scc:nonroot -n scc-test -o json | jq '.subjects'
[
  {
    "kind": "ServiceAccount",
    "name": "test-sa",
    "namespace": "scc-test"
  }
]

SCC granted to regular user on the cluster scope

In the case of “user1” regular account, SCC is bound through ClusterRolebinding, because the permission granted in cluster scope.

$ oc get clusterrolebinding system:openshift:scc:nonroot
NAME                           ROLE                                       AGE
system:openshift:scc:nonroot   ClusterRole/system:openshift:scc:nonroot   4m19s

$ oc get clusterrolebinding system:openshift:scc:nonroot -o json | jq '.subjects'
[
  {
    "apiGroup": "rbac.authorization.k8s.io",
    "kind": "User",
    "name": "user1"
  }
]

We can see SCC is managed by RBAC through RoleBinding and ClusterRoleBinding now.

Additionally, let’s see how to apply the permission to running Pod as follows.

How to work the SCC on running Pod

When “user2" regular user does not have no SCC permissions, then Pod depends on the “test-sa” service account which is specified on the running Pod.

$ oc adm policy add-role-to-user edit user2
clusterrole.rbac.authorization.k8s.io/edit added: "user2"

$ oc whoami
user2

$ oc create -n scc-test -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: scc-test
spec:
  containers:
  - args:
    - tail
    - -f
    - /dev/null
    image: centos/tools
    name: scc-test
    securityContext:
      runAsUser: 6868
  serviceAccountName: test-sa
EOF

$ oc get pod -n scc-test
NAME       READY   STATUS    RESTARTS   AGE
scc-test   1/1     Running   0          8s

$ oc get pod scc-test -n scc-test -o yaml | grep -w -E 'openshift.io/scc:|serviceAccountName:'
openshift.io/scc: nonroot
serviceAccountName: test-sa
    
$ oc rsh -n scc-test scc-test id
uid=6868(6868) gid=0(root) groups=0(root)

But after switching to “user1” regular user which is granted “nonroot” SCC, and run the Pod with default service account has “restricted” SCC, then the Pod will run using “user1” SCC permission.

$ oc new-project scc-test2

$ oc adm policy add-role-to-user edit user1 -n scc-test2
clusterrole.rbac.authorization.k8s.io/edit added: "user1"

$ oc whoami
user1

$ oc create -n scc-test2 -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: scc-test2
spec:
  containers:
  - args:
    - tail
    - -f
    - /dev/null
    image: centos/tools
    name: scc-test2
    securityContext:
      runAsUser: 6868
EOF

$ oc get pod -n scc-test2
NAME        READY   STATUS    RESTARTS   AGE
scc-test2   1/1     Running   0          10s

$ oc get pod scc-test2 -n scc-test2 -o yaml | grep -w -E 'openshift.io/scc:|serviceAccountName:'
    openshift.io/scc: nonroot
  serviceAccountName: default

$ oc rsh -n scc-test2 scc-test2 id
uid=6868(6868) gid=0(root) groups=0(root)

Even though the service account does not have the “nonroot” SCC, the Pod can run with the the permission through “user1” SCC. That is interesting point on this testing.

Thank you for reading.