This page gives an overview over Security Contexts, Security Context Constraints, and Pod Security Admission and how they interact.
A Security Context is part of a Pod specification and defines privilege and access control settings for the Pod or Container. Security context settings include setting the user ID, give it certain Linux capability, configuring SELinux, and much more.
This is an example of a restictive security context, that would adhere to the Restricted Pod Security Standard (See section on Pod Security Admission).
- name: sec-ctx-4
This means security contexts restrict what an application running in a Pod is allowed to do, but doesn’t in any way restrict what permissions users can give these applications. That’s the job of a Pod security admission controller implementation, such as SCCs, PSA, or potentially other admission controllers such as Kyverno.
Security Context Constraints are OpenShift’s solution to restrict what permissions a Pod is allowed to request. This includes what Security Context is set, but also for example the usage of volume types such as HostPath.
What SCC a user, or usually a deployment, can use is defined through normal RBAC rules.
You can assign an SCC to a deployment by giving its service account the
use permission for this SCC.
If a service account or user has access to more than one Security Context Constraint, the higher priority SCC will apply.
If priorities are equal, the most restrictive SCC will apply.
SCCs are implemented as both a validating and mutating webhook. Therefore, when a Pod is created, the controller will first verify that no configuration violates the selected SCC. Then, if the validation succeeds, all omitted configurations will be set to the maximum allowed configuration according to the SCC.
The following example SCC is a subset of the default
This SCC is fairly restricted, but allows users to run with any non-root UID.
- ALL (1)
- NET_BIND_SERVICE (1)
type: MustRunAsNonRoot (2)
|The Pod needs to drop all capabilities and is only allowed to request
If capabilities aren’t configured, the modifying webhook will drop all capabilities.
|The Pod can run as any non root user, but the specifcation needs to set a specific user.
|The Pod is only allowed to mount volumes with the specified types.
Most notably it’s not allowed to mount
|With OpenShift 4.11 we do no longer recommend that you rely on the mutating webhook, but always explicitly specify a Pod’s security context.
Kubernetes 1.24 removed Pod Security Policies, the Kubernetes native SCC equivalent, and enabled the new Pod Security Admission by default. OpenShift 4.11 also introduces PSA globally with restricted audit logging and API warnings. However, OpenShift doesn’t replace the Security Context Constraints with Pod Security Admission, but instead runs both mechanisms in parallel.
Pod Security Admission was designed to meet the most common security needs out of the box, while being simple to understand and adopt.
At the core of PSA there are the Pod Security Standards, that define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly-permissive to highly-restrictive.
Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations.
Minimally restrictive policy which prevents known privilege escalations. Allows the default (minimally specified) Pod configuration.
Heavily restricted policy, following current Pod hardening best practices.
Under Pod Security Admission, the built-in Pod Security admission controller enforces the configured Pod Security Standards. Pod security restrictions are managed at the namespace level, and are processed when pods are created. The PSA admission controller will deny the creation of workloads (Pods, Deployments, etc.) if they don’t adhere to the configured Pod Security Standard of the namespace.
You can configure how PSA will apply for a namespace by setting specific labels on the namespace. These labels define which of the predefined Pod Security Standard levels are used for a namespace. The selected label defines what action the control plane takes if a potential violation is detected:
Policy violations will cause the pod to be rejected.
Policy violations will trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed.
Policy violations will trigger a user-facing warning, but are otherwise allowed.
A namespace can configure any or all modes, or even set a different level for different modes. Check out Enforce Pod Security Standards with Namespace Labels to see how these can be configured