What is Security Context?

A security context (SC), defined at the 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 Security Context Constraint (SCC).

What Can Be Configured in Security Context?

A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to:

Discretionary Access Control: Permission to access an object, like a file, based on user ID (UID) and group ID (GID).
Security Enhanced Linux (SELinux): Objects are assigned security labels.
Running as privileged or unprivileged.
Linux Capabilities: Give a process some privileges, but not all the privileges of the root user.
AppArmor: Use program profiles to restrict the capabilities of individual programs.
Seccomp: Filter a process's system calls.
allowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This boolean directly controls whether the no_new_privs flag gets set on the container process. allowPrivilegeEscalation is always true when the container:
- is run as privileged, or
- has CAP_SYS_ADMIN
readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.

For more security context parameters, please refer to the Kubernetes documentation.

What is Security Context Constraint (SCC)?

A security context constraint (SCC), defined at the 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.

How security context constraints works on Openshift?

Default Security Context Constraints on OpenShift

SCC	Description

SCC	Description
anyuid	Provides all features of the restricted SCC, but allows users to run with any UID and any GID.
hostaccess	Allows access to all host namespaces but still requires pods to be run with a UID and SELinux context that are allocated to the namespace. This SCC allows host access to namespaces, file systems, and PIDs. Should only be used by trusted pods. Grant with caution.
hostmount-anyuid	Provides all the features of the restricted SCC, but allows host mounts and running as any UID and any GID on the system. This SCC allows host file system access as any UID, including UID 0. Grant with caution.
hostnetwork	Allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that are allocated to the namespace. Use caution when providing access to hostnetwork on control plane hosts (master hosts). A workload that runs hostnetwork on a control plane host is effectively root on the cluster and must be trusted accordingly.
node-exporter	Used for the Prometheus node exporter. This SCC allows host file system access as any UID, including UID 0. Grant with caution.
nonroot	Provides all features of the restricted SCC, but allows users to run with any non-root UID. The user must specify the UID or it must be specified in the manifest of the container runtime.
privileged	Allows access to all privileged and host features and the ability to run as any user, any group, any FSGroup, and with any SELinux context. This is the most relaxed SCC and should be used only for cluster administration. Grant with caution.
restricted	Denies access to all host features and requires pods to be run with a UID and SELinux context that are allocated to the namespace. This is the most restrictive SCC provided by a new installation and will be used by default for authenticated users.

Privileges of Privileged SCC

Users can run privileged pods.
Pods can mount host directories as volumes.
Pods can run as any user.
Pods can run with any MCS label.
Pods can use the host’s IPC namespace.
Pods can use the host’s PID namespace.
Pods can use any FSGroup.
Pods can use any supplemental group.
Pods can use any seccomp profiles.
Pods can request any capabilities.

Setting privileged: true in the pod specification does not necessarily select the privileged SCC. The SCC that has allowPrivilegedContainer: true and has the highest prioritization will be chosen if the user has the permissions to use it.

Features of Restricted SCC

Ensures that pods cannot run as privileged.
Ensures that pods cannot mount host directory volumes.
Requires that a pod is run as a user in a pre-allocated range of UIDs.
Requires that a pod is run with a pre-allocated MCS label.
Allows pods to use any FSGroup.
Allows pods to use any supplemental group.

The restricted SCC is the most restrictive of the SCCs that ship by default with the system. However, a custom SCC can be created to be even more restrictive, e.g., restricting readOnlyRootFS to true and allowPrivilegeEscalation to false.

Listing Security Context Constraints

To list the existing SCCs, use the following command:

oc get scc

Example Output:

NAME	PRIV	CAPS	SELINUX	RUNASUSER	FSGROUP	SUPGROUP	PRIORITY	READONLYROOTFS	VOLUMES

NAME	PRIV	CAPS	SELINUX	RUNASUSER	FSGROUP	SUPGROUP	PRIORITY	READONLYROOTFS	VOLUMES
anyuid	false	[]	MustRunAs	RunAsAny	RunAsAny	RunAsAny	10	false	[configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
hostaccess	false	[]	MustRunAs	MustRunAsRange	MustRunAs	RunAsAny	<none>	false	[configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret]
hostmount-anyuid	false	[]	MustRunAs	RunAsAny	RunAsAny	RunAsAny	<none>	false	[configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret]
hostnetwork	false	[]	MustRunAs	MustRunAsRange	MustRunAs	MustRunAs	<none>	false	[configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
node-exporter	false	[]	RunAsAny	RunAsAny	RunAsAny	RunAsAny	<none>	false	[*]
nonroot	false	[]	MustRunAs	MustRunAsNonRoot	RunAsAny	RunAsAny	<none>	false	[configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
privileged	true	[*]	RunAsAny	RunAsAny	RunAsAny	RunAsAny	<none>	false	[*]
restricted	false	[]	MustRunAs	MustRunAsRange	MustRunAs	RunAsAny	<none>	false	[configMap downwardAPI emptyDir persistentVolumeClaim projected secret]

Strategy for Managing Security Context Constraints - DIGIT Deployment on OpenShift

1. Create a Custom SCC

If you don't have an SCC that allows privileged containers, you need to create one.

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: custom-privileged-scc
allowPrivilegedContainer: true
allowedCapabilities:
- '*'
allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegeEscalation: true
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
fsGroup:
  type: RunAsAny
supplementalGroups:
  type: RunAsAny
volumes:
- '*'

2. Apply the Custom SCC

oc apply -f custom-privileged-scc.yaml

3. Assign the Custom SCC to Your Service Account

Replace <your-namespace> and <your-service-account> with the appropriate values.

4. Retry Creating the StatefulSet or Deployment

Sample SCC Files Configured for Elasticsearch and Kafka Deployment

custom-elasticsearch-scc.yaml

custom-kafka-scc.yaml

This document provides a comprehensive overview of Security Context Constraints (SCC) in OpenShift, along with a detailed guide on creating and applying custom SCCs for specific deployments. Ensure to review and tailor the SCC configurations as per your specific requirements and security policies.

DevOps

Security Context Constraints - OpenShift Deployment