
If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.
A Security Context Constraint is used to control certain things, such as:
- Whether or not a pod can be run as root
- Whether or not a pod can access the host OpenShift system
- Whether or not a pod can access the host OpenShift network
Typically, a Deployment is associated with a Service Account which has a certain Security Context Constraint (SCC) so that the pod runs with a certain Security Context Constraint (SCC).
By default, if a pod is not associated with a specific Service Account that has been bound to a certain Security Context Constraint, the pod will have the restricted Security Context Constraint, which can be seen using the oc describe pod command.
~]$ oc describe pod my-app-kf7hf
Annotations: openshift.io/scc: restricted
The oc get securitycontextconstraints command can be used to see that the restricted Security Context Constraint has MustRunAsRange. Typically, the user running the pod ID must be between 1000910000 and 1000919999.
~]$ oc get securitycontextconstraints restricted
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES
restricted false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
Let's update the deployment YAML with securityContext runAsUuser: 0 to the pod as root.
spec:
template:
spec:
securityContext:
runAsUser: 0
This should cause unable to validate against any security context constraint to be returned. Let's remove securityContext runAsUuser: 0 from the deployment YAML.
Error creating: pods "my-deployment-" is forbidden:
unable to validate against any security context constraint: [
spec.containers[0].securityContext.runAsUser: Invalid value: 0: must be in the ranges: [1000910000, 1000919999]
Forbidden: not usable by user or serviceaccount, provider "anyuid"
Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid"
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, provider "nonroot"
Forbidden: not usable by user or serviceaccount, provider "privileged"
Forbidden: not usable by user or serviceaccount, provider "restricted"
]
The oc adm policy scc-subject-review command shows the deployment wants to use the anyuid Security Context Constraint. But by default, pods have the restricted Security Context Constraint. What to do?
~]$ oc get deployment my-deployment --output yaml | oc adm policy scc-subject-review -f -
RESOURCE ALLOWED BY
Deployment/my-deployment anyuid
The oc adm policy scc-review command shows that no Service Accounts are associated with the pod. This is why the pod is defaulting to the restricted Security Context Constraint.
~]$ oc get pod my-app-kf7hf --output yaml | oc adm policy scc-review -f -
RESOURCE SERVICE ACCOUNT ALLOWED BY
Let's create a Service Account.
~]$ oc create serviceaccount my-service-account
serviceaccount/my-service-account created
Then associate the Service Account with a Security Context Contraint (SCC). In this example, it makes sense to associate the Service Account with the anyuid Security Context Constraint since the oc adm policy scc-subject-review command returned anyuid.
~]$ oc adm policy add-scc-to-user anyuid -z my-service-account
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "my-service-account"
The oc describe clusterrolebinding command can be used to validate that the service account is bound to the anyuid Security Context Constraint.
~]$ oc describe clusterrolebinding system:openshift:scc:anyuid
Name: system:openshift:scc:anyuid
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: system:openshift:scc:anyuid
Subjects:
Kind Name Namespace
---- ---- ---------
ServiceAccount my-service-account my-project
Then the oc set serviceaccount command can be used to have a deployment / pod run by the Service Account which will apply the Security Context Contraint (SCC) to the container / deployment / pod.
~]$ oc set serviceaccount deployment/my-deployment my-service-account
deployment.apps/my-deployment serviceaccount updated
the oc set serviceaccount command will update the deployment YAML to have serviceAccount and serviceAccountName.
spec:
template:
spec:
serviceAccount: my-service-account
serviceAccountName: my-service-account
Now the oc adm policy scc-review command shows that the pod has the Service Account and the anyuid Security Context Contraint (SCC).
~]# oc get pod my-app-mkfjk --output yaml | oc adm policy scc-review -f -
RESOURCE SERVICE ACCOUNT ALLOWED BY
Pod/my-app-mkfjk my-service-account anyuid
And of course the oc adm policy scc-subject-review command still shows the deployment wants to use the anyuid Security Context Constraint. But this is just nice to see, where both scc-review and scc-subject-review have the same SCC.
~]$ oc get deployment my-app --output yaml | oc adm policy scc-subject-review -f -
RESOURCE ALLOWED BY
Deployment/my-app anyuid
And now the oc describe pod command should show that the pod has the anyuid Security Context Contraint.
~]$ oc describe pod my-app-mkfjk
Annotations: openshift.io/scc: anyuid
Did you find this article helpful?
If so, consider buying me a coffee over at