This is a cache of https://docs.openshift.com/rosa/authentication/understanding-and-managing-pod-security-admission.html. It is a snapshot of the page at 2024-11-25T03:10:31.929+0000.
Understanding and managing pod security admission | Authentication and authorization | Red Hat OpenShift <strong>service</strong> on AWS
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Understanding and managing pod security admission

edit

About pod security admission

Red Hat OpenShift service on AWS includes Kubernetes pod security admission. Pods that do not comply with the pod security admission defined globally or at the namespace level are not admitted to the cluster and cannot run.

Globally, the privileged profile is enforced, and the restricted profile is used for warnings and audits.

You can also configure the pod security admission settings at the namespace level.

Do not run workloads in or share access to default projects. Default projects are reserved for running core cluster components.

The following default projects are considered highly privileged: default, kube-public, kube-system, openshift, openshift-infra, openshift-node, and other system-created projects that have the openshift.io/run-level label set to 0 or 1. Functionality that relies on admission plugins, such as pod security admission, security context constraints, cluster resource quotas, and image reference resolution, does not work in highly privileged projects.
edit

Pod security admission modes

You can configure the following pod security admission modes for a namespace:

Table 1. Pod security admission modes
Mode Label Description

enforce

pod-security.kubernetes.io/enforce

Rejects a pod from admission if it does not comply with the set profile

audit

pod-security.kubernetes.io/audit

Logs audit events if a pod does not comply with the set profile

warn

pod-security.kubernetes.io/warn

Displays warnings if a pod does not comply with the set profile

Pod security admission profiles

You can set each of the pod security admission modes to one of the following profiles:

Table 2. Pod security admission profiles
Profile Description

privileged

Least restrictive policy; allows for known privilege escalation

baseline

Minimally restrictive policy; prevents known privilege escalations

restricted

Most restrictive policy; follows current pod hardening best practices

Privileged namespaces

The following system namespaces are always set to the privileged pod security admission profile:

  • default

  • kube-public

  • kube-system

You cannot change the pod security profile for these privileged namespaces.

edit

Pod security admission and security context constraints

Pod security admission standards and security context constraints are reconciled and enforced by two independent controllers. The two controllers work independently using the following processes to enforce security policies:

  1. The security context constraint controller may mutate some security context fields per the pod’s assigned SCC. For example, if the seccomp profile is empty or not set and if the pod’s assigned SCC enforces seccompProfiles field to be runtime/default, the controller sets the default type to RuntimeDefault.

  2. The security context constraint controller validates the pod’s security context against the matching SCC.

  3. The pod security admission controller validates the pod’s security context against the pod security standard assigned to the namespace.

edit

About pod security admission synchronization

In addition to the global pod security admission control configuration, a controller applies pod security admission control warn and audit labels to namespaces according to the SCC permissions of the service accounts that are in a given namespace.

The controller examines serviceAccount object permissions to use security context constraints in each namespace. Security context constraints (SCCs) are mapped to pod security profiles based on their field values; the controller uses these translated profiles. Pod security admission warn and audit labels are set to the most privileged pod security profile in the namespace to prevent displaying warnings and logging audit events when pods are created.

Namespace labeling is based on consideration of namespace-local service account privileges.

Applying pods directly might use the SCC privileges of the user who runs the pod. However, user privileges are not considered during automatic labeling.

edit

Pod security admission synchronization namespace exclusions

Pod security admission synchronization is permanently disabled on system-created namespaces and openshift-* prefixed namespaces.

Namespaces that are defined as part of the cluster payload have pod security admission synchronization disabled permanently. The following namespaces are permanently disabled:

  • default

  • kube-node-lease

  • kube-system

  • kube-public

  • openshift

  • All system-created namespaces that are prefixed with openshift-

edit

Controlling pod security admission synchronization

You can enable or disable automatic pod security admission synchronization for most namespaces.

You cannot enable pod security admission synchronization on system-created namespaces. For more information, see Pod security admission synchronization namespace exclusions.
Procedure

  • For each namespace that you want to configure, set a value for the security.openshift.io/scc.podSecurityLabelSync label:

    • To disable pod security admission label synchronization in a namespace, set the value of the security.openshift.io/scc.podSecurityLabelSync label to false.

      Run the following command:

      $ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=false

    • To enable pod security admission label synchronization in a namespace, set the value of the security.openshift.io/scc.podSecurityLabelSync label to true.

      Run the following command:

      $ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=true

    Use the --overwrite flag to overwrite the value if this label is already set on the namespace.
Additional resources
edit

Configuring pod security admission for a namespace

You can configure the pod security admission settings at the namespace level. For each of the pod security admission modes on the namespace, you can set which pod security admission profile to use.

Procedure

  • For each pod security admission mode that you want to set on a namespace, run the following command:

    $ oc label namespace <namespace> \                (1)
    pod-security.kubernetes.io/<mode>=<profile> \ (2)
    --overwrite
    1 Set <namespace> to the namespace to configure.
    2 Set <mode> to enforce, warn, or audit. Set <profile> to restricted, baseline, or privileged.
edit

About pod security admission alerts

A PodSecurityViolation alert is triggered when the Kubernetes API server reports that there is a pod denial on the audit level of the pod security admission controller. This alert persists for one day.

View the Kubernetes API server audit logs to investigate alerts that were triggered. As an example, a workload is likely to fail admission if global enforcement is set to the restricted pod security level.

For assistance in identifying pod security admission violation audit events, see Audit annotations in the Kubernetes documentation.

edit

Additional resources