Rejects a pod from admission if it does not comply with the set profile
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 OKD. 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 OKD 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 OKD 4.17 to maintain their projects and create Operator releases targeting newer versions of OKD. 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.
For the most recent list of major functionality that has been deprecated or removed within OKD, refer to the Deprecated and removed features section of the OKD release notes. For information about the unsupported, community-maintained, version of the Operator SDK, see Operator SDK (Operator Framework). |
OKD 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: |
You can configure the following pod security admission modes for a namespace:
Mode | Label | Description |
---|---|---|
|
|
Rejects a pod from admission if it does not comply with the set profile |
|
|
Logs audit events if a pod does not comply with the set profile |
|
|
Displays warnings if a pod does not comply with the set profile |
You can set each of the pod security admission modes to one of the following profiles:
Profile | Description |
---|---|
|
Least restrictive policy; allows for known privilege escalation |
|
Minimally restrictive policy; prevents known privilege escalations |
|
Most restrictive policy; follows current pod hardening best practices |
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.
Pod security admission synchronization is permanently disabled on most system-created namespaces. Synchronization is also initially disabled on user-created openshift-*
prefixed namespaces, but you can enable synchronization on them later.
If a pod security admission label ( If necessary, you can enable synchronization again by using one of the following methods:
|
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-
, except for openshift-operators
By default, all namespaces that have an openshift-
prefix have pod security admission synchronization disabled initially. You can enable synchronization for user-created openshift-*
namespaces and for the openshift-operators
namespace.
You cannot enable synchronization for any system-created |
If an Operator is installed in a user-created openshift-*
namespace, synchronization is enabled automatically after a cluster service version (CSV) is created in the namespace. The synchronized label is derived from the permissions of the service accounts in the namespace.
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 |
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:
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:
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. |
If your Operator project requires escalated permissions to run, you must edit your Operator’s cluster service version (CSV).
Set the security context configuration to the required permission level in your Operator’s CSV, similar to the following 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:
<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:
<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.