OpenShift - Run a deployment with a Service Account and Security Context Constraint

If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

Role Bindings and Security Context Constraint are similar in that they both are access control mechanisms.

  • Role Bindings are used to control what an OpenShift Users are allowed to do
  • Security Context Constraints are used to control what pods are allowed to do

A Security Context Constraint is used to control certain things that a deployment or pod is allowed or not allowed to do, such as mounting a host volume. Typically, a Security Context Constraint (SCC) is associated with a Service Account.

Let's say you have created a Service Account named my-service-account.

~]$ oc create serviceaccount my-service-account
serviceaccount/my-service-account created


The oc get serviceaccounts (or just oc get sa) command can be used to list the Service Accounts that have been created in the current project / namespace.

~]$ oc get serviceaccounts
NAME                  SECRETS   AGE
default               2         388d
my-servie-account     2         112s


The oc describe serviceaccount command can be used to show more details of a specific Service Account.

~]$ oc describe serviceaccount my-service-account
Name:                my-service-account
Namespace:           my-project
Labels:              <none>
Annotations:         <none>
Image pull secrets:  my-service-account-dockercfg-57b6r
Mountable secrets:   my-service-account-token-sfrpr
Tokens:              my-service-account-token-6x45k
Events:              <none>


Before you update a container in a deployment with the Service Account, you want to associate the Service Account with a Security Context Contraint (SCC)

~]$ oc adm policy add-scc-to-user restricted -z my-service-account added: "my-service-account"


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


Or, you could use the oc edit or oc patch command to update the deployment YAML file.

~]$ oc patch deployment my-deployment --patch '{"spec":{"template":{"spec":{"serviceAccount":"my-service-account","serviceAccountName":"my-service-account"}}}}'


This command will update the deployment YAML to have the serviceAccount and serviceAccountName keys. 

      serviceAccount: my-service-account
      serviceAccountName: my-service-account


And then this one liner can be used to see that the deployment has the Service Account and the restricted Security Context Contraint (SCC).

~]# oc get deployment my-app --output yaml | oc adm policy scc-review --filename - 
RESOURCE                    SERVICE ACCOUNT       ALLOWED BY         
Deployment/my-deployment    my-service-account    restricted


The oc get pods command can be used to see that a new pod should be created.

~]$ oc get pods
NAME                  READY   STATUS      RESTARTS   AGE
my-deployment-mkfjk   1/1     Running     0          4m46s


The oc describe pod command should show that the pod has the restricted Security Context Contraint.

~]$ oc describe pod my-deployment-mkfjk
Name:         my-deployment-mkfjk
Namespace:    my-project
Annotations: restricted


Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee

Add a Comment

We will never share your name or email with anyone. Enter your email if you would like to be notified when we respond to your comment.

Please enter d66e9 in the box below so that we can be sure you are a human.