Complying with pod security admission - Developing Operators | Operators | Red Hat OpenShift <strong>service</strong> on AWS

About pod security admission
About pod security admission synchronization
- Pod security admission synchronization namespace exclusions
Ensuring Operator workloads run in namespaces set to the restricted pod security level
Managing pod security admission for Operator workloads that require escalated permissions
Additional resources

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.

The Red Hat-supported version of the Operator SDK CLI tool, including the related scaffolding and testing tools for Operator projects, is deprecated and is planned to be removed in a future release of Red Hat OpenShift service on AWS. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements and will be removed from future Red Hat OpenShift service on AWS releases.

The Red Hat-supported version of the Operator SDK is not recommended for creating new Operator projects. Operator authors with existing Operator projects can use the version of the Operator SDK CLI tool released with Red Hat OpenShift service on AWS to maintain their projects and create Operator releases targeting newer versions of Red Hat OpenShift service on AWS.

The following related base images for Operator projects are not deprecated. The runtime functionality and configuration APIs for these base images are still supported for bug fixes and for addressing CVEs.

The base image for Ansible-based Operator projects
The base image for Helm-based Operator projects

For information about the unsupported, community-maintained, version of the Operator SDK, see Operator SDK (Operator Framework).

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

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

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 Red Hat OpenShift service on AWS 4.10.
- For Operator projects that must run in only Red Hat OpenShift service on AWS 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 Red Hat OpenShift service on AWS 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 Red Hat OpenShift service on AWS 4.10.

Additional resources

Managing security context constraints

edit

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

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"
...
```

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
...

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.

edit

Additional resources

Understanding and managing pod security admission