Using the legacy restricted SCC in OCP 4.11+

Updated -

In OpenShift 4.11, if a cluster is freshly installed, the "restricted-v2" SCC replaces "restricted" as the SCC that can be used to run workloads by any authenticated user. For clusters upgraded from previous versions, both the "restricted" and "restricted-v2" SCCs coexist, although the "restricted-v2", being the more restrictive, will have priority during SCC admission evaluation. To read more about the change, see the 4.11 release notes.

This article describes how to mitigate issues that might be caused by the changes described above.

Why you would need to add this permission

I need to allow my users to be able to run workloads that will not function when “restricted-v2” SCC matches their specification for one of the following reasons:

Why you should consider granting permissions per workload instead

The “restricted-v2” SCC includes a minimal set of privileges that are usually necessary for a generic workload to run. It is the most restrictive policy that matches the current pod security standards. Any workload requiring more permissions should be explicitly allowed by the cluster administrator who should review if more permissiveness is really necessary for the given workload.

How to allow usage of the restricted SCC by all users

Using the restricted SCC is not bad, it’s just not as tightly scoped as restricted-v2 and corresponds to Kubernetes “baseline”. If you want to have your freshly installed 4.11+ cluster admit the same pods that 4.10 would have admitted, you can grant access to the restricted SCC to all authenticated users, by creating a ClusterRoleBinding like this

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:openshift:scc:restricted
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:openshift:scc:restricted
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

or running a command like this

oc create clusterrolebinding system:openshift:scc:restricted --clusterrole=system:openshift:scc:restricted --group=system:authenticated

Note that since the “restricted-v2” SCC is more restrictive than the “restricted” SCC, it is evaluated first and if the security context of the pod being evaluated can be matched against it, it will. Therefore, you need to specifically set the “allowPrivilegeEscalation” security context field to “true”, which makes the “restricted-v2” SCC not match your workload, but makes the “restricted” SCC match instead.

How to allow usage of the restricted SCC by service accounts in a particular namespace

To only allow users using the “restricted” SCC in a particular namespace, you can create a rolebinding like the following:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: scc:restricted:users
  namespace: <namespace_name>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:openshift:scc:restricted
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:<namespace_name>

or by running a command like this:

oc create rolebinding local:scc:restricted -n <namespace_name> --clusterrole=system:openshift:scc:restricted  --group=system:serviceaccounts:<namespace_name>

Comments