How to manage service accounts and security context constraints in OpenShift

Kubernetes and OpenShift utilize user accounts and service accounts. The difference is simple: User accounts are for humans, and service accounts are for processes. In my previous article, I demonstrated how to use a service account and security context constraints (SCCs) to ensure that a pod has sufficient permissions to run system-level processes. This article discusses using and managing service accounts and SCCs.

Service accounts exist within a project, and each service account username is derived from its project. Every service account is a member of two groups:

• system:serviceaccount includes all service accounts in the system.
• system:serviceaccount:<project> includes all service accounts in the specified project.

Use the oc command to view all service accounts within your current project:

$ oc get sa

If you are not querying the active project, use the -n option to specify the project or namespace.

Use oc create sa along with an arbitrary name to create a service account:

$ oc create sa sa-demo
serviceaccount/sa-demo created

View details about the service account using the describe subcommand:

Name:                sa-demo
Namespace:           default
Labels:              none
Annotations:         none
Image pull secrets:  sa-demo-dockercfg-wx9mw
Mountable secrets:   sa-demo-token-zm6jh
                     sa-demo-dockercfg-wx9mw
Tokens:              sa-demo-token-lt7h8
                     sa-demo-token-zm6jh
Events:              none

Configure service account access restrictions

After creating a service account, use a role binding to connect the account to a specific role or bind it with a specific SCC. To grant a role to a service account for your active project, type:

$ oc adm policy add-role-to-user <role> \ 
system:serviceaccount:<project name>:<service account>

[ Learn Kubernetes basics in this cheat sheet. ]

Use security context constraints

An SCC is an OpenShift resource that restricts a pod to a group of resources and is similar to the Kubernetes security context resource. The primary purpose of both is to limit a pod's access to the host environment. You can use an SCC to control pod permissions, similar to how you use role-based access control (RBAC) to manage user privilege.

You can use an SCC to define a set of conditions a pod must use when running. This capability allows you to control things like whether a pod can run privileged containers, the capabilities a container can request, the SELinux context of a container, the usage of volume types, and so on.

[ Improve your skills managing and using SELinux with this helpful guide. ]

Create a custom SCC

You can create an SCC like any other resource: With a YAML file. Here is an example:

---
kind: SecurityContextConstraints
apiVersion: security.openshift.io/v1
metadata:
  name: scc-admin
allowPrivilegedContainer: true
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
fsGroup:
  type: RunAsAny
supplementalGroups:
  type: RunAsAny
users:
- sa-demo   # service account
requiredDropCapabilities:  # disallow these docker capabilities
- KILL
- MKNOD
- SYS_CHROOT

Process the YAML file with oc create:

$ oc create -f scc-admin.yaml
securitycontextconstraints.security.openshift.io/scc-admin created

To view details about the security context constraint you've just created, use oc get:

$ oc get scc | grep scc-admin
scc-admin     true    <no value>   RunAsAny    RunAsAny           RunAsAny    RunAsAny    <no value>   false          ["awsElasticBlockStore","azureDisk","azureFile","cephFS","cinder","configMap","csi","downwardAPI","emptyDir","ephemeral","fc","flexVolume","flocker","gcePersistentDisk","gitRepo","glusterfs","iscsi","nfs","persistentVolumeClaim","photonPersistentDisk",[…]

You can see even more detail with oc describe:

$ oc describe scc scc-admin
Name:					scc-admin
Priority:				none
Access:					
  Users:				sa-demo   #service account
  Groups:				none
Settings:				
  Allow Privileged:		true
  Allow Privilege Escalation:	true
  Default Add Capabilities:	none
  Required Drop Capabilities:	KILL,MKNOD,SYS_CHROOT
  [...]
  SELinux Context Strategy: RunAsAny		
    User:					none
    Role:					none
    Type:					none
    Level:					none
  FSGroup Strategy: RunAsAny			
    Ranges:					none
  Supplemental Groups Strategy: RunAsAny	
    Ranges:					none

Service accounts and SCCs

Service accounts and SCCs are important ways of managing permissions within a cluster. OpenShift has plenty of methods to query your projects and cluster to learn about resources, so get familiar with the available commands and constructs.

You can further explore the various SCC options by reading the OpenShift SCC documentation. Particularly useful topics include controlling a container's SELinux context, requesting additional capabilities to a container, changing the user ID, and using host directories as volumes.