What are security contexts and security context constraints?

Red Hat OpenShift includes a pair of security features, security contexts and security context constraints, that allow containerized applications to access protected Linux functionality. This article introduces security contexts (SCs) and security context constraints (SCCs) and explains how they solve access problems in container environments.

A pod configures a container’s access with permissions requested in the pod’s security context and approved by the cluster’s security context constraints:

A security context (SC), defined in a pod level, enables a deployer to specify a container’s permissions to access protected functions. When the pod creates the container, it configures the container to allow these permissions and block all others. The cluster will only deploy the pod if the permissions it requests are allowed by a corresponding SCC.

A security context constraint (SCC), defined in a cluster level, enables an administrator to control permissions for pods, permissions that manage containers’ access to protected Linux functions. Similarly to how role-based access control (RBAC) manages users’ access to a cluster’s resources, an SCC manages pods’ access to Linux functions. By default, a pod is assigned an SCC named restricted that blocks access to protected functions. For an application to access protected functions, the cluster must make an SCC that allows it to be available to the pod.

Note: SCC enforcement is implemented using SELinux and AppArmor, security modules that are included in the kernel of both Red Hat Enterprise Linux (RHEL) and Red Hat Enterprise Linux CoreOS (RHCOS). The nodes in an OpenShift v4 cluster can only run on one of Red Hat’s Linux distributions, guaranteeing that the kernel will include those modules.

By default, OpenShift prevents the containers running in a cluster from accessing protected functions. These functions — Linux features such as shared file systems, root access, and some core capabilities such as the KILL command -- can affect other containers running in the same Linux kernel, so the cluster limits access to them. Most cloud-native applications work fine with these limitations, but some (especially stateful workloads) need greater access. Applications that need these functions can still use them, but they need the cluster's permission.

The application’s security context specifies the permissions that the application needs, while the cluster’s security context constraints specify the permissions that the cluster allows. An SC with an SCC enables an application to request access while limiting the access that the cluster will grant.

How a pod requests additional access

While an SCC grants access to protected functions, each pod that wants to use that access must request it. To request access to the functions its application needs, a pod specifies those permissions in the security context field of the pod manifest. The manifest also specifies the service account that should be able to grant this access. When the manifest is deployed, the cluster associates the pod with the service account, which is associated with the SCC. For the cluster to deploy the pod, the SCC must grant the permissions that the pod requests.

See the below yaml to understand service account, pod SC, and container SC.

• serviceAccountName is default. You can change this later.
• securityContext for the pod was given seLinuxOptions and an fsGroup setting.
• securityContext for the container was given some specific capabilities to drop and a runAsUser. These are also from the project defaults. Notice that the container's runAsUser is the same as the pod's fsGroup.

Example: Please see the below pod yaml to understand how SC and SCC are defined…

One way to visualize this relationship is to think of the SCC as a lock that protects Linux functions, while the manifest is the key. The pod is allowed to deploy only if the key fits.

Fig:01

The diagram shows a deployment that is blocked by the SCC on the left and is allowed by the SCC on the right. In both examples, the pod specifies in its security context that it needs access to two permissions arbitrarily labeled P2 and P5. In the first example, a very restrictive SCC does not grant the access the manifest requests in its security context, so the cluster refuses to deploy the pod. In the second example, a custom SCC does grant the access the manifest requests in its security context, so the cluster proceeds with deploying the pod.

Deployment scenario showing the permissions approval flow

It time to understand how SCCs control access works on an OpenShift cluster, let’s walk through a deployment scenario so you can see how the cluster’s admission process uses the deployment manifest, service account, and SCC together to determine whether to deploy a pod.

Fig: 02

Above diagram illustrates the deployment process flow…

• The developer implements an application or service that requires access to protected functions, and delivers the application to the deployer.
• The deployer creates a deployment manifest for the application. The manifest specifies a security context and a service account.
• The administrator creates a role and assigns it an SCC.
• The administrator also creates a service account and binds it to the role.
• The deployer applies the deployment manifest, thereby deploying the application.
• OpenShift processes the deployment manifest and attempts to deploy the pod. The deployment process determines which SCC to use based on the service account specified in the manifest. The admission process compares the security context of the manifest against the SCC and decides whether to block or allow the pod to deploy.
• BLOCK: Some requested permissions are not granted, so the deployment fails.
• ALLOW: All requested permissions are granted, so the deployment creates the pod, configures the container as described by the pod’s security context, and runs the application in that container.

If the pod is denied the requested permissions, then the administrator needs to do below :

• Determine if the additional requests made in the manifest are in fact needed.
• If so, assign the requested permissions to the SCC or select an SCC that already has the requested permissions.

Thanks for reading……