Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
×

Complying with pod security admission

Pod security admission is an implementation of the Kubernetes pod security standards. Pod security admission restricts the behavior of pods. 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.

If your Operator project does not require escalated permissions to run, you can ensure your workloads run in namespaces set to the restricted pod security level. If your Operator project requires escalated permissions to run, you must set the following security context configurations:

  • The allowed pod security admission level for the Operator’s namespace

  • The allowed security context constraints (SCC) for the workload’s service account

For more information, see Understanding and managing pod security admission.

Security context constraint synchronization with pod security standards

OKD includes Kubernetes pod security admission. Globally, the privileged profile is enforced, and the restricted profile is used for warnings and audits.

In addition to the global pod security admission control configuration, a controller exists that 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.

Namespaces that are defined as part of the cluster payload have pod security admission synchronization disabled permanently. You can enable pod security admission synchronization on other namespaces as necessary.

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 found in the namespace to prevent warnings and audit logging as 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.

Ensuring Operator workloads run in namespaces set to the restricted pod security level

To ensure your Operator project can run on a wide variety of deployments and environments, configure the Operator’s workloads to run in namespaces set to the restricted pod security level.

You must leave the runAsUser field empty. If your image requires a specific user, it cannot be run under restricted security context constraints (SCC) and restricted pod security enforcement.
Procedure

  • To configure Operator workloads to run in namespaces set to the restricted pod security level, edit your Operator’s namespace definition similar to the following examples:

    It is recommended that you set the seccomp profile in your Operator’s namespace definition. However, setting the seccomp profile is not supported in OKD 4.10.

    • For Operator projects that must run in only OKD 4.11 and later, edit your Operator’s namespace definition similar to the following example:

      Example config/manager/manager.yaml file
      ...
spec:
 securityContext:
   seccompProfile:
     type: RuntimeDefault (1)
   runAsNonRoot: true
 containers:
   - name: <operator_workload_container>
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         drop:
           - ALL
...
      1 By setting the seccomp profile type to RuntimeDefault, the SCC defaults to the pod security profile of the namespace.

    • For Operator projects that must also run in OKD 4.10, edit your Operator’s namespace definition similar to the following example:

      Example config/manager/manager.yaml file
      ...
spec:
 securityContext: (1)
   runAsNonRoot: true
 containers:
   - name: <operator_workload_container>
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         drop:
           - ALL
...
      1 Leaving the seccomp profile type unset ensures your Operator project can run in OKD 4.10.
Additional resources

Managing pod security admission for Operator workloads that require escalated permissions

If your Operator project requires escalated permissions to run, you must edit your Operator’s cluster service version (CSV).

Procedure

  1. Set the security context configuration to the required permission level in your Operator’s CSV, similar to the following example:

    Example <operator_name>.clusterserviceversion.yaml file with network administrator privileges
    ...
containers:
   - name: my-container
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         add:
           - "NET_ADMIN"
...

  2. Set the service account privileges that allow your Operator’s workloads to use the required security context constraints (SCC), similar to the following example:

    Example <operator_name>.clusterserviceversion.yaml file
    ...
  install:
    spec:
      clusterPermissions:
      - rules:
        - apiGroups:
          - security.openshift.io
          resourceNames:
          - privileged
          resources:
          - securitycontextconstraints
          verbs:
          - use
        serviceAccountName: default
...

  3. Edit your Operator’s CSV description to explain why your Operator project requires escalated permissions similar to the following example:

    Example <operator_name>.clusterserviceversion.yaml file
    ...
spec:
  apiservicedefinitions:{}
  ...
description: The <operator_name> requires a privileged pod security admission label set on the Operator's namespace. The Operator's agents require escalated permissions to restart the node if the node needs remediation.

Additional resources