Skip to main content

How to manage service accounts and security context constraints in OpenShift

Learn how to configure service account access restrictions and security context constraints (SCCs) to control permissions for pods.
Red and yellow doors on a brick building

Photo by Robert Anasch on Unsplash

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
Tokens:              sa-demo-token-lt7h8
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
  name: scc-admin
allowPrivilegedContainer: true
  type: RunAsAny
  type: RunAsAny
  type: RunAsAny
  type: RunAsAny
- sa-demo   # service account
requiredDropCapabilities:  # disallow these docker capabilities

Process the YAML file with oc create:

$ oc create -f scc-admin.yaml 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
  Users:				sa-demo   #service account
  Groups:				none
  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.

Topics:   OpenShift   Cloud   Security   Kubernetes  
Author’s photo

Robert Kimani

Robert is a Linux enthusiast and an open source advocate, currently transitioning into a site reliability engineering (SRE) role. Always striving to learn more, he's pursuing Red Hat Certified Architect - Infrastructure path certification. Besides his love for Linux, he believes in helping others More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.