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.
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.
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.
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
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 -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 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 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.
Learn how to change a default security context constraint (SCC) in OpenShift to manage permissions within a cluster.
Go beyond OpenShift's default options to set up custom role-based access control (RBAC) permissions for local and cluster roles.
Sometimes the process to delete Kubernetes namespaces gets hung up, and the command never completes. Here's how to troubleshoot terminating namespaces