OCP 4.22 Compliance Status

Ensure that application Namespaces have Network Policies defined.
Use network policies to isolate traffic in your cluster network.

Ensure that application Namespaces have Network Policies defined.
Use network policies to isolate traffic in your cluster network.

Ensure that FIPS mode is enabled on all cluster nodes
OpenShift has an installation-time flag that can enable FIPS mode for the cluster. The flag

fips: true

must be enabled at install time in the

install-config.yaml

file.

Ensure that application Namespaces have Network Policies defined.
Use network policies to isolate traffic in your cluster network.

Ensure that full disk encryption is configured on cluster nodes
When full disk encryption is chosen as a way to protect card data at rest, OpenShift can provide several solutions depending on the hosting environment. While LUKS (with TPM2 or Tang) can be used for bare metal use cases, cloud-provider specific disk encryption can be used as well. [1][2] [1] https://docs.openshift.com/container-platform/latest/machine_management/creating_machinesets/creating-machineset-azure.html#machineset-enabling-customer-managed-encryption-azure_creating-machineset-azure [2] https://docs.openshift.com/container-platform/latest/machine_management/creating_machinesets/creating-machineset-gcp.html#machineset-enabling-customer-managed-encryption_creating-machineset-gcp

Configure System Cryptography Policy
To configure the system cryptography policy to use ciphers only from the FIPS policy, create a MachineConfig as follows:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 50-master-configure-crypto-policy
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: configure-crypto-policy.service
enabled: true
contents: |
[Unit]
Before=kubelet.service
[Service]
Type=oneshot
ExecStart=update-crypto-policies --set FIPS
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target

This will configure the crypto policy appropriately in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation ( https://docs.openshift.com/container-platform/4.6/post_installation_configuration/machine-configuration-tasks.html ).

The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied. Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon.

Enable FIPS Mode
OpenShift has an installation-time flag that can enable FIPS mode for the cluster. The flag

fips: true

must be enabled at install time in the

install-config.yaml

file. If this rule fails on an installed cluster, then this is a permanent finding and cannot be fixed.

Configure System Cryptography Policy
To configure the system cryptography policy to use ciphers only from the FIPS policy, create a MachineConfig as follows:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 50-master-configure-crypto-policy
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: configure-crypto-policy.service
enabled: true
contents: |
[Unit]
Before=kubelet.service
[Service]
Type=oneshot
ExecStart=update-crypto-policies --set FIPS
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target

This will configure the crypto policy appropriately in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation ( https://docs.openshift.com/container-platform/4.6/post_installation_configuration/machine-configuration-tasks.html ).

The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied. Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon.

Enable FIPS Mode
OpenShift has an installation-time flag that can enable FIPS mode for the cluster. The flag

fips: true

must be enabled at install time in the

install-config.yaml

file. If this rule fails on an installed cluster, then this is a permanent finding and cannot be fixed.

Ensure that Audit Log Forwarding Is Enabled
OpenShift audit works at the API server level, logging all requests coming to the server. Audit is on by default and the best practice is to ship audit logs off the cluster for retention. The cluster-logging-operator is able to do this with the

ClusterLogForwarders

resource. The forementioned resource can be configured to logs to different third party systems. For more information on this, please reference the official documentation: https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-clf.html

Configure An Identity Provider
For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. Understanding authentication | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/logging/cluster-logging-external.html )

The OpenShift Container Platform includes a built-in OAuth server for token-based authentication. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. It is recommended for an administrator to configure OAuth to specify an identity provider after the cluster is installed. User access to the cluster is managed through the identity provider. Understanding identity provider configuration | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/authentication/understanding-identity-provider.html )

OpenShift includes built-in role based access control (RBAC) to determine whether a user is allowed to perform a given action within the cluster. Roles can have cluster scope or local (i.e. project) scope. Using RBAC to define and apply permissions | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/authentication/using-rbac.html )

Ensure that the kubeadmin secret has been removed
The kubeadmin user is meant to be a temporary user used for bootstrapping purposes. It is preferable to assign system administrators whose users are backed by an Identity Provider.

Make sure to remove the user as described in the documentation ( https://docs.openshift.com/container-platform/latest/authentication/remove-kubeadmin.html )

Allowed registries are configured
The configuration registrySources.allowedRegistries determines the permitted registries that the OpenShift container runtime can access for builds and pods. This configuration setting ensures that all registries other than those specified are blocked. You can set the allowed repositories by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-registries-patch.yaml

spec:
registrySources:
allowedRegistries:
- my-trusted-registry.internal.example.com

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-registries-patch.yaml)" --type=merge

Allowed registries for import are configured
The configuration allowedRegistriesForImport limits the container image registries from which normal users may import images. This is important to control, as a user who can stand up a malicious registry can then import content which claims to include the SHAs of legitimate content layers. You can set the allowed repositories for import by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-import-registries-patch.yaml

spec:
allowedRegistriesForImport:
- domainName: my-trusted-registry.internal.example.com
insecure: false

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-import-registries-patch.yaml)" --type=merge

Limit Container Capabilities
Containers should not enable more capabilites than needed as this opens the door for malicious use. To enable only the required capabilities, the appropriate Security Context Constraints (SCCs) should set capabilities as a list in allowedCapabilities.

In case an SCC outside the default allow list in the variable var-sccs-with-allowed-capabilities-regex is being flagged, create a TailoredProfile and add the additional SCC to the regular expression in the variable var-sccs-with-allowed-capabilities-regex. An example allowing an SCC named additional follows:

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
name: cis-additional-scc
spec:
description: Allows an additional scc
setValues:
- name: ocp4-var-sccs-with-allowed-capabilities-regex
rationale: Allow our own custom SCC
value: ^privileged$|^hostnetwork-v2$|^restricted-v2$|^nonroot-v2$|^additional$
extends: ocp4-cis
title: Modified CIS allowing one more SCC

Finally, reference this TailoredProfile in a ScanSettingBinding For more information on Tailoring the Compliance Operator, please consult the OpenShift documentation: https://docs.openshift.com/container-platform/latest/security/compliance_operator/co-scans/compliance-operator-tailor.html

Allowed registries are configured
The configuration registrySources.allowedRegistries determines the permitted registries that the OpenShift container runtime can access for builds and pods. This configuration setting ensures that all registries other than those specified are blocked. You can set the allowed repositories by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-registries-patch.yaml

spec:
registrySources:
allowedRegistries:
- my-trusted-registry.internal.example.com

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-registries-patch.yaml)" --type=merge

Allowed registries for import are configured
The configuration allowedRegistriesForImport limits the container image registries from which normal users may import images. This is important to control, as a user who can stand up a malicious registry can then import content which claims to include the SHAs of legitimate content layers. You can set the allowed repositories for import by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-import-registries-patch.yaml

spec:
allowedRegistriesForImport:
- domainName: my-trusted-registry.internal.example.com
insecure: false

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-import-registries-patch.yaml)" --type=merge

Limit Container Capabilities
Containers should not enable more capabilites than needed as this opens the door for malicious use. To enable only the required capabilities, the appropriate Security Context Constraints (SCCs) should set capabilities as a list in allowedCapabilities.

In case an SCC outside the default allow list in the variable var-sccs-with-allowed-capabilities-regex is being flagged, create a TailoredProfile and add the additional SCC to the regular expression in the variable var-sccs-with-allowed-capabilities-regex. An example allowing an SCC named additional follows:

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
name: cis-additional-scc
spec:
description: Allows an additional scc
setValues:
- name: ocp4-var-sccs-with-allowed-capabilities-regex
rationale: Allow our own custom SCC
value: ^privileged$|^hostnetwork-v2$|^restricted-v2$|^nonroot-v2$|^additional$
extends: ocp4-cis
title: Modified CIS allowing one more SCC

Finally, reference this TailoredProfile in a ScanSettingBinding For more information on Tailoring the Compliance Operator, please consult the OpenShift documentation: https://docs.openshift.com/container-platform/latest/security/compliance_operator/co-scans/compliance-operator-tailor.html

Ensure that Audit Log Forwarding Is Enabled
OpenShift audit works at the API server level, logging all requests coming to the server. Audit is on by default and the best practice is to ship audit logs off the cluster for retention. The cluster-logging-operator is able to do this with the

ClusterLogForwarders

resource. The forementioned resource can be configured to logs to different third party systems. For more information on this, please reference the official documentation: https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-clf.html

Ensure that Audit Log Forwarding Uses TLS
OpenShift audit works at the API server level, logging all requests coming to the server. Audit is on by default and the best practice is to ship audit logs off the cluster for retention using a secure protocol.

The cluster-logging-operator is able to do this with the

ClusterLogForwarders

resource. The forementioned resource can be configured to logs to different third party systems. For more information on this, please reference the official documentation: https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-clf.html

Ensure that a OpenShift OAuth login template or a classification banner is set
A legal notice must be configured.

This is achievable via the OAuth object by creating a custom login page, storing it in a Kubernetes Secret and referencing it in the appropriate field as described in the documentation ( https://docs.openshift.com/container-platform/latest/web_console/customizing-the-web-console.html#customizing-the-login-page_customizing-web-console )

Another way of achieving this is via a custom classification banner which is possible to set via the ConsoleNotification CRD as described in the documentation ( https://docs.openshift.com/container-platform/4.7/web_console/customizing-the-web-console.html#creating-custom-notification-banners_customizing-web-console )

Ensure that cluster-wide proxy is set
Production environments can deny direct access to the Internet and instead have an HTTP or HTTPS proxy available.

The Proxy object is used to manage the cluster-wide egress proxy. Setting this will ensure that containers get the appropriate environment variables set to ensure traffic goes to the proxy per organizational requirements.

For more information, see the relevant documentation. ( https://docs.openshift.com/container-platform/latest/networking/enable-cluster-wide-proxy.html )

Ensure that the default Ingress CA (wildcard issuer) has been replaced
Check that the default Ingress CA has been replaced.

Ensure that File Integrity Operator is scanning the cluster
The File Integrity Operator ( https://docs.openshift.com/container-platform/4.7/security/file_integrity_operator/file-integrity-operator-understanding.html ) continually runs file integrity checks on the cluster nodes. It deploys a daemon set that initializes and runs privileged AIDE containers on each node, providing a status object with a log of files that are modified during the initial run of the daemon set pods.

Ensure the notification is enabled for file integrity operator
The OpenShift platform provides the File Integrity Operator to monitor for unwanted file changes, and this control ensures proper notification alert is enabled so that system administrators and security personnel are notified about the alerts

Configure An Identity Provider
For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. Understanding authentication | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/logging/cluster-logging-external.html )

The OpenShift Container Platform includes a built-in OAuth server for token-based authentication. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. It is recommended for an administrator to configure OAuth to specify an identity provider after the cluster is installed. User access to the cluster is managed through the identity provider. Understanding identity provider configuration | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/authentication/understanding-identity-provider.html )

OpenShift includes built-in role based access control (RBAC) to determine whether a user is allowed to perform a given action within the cluster. Roles can have cluster scope or local (i.e. project) scope. Using RBAC to define and apply permissions | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/authentication/using-rbac.html )

Ensure that the default Ingress certificate has been replaced
Check that the default Ingress certificate has been replaced.

Ensure that the kubeadmin secret has been removed
The kubeadmin user is meant to be a temporary user used for bootstrapping purposes. It is preferable to assign system administrators whose users are backed by an Identity Provider.

Make sure to remove the user as described in the documentation ( https://docs.openshift.com/container-platform/latest/authentication/remove-kubeadmin.html )

Configure OAuth tokens to expire after a set period of inactivity
You can configure OAuth tokens to have have a custom duration. By default, the tokens are valid for 24 hours (86400 seconds).

The maximum age can be either set in the OAuth server configuration or in any of the OAuth clients. The client settings override the OAuth server setting.

To set the OAuth server token max age, edit the OAuth server object: oc edit oauth cluster and set the.spec.tokenConfig.accessTokenMaxAgeSeconds parameter to the desired value:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
...
spec:
tokenConfig:
accessTokenMaxAgeSeconds: 28800

To set the OAuth client token max age, edit the OAuth client object: oc edit oauthclient $clientname and set the top-level accessTokenMaxAgeSeconds attribute.

apiVersion: oauth.openshift.io/v1
grantMethod: auto
kind: OAuthClient
metadata:
...
accessTokenMaxAgeSeconds: 28800

For more information on configuring the OAuth server, consult the OpenShift documentation: https://docs.openshift.com/container-platform/4.7/authentication/configuring-internal-oauth.html

Allowed registries are configured
The configuration registrySources.allowedRegistries determines the permitted registries that the OpenShift container runtime can access for builds and pods. This configuration setting ensures that all registries other than those specified are blocked. You can set the allowed repositories by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-registries-patch.yaml

spec:
registrySources:
allowedRegistries:
- my-trusted-registry.internal.example.com

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-registries-patch.yaml)" --type=merge

Allowed registries for import are configured
The configuration allowedRegistriesForImport limits the container image registries from which normal users may import images. This is important to control, as a user who can stand up a malicious registry can then import content which claims to include the SHAs of legitimate content layers. You can set the allowed repositories for import by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-import-registries-patch.yaml

spec:
allowedRegistriesForImport:
- domainName: my-trusted-registry.internal.example.com
insecure: false

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-import-registries-patch.yaml)" --type=merge

Ensure that the OpenShift MOTD is set
To configure OpenShift's MOTD, create a *ConfigMap* called motd in the openshift namespace. The object should look as follows:

---
apiVersion: v1
kind: ConfigMap
metadata:
name: motd
namespace: openshift
data:
message: "A relevant MOTD"

Where message is a mandatory key. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.

OR:

I've read & consent to terms in IS user agreement.

Ensure that all deployments has resource limits
When deploying an application, it is important to tune based on memory and CPU consumption, allocating enough resources for the application to function properly. Images provided by OpenShift Dedicated behave properly within the confines of the memory they are allocated. However, any application images must pay attention to the specific resources required to ensure they are available. If the node where a Pod is running has enough of a resource available, it's possible (and allowed) for a container to use more resource than its request for that resource specifies. However, a container is not allowed to use more than its resource limit.

Ensure workloads use resource requests and limits
There are two ways to enable resource requests and limits. To create either: A multi-project quota, defined by a ClusterResourceQuota object, allows quotas to be shared across multiple projects. Resources used in each selected project are aggregated and that aggregate is used to limit resources across all the selected projects. A resource quota, defined by a ResourceQuota object, provides constraints that limit aggregate resource consumption per project. It can limit the quantity of objects that can be created in a project by type, as well as the total amount of compute resources and storage that might be consumed by resources in that project. We want to make sure either a ClusterResourceQuota is used in a cluster or a ResourceQuota is used per namespaces.

To configure ClusterResourceQuota, follow the directions in the documentation ( https://docs.openshift.com/container-platform/4.9/applications/quotas/quotas-setting-across-multiple-projects.html )

To configure ResourceQuota Per Project, follow the directions in the documentation ( https://docs.openshift.com/container-platform/4.9/applications/quotas/quotas-setting-per-project.html )

Limit Container Capabilities
Containers should not enable more capabilites than needed as this opens the door for malicious use. To enable only the required capabilities, the appropriate Security Context Constraints (SCCs) should set capabilities as a list in allowedCapabilities.

In case an SCC outside the default allow list in the variable var-sccs-with-allowed-capabilities-regex is being flagged, create a TailoredProfile and add the additional SCC to the regular expression in the variable var-sccs-with-allowed-capabilities-regex. An example allowing an SCC named additional follows:

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
name: cis-additional-scc
spec:
description: Allows an additional scc
setValues:
- name: ocp4-var-sccs-with-allowed-capabilities-regex
rationale: Allow our own custom SCC
value: ^privileged$|^hostnetwork-v2$|^restricted-v2$|^nonroot-v2$|^additional$
extends: ocp4-cis
title: Modified CIS allowing one more SCC

Finally, reference this TailoredProfile in a ScanSettingBinding For more information on Tailoring the Compliance Operator, please consult the OpenShift documentation: https://docs.openshift.com/container-platform/latest/security/compliance_operator/co-scans/compliance-operator-tailor.html

Ensure that Advanced Cluster Security (ACS) Sensor is deployed
Red Hat Advanced Cluster Security (ACS) for Kubernetes provides comprehensive security for containerized environments. It offers deep visibility into deployed resources across Kubernetes clusters, enabling teams to detect vulnerabilities in all images, manage compliance, and enforce security policies. By integrating ACS into the Kubernetes environment, organizations can automate security checks and configurations, ensuring that every deployed application is scanned and secured according to best practices and organizational policies. Sensor is the service responsible for analyzing and monitoring the cluster. Sensor listens to the OpenShift Container Platform or Kubernetes API and Collector events to report the current state of the cluster. Sensor also triggers deploy-time and runtime violations based on RHACS Cloud Service policies. In addition, Sensor is responsible for all cluster interactions, such as applying network policies, initiating reprocessing of RHACS Cloud Service policies, and interacting with the Admission controller.

Ensure that Audit Log Forwarding Is Enabled
OpenShift audit works at the API server level, logging all requests coming to the server. Audit is on by default and the best practice is to ship audit logs off the cluster for retention. The cluster-logging-operator is able to do this with the

ClusterLogForwarders

resource. The forementioned resource can be configured to logs to different third party systems. For more information on this, please reference the official documentation: https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-clf.html

Make sure the Container Security Operator is installed
Using the Red Hat Quay Container Security Operator, you can access vulnerability scan results from the OpenShift Container Platform web console for container images used in active pods on the cluster. The Red Hat Quay Container Security Operator:

* Watches containers associated with pods on all or specified namespaces
* Queries the container registry where the containers came from for vulnerability information, provided an image’s registry is running image scanning (such as Quay.io or a Red Hat Quay registry with Clair scanning)
* Exposes vulnerabilities via the ImageManifestVuln object in the Kubernetes API

For more information on the Container Security Operator, follow the OpenShift documentation: https://docs.openshift.com/container-platform/latest/security/pod-vulnerability-scan.html

Ensure that File Integrity Operator is scanning the cluster
The File Integrity Operator ( https://docs.openshift.com/container-platform/4.7/security/file_integrity_operator/file-integrity-operator-understanding.html ) continually runs file integrity checks on the cluster nodes. It deploys a daemon set that initializes and runs privileged AIDE containers on each node, providing a status object with a log of files that are modified during the initial run of the daemon set pods.

Ensure the notification is enabled for file integrity operator
The OpenShift platform provides the File Integrity Operator to monitor for unwanted file changes, and this control ensures proper notification alert is enabled so that system administrators and security personnel are notified about the alerts

Configure An Identity Provider
For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. Understanding authentication | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/logging/cluster-logging-external.html )

The OpenShift Container Platform includes a built-in OAuth server for token-based authentication. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. It is recommended for an administrator to configure OAuth to specify an identity provider after the cluster is installed. User access to the cluster is managed through the identity provider. Understanding identity provider configuration | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/authentication/understanding-identity-provider.html )

OpenShift includes built-in role based access control (RBAC) to determine whether a user is allowed to perform a given action within the cluster. Roles can have cluster scope or local (i.e. project) scope. Using RBAC to define and apply permissions | Authentication | OpenShift Container Platform ( https://docs.openshift.com/container-platform/4.6/authentication/using-rbac.html )

Ensure that the default Ingress certificate has been replaced
Check that the default Ingress certificate has been replaced.

Ensure that the kubeadmin secret has been removed
The kubeadmin user is meant to be a temporary user used for bootstrapping purposes. It is preferable to assign system administrators whose users are backed by an Identity Provider.

Make sure to remove the user as described in the documentation ( https://docs.openshift.com/container-platform/latest/authentication/remove-kubeadmin.html )

Configure OAuth tokens to expire after a set period of inactivity
You can configure OAuth tokens to expire after a set period of inactivity. By default, no token inactivity timeout is set.

The inactivity timeout can be either set in the OAuth server configuration or in any of the OAuth clients. The client settings override the OAuth server setting.

To set the OAuth server inactivity timeout, edit the OAuth server object: oc edit oauth cluster and set the.spec.tokenConfig.accessTokenInactivityTimeout parameter to the desired value:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
...
spec:
tokenConfig:
accessTokenInactivityTimeout: 10m0s

Please note that the OAuth server converts the value internally to a human-readable format,
so that e.g. setting accessTokenInactivityTimeout=600s would be converted by the OAuth
server to accessTokenInactivityTimeout=10m0s.

For more information on configuring the OAuth server, consult the OpenShift documentation: https://docs.openshift.com/container-platform/4.7/authentication/configuring-oauth-clients.html

To edit the OAuth client inactivity timeout, edit the OAuth client object: oc edit oauthclient $clientname and set the top-level accessTokenInactivityTimeoutSeconds attribute.

apiVersion: oauth.openshift.io/v1
grantMethod: auto
kind: OAuthClient
metadata:
...
accessTokenInactivityTimeoutSeconds: 600

For more information on configuring the OAuth clients, consult the OpenShift documentation: https://access.redhat.com/documentation/en-us/openshift_container_platform/4.7/html-single/authentication_and_authorization/index#oauth-token-inactivity-timeout_configuring-internal-oauth

Allowed registries are configured
The configuration registrySources.allowedRegistries determines the permitted registries that the OpenShift container runtime can access for builds and pods. This configuration setting ensures that all registries other than those specified are blocked. You can set the allowed repositories by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-registries-patch.yaml

spec:
registrySources:
allowedRegistries:
- my-trusted-registry.internal.example.com

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-registries-patch.yaml)" --type=merge

Allowed registries for import are configured
The configuration allowedRegistriesForImport limits the container image registries from which normal users may import images. This is important to control, as a user who can stand up a malicious registry can then import content which claims to include the SHAs of legitimate content layers. You can set the allowed repositories for import by applying the following manifest using

oc patch

, e.g. if you save the following snippet to

/tmp/allowed-import-registries-patch.yaml

spec:
allowedRegistriesForImport:
- domainName: my-trusted-registry.internal.example.com
insecure: false

you would call

oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-import-registries-patch.yaml)" --type=merge

Limit Container Capabilities
Containers should not enable more capabilites than needed as this opens the door for malicious use. To enable only the required capabilities, the appropriate Security Context Constraints (SCCs) should set capabilities as a list in allowedCapabilities.

In case an SCC outside the default allow list in the variable var-sccs-with-allowed-capabilities-regex is being flagged, create a TailoredProfile and add the additional SCC to the regular expression in the variable var-sccs-with-allowed-capabilities-regex. An example allowing an SCC named additional follows:

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
name: cis-additional-scc
spec:
description: Allows an additional scc
setValues:
- name: ocp4-var-sccs-with-allowed-capabilities-regex
rationale: Allow our own custom SCC
value: ^privileged$|^hostnetwork-v2$|^restricted-v2$|^nonroot-v2$|^additional$
extends: ocp4-cis
title: Modified CIS allowing one more SCC

Finally, reference this TailoredProfile in a ScanSettingBinding For more information on Tailoring the Compliance Operator, please consult the OpenShift documentation: https://docs.openshift.com/container-platform/latest/security/compliance_operator/co-scans/compliance-operator-tailor.html

Make sure the Security Profiles Operator is installed
Security Profiles Operator provides a way to define secure computing (seccomp) profiles and SELinux profiles as custom resources that are syncrhonized to every node in a given namespace. Using security profiles can increase security at the container level in your cluster. Seccomp security profiles list the syscalls a process can make, and SELinux security profiles provide a label-based system that restricts access and usage of processes, applications, and files.

Install usbguard Package
The usbguard package can be installed with the following manifest:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-usbguard-install
spec:
config:
ignition:
version: 3.1.0
extensions:
- usbguard

This will install the usbguard package in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation ( https://docs.openshift.com/container-platform/4.6/post_installation_configuration/machine-configuration-tasks.html ).

Enable the USBGuard Service
The USBGuard service should be enabled. The usbguard service can be enabled with the following manifest:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-usbguard-enable
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: usbguard.service
enabled: true

This will enable the usbguard service in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation ( https://docs.openshift.com/container-platform/4.6/post_installation_configuration/machine-configuration-tasks.html ).

Set SSH Client Alive Interval
SSH allows administrators to set a network responsiveness timeout interval. After this interval has passed, the unresponsive client will be automatically logged out.

To set this timeout interval, edit the following line in /etc/ssh/sshd_config as follows:

ClientAliveInterval *300*


The timeout *interval* is given in seconds. For example, have a timeout of 10 minutes, set *interval* to 600.

If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made in /etc/ssh/sshd_config. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.

Set SSH Client Alive Count Max
The SSH server sends at most ClientAliveCountMax messages during a SSH session and waits for a response from the SSH client. The option ClientAliveInterval configures timeout after each ClientAliveCountMax message. If the SSH server does not receive a response from the client, then the connection is considered unresponsive and terminated. For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when the ClientAliveInterval is set. Starting with v8.2, a value of 0 disables the timeout functionality completely. If the option is set to a number greater than 0 , then the session will be disconnected after ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message.

Authorize Human Interface Devices and USB hubs in USBGuard daemon
To allow authorization of USB devices combining human interface device and hub capabilities by USBGuard daemon, add the line allow with-interface match-all { 03:*:* 09:00:* } to /etc/usbguard/rules.conf.

Install usbguard Package
The usbguard package can be installed with the following manifest:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-usbguard-install
spec:
config:
ignition:
version: 3.1.0
extensions:
- usbguard

This will install the usbguard package in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation ( https://docs.openshift.com/container-platform/4.6/post_installation_configuration/machine-configuration-tasks.html ).

Enable the USBGuard Service
The USBGuard service should be enabled. The usbguard service can be enabled with the following manifest:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-usbguard-enable
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: usbguard.service
enabled: true

This will enable the usbguard service in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation ( https://docs.openshift.com/container-platform/4.6/post_installation_configuration/machine-configuration-tasks.html ).

Set SSH Client Alive Interval
SSH allows administrators to set a network responsiveness timeout interval. After this interval has passed, the unresponsive client will be automatically logged out.

To set this timeout interval, edit the following line in /etc/ssh/sshd_config as follows:

ClientAliveInterval *300*


The timeout *interval* is given in seconds. For example, have a timeout of 10 minutes, set *interval* to 600.

If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made in /etc/ssh/sshd_config. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.

Set SSH Client Alive Count Max
The SSH server sends at most ClientAliveCountMax messages during a SSH session and waits for a response from the SSH client. The option ClientAliveInterval configures timeout after each ClientAliveCountMax message. If the SSH server does not receive a response from the client, then the connection is considered unresponsive and terminated. For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when the ClientAliveInterval is set. Starting with v8.2, a value of 0 disables the timeout functionality completely. If the option is set to a number greater than 0 , then the session will be disconnected after ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message.

Authorize Human Interface Devices and USB hubs in USBGuard daemon
To allow authorization of USB devices combining human interface device and hub capabilities by USBGuard daemon, add the line allow with-interface match-all { 03:*:* 09:00:* } to /etc/usbguard/rules.conf.

Restrict Automounting of Service Account Tokens
Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server. To ensure pods do not automatically mount tokens, set automountServiceAccountToken to false.

Ensure Usage of Unique Service Accounts
Using the default service account prevents accurate application rights review and audit tracing. Instead of default , create a new and unique service account with the following command:

$ oc create sa service_account_name


where service_account_name is the name of a service account that is needed in the project namespace.

Apply Security Context to Your Pods and Containers
Apply Security Context to your Pods and Containers

The default namespace should not be used
Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult.

Ensure Seccomp Profile Pod Definitions
Enable default seccomp profiles in your pod definitions.

Create administrative boundaries between resources using namespaces
Use namespaces to isolate your Kubernetes objects.

Ensure that the RBAC setup follows the principle of least privilege
Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. If users or groups exist that are bound to roles they must not have, modify the user or group permissions using the following cluster and local role binding commands: Remove a User from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-user role username Remove a Group from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-group role groupname Remove a User from a Local RBAC role by executing the following: oc adm policy remove-role-from-user role username Remove a Group from a Local RBAC role by executing the following: oc adm policy remove-role-from-group role groupname NOTE: For additional information. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html

Ensure that the cluster-admin role is only used where required
The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.

Limit Access to Kubernetes Secrets
The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation. To restrict users from secrets, remove get , list , and watch access to unauthorized users to secret objects in the cluster.

Minimize Access to Pod Creation
The ability to create pods in a namespace can provide a number of opportunities for privilege escalation. Where applicable, remove create access to pod objects in the cluster.

Minimize Wildcard Usage in Cluster and Local Roles
Kubernetes Cluster and Local Roles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these using a wildcard * which matches all items. This violates the principle of least privilege and leaves a cluster in a more vulnerable state to privilege abuse.

Drop Container Capabilities
Containers should not enable more capabilities than needed as this opens the door for malicious use. To disable the capabilities, the appropriate Security Context Constraints (SCCs) should set all capabilities as * or a list of capabilities in requiredDropCapabilities.

Limit Access to the Host IPC Namespace
Containers should not be allowed access to the host's Interprocess Communication (IPC) namespace. To prevent containers from getting access to a host's IPC namespace, the appropriate Security Context Constraints (SCCs) should set allowHostIPC to false.

Limit Use of the CAP_NET_RAW
Containers should not enable more capabilities than needed as this opens the door for malicious use. CAP_NET_RAW enables a container to launch a network attack on another container or cluster. To disable the CAP_NET_RAW capability, the appropriate Security Context Constraints (SCCs) should set NET_RAW in requiredDropCapabilities.

Limit Access to the Host Network Namespace
Containers should not be allowed access to the host's network namespace. To prevent containers from getting access to a host's network namespace, the appropriate Security Context Constraints (SCCs) should set allowHostNetwork to false.

Limit Containers Ability to Escalate Privileges
Containers should be limited to only the privileges required to run and should not be allowed to escalate their privileges. To prevent containers from escalating privileges, the appropriate Security Context Constraints (SCCs) should set allowPrivilegeEscalation to false.

Limit Privileged Container Use
Containers should be limited to only the privileges required to run. To prevent containers from running as privileged containers, the appropriate Security Context Constraints (SCCs) should set allowPrivilegedContainer to false.

Limit Access to the Host Process ID Namespace
Containers should not be allowed access to the host's process ID namespace. To prevent containers from getting access to a host's process ID namespace, the appropriate Security Context Constraints (SCCs) should set allowHostPID to false.

Limit Container Running As Root User
Containers should run as a random non-privileged user. To prevent containers from running as root user, the appropriate Security Context Constraints (SCCs) should set.runAsUser.type to MustRunAsRange.

Consider external secret storage
Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets.

Do Not Use Environment Variables with Secrets
Secrets should be mounted as data volumes instead of environment variables.

Ensure that the cluster-admin role is only used where required
The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.

Minimize Access to Pod Creation
The ability to create pods in a namespace can provide a number of opportunities for privilege escalation. Where applicable, remove create access to pod objects in the cluster.

Minimize Wildcard Usage in Cluster and Local Roles
Kubernetes Cluster and Local Roles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these using a wildcard * which matches all items. This violates the principle of least privilege and leaves a cluster in a more vulnerable state to privilege abuse.

Limit Containers Ability to Escalate Privileges
Containers should be limited to only the privileges required to run and should not be allowed to escalate their privileges. To prevent containers from escalating privileges, the appropriate Security Context Constraints (SCCs) should set allowPrivilegeEscalation to false.

Limit Privileged Container Use
Containers should be limited to only the privileges required to run. To prevent containers from running as privileged containers, the appropriate Security Context Constraints (SCCs) should set allowPrivilegedContainer to false.

Limit Container Running As Root User
Containers should run as a random non-privileged user. To prevent containers from running as root user, the appropriate Security Context Constraints (SCCs) should set.runAsUser.type to MustRunAsRange.

Restrict Automounting of Service Account Tokens
Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server. To ensure pods do not automatically mount tokens, set automountServiceAccountToken to false.

Ensure Usage of Unique Service Accounts
Using the default service account prevents accurate application rights review and audit tracing. Instead of default , create a new and unique service account with the following command:

$ oc create sa service_account_name


where service_account_name is the name of a service account that is needed in the project namespace.

Apply Security Context to Your Pods and Containers
Apply Security Context to your Pods and Containers

Manage Image Provenance Using ImagePolicyWebhook
OpenShift administrators can control which images can be imported, tagged, and run in a cluster. There are two facilities for this purpose: (1) Allowed Registries, allowing administrators to restrict image origins to known external registries; and (2) ImagePolicy Admission plug-in which lets administrators specify specific images which are allowed to run on the OpenShift cluster. Configure an Image policy per the Image Policy chapter in the OpenShift documentation: https://docs.openshift.com/container-platform/4.4/openshift_images/image-configuration.html

The default namespace should not be used
Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult.

Ensure Seccomp Profile Pod Definitions
Enable default seccomp profiles in your pod definitions.

Create administrative boundaries between resources using namespaces
Use namespaces to isolate your Kubernetes objects.

Ensure that the RBAC setup follows the principle of least privilege
Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. If users or groups exist that are bound to roles they must not have, modify the user or group permissions using the following cluster and local role binding commands: Remove a User from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-user role username Remove a Group from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-group role groupname Remove a User from a Local RBAC role by executing the following: oc adm policy remove-role-from-user role username Remove a Group from a Local RBAC role by executing the following: oc adm policy remove-role-from-group role groupname NOTE: For additional information. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html

Ensure that the cluster-admin role is only used where required
The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.

Limit Access to Kubernetes Secrets
The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation. To restrict users from secrets, remove get , list , and watch access to unauthorized users to secret objects in the cluster.

Minimize Access to Pod Creation
The ability to create pods in a namespace can provide a number of opportunities for privilege escalation. Where applicable, remove create access to pod objects in the cluster.

Minimize Wildcard Usage in Cluster and Local Roles
Kubernetes Cluster and Local Roles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these using a wildcard * which matches all items. This violates the principle of least privilege and leaves a cluster in a more vulnerable state to privilege abuse.

Drop Container Capabilities
Containers should not enable more capabilities than needed as this opens the door for malicious use. To disable the capabilities, the appropriate Security Context Constraints (SCCs) should set all capabilities as * or a list of capabilities in requiredDropCapabilities.

Limit Access to the Host IPC Namespace
Containers should not be allowed access to the host's Interprocess Communication (IPC) namespace. To prevent containers from getting access to a host's IPC namespace, the appropriate Security Context Constraints (SCCs) should set allowHostIPC to false.

Limit Use of the CAP_NET_RAW
Containers should not enable more capabilities than needed as this opens the door for malicious use. CAP_NET_RAW enables a container to launch a network attack on another container or cluster. To disable the CAP_NET_RAW capability, the appropriate Security Context Constraints (SCCs) should set NET_RAW in requiredDropCapabilities.

Limit Access to the Host Network Namespace
Containers should not be allowed access to the host's network namespace. To prevent containers from getting access to a host's network namespace, the appropriate Security Context Constraints (SCCs) should set allowHostNetwork to false.

Limit Containers Ability to Escalate Privileges
Containers should be limited to only the privileges required to run and should not be allowed to escalate their privileges. To prevent containers from escalating privileges, the appropriate Security Context Constraints (SCCs) should set allowPrivilegeEscalation to false.

Limit Privileged Container Use
Containers should be limited to only the privileges required to run. To prevent containers from running as privileged containers, the appropriate Security Context Constraints (SCCs) should set allowPrivilegedContainer to false.

Limit Access to the Host Process ID Namespace
Containers should not be allowed access to the host's process ID namespace. To prevent containers from getting access to a host's process ID namespace, the appropriate Security Context Constraints (SCCs) should set allowHostPID to false.

Limit Container Running As Root User
Containers should run as a random non-privileged user. To prevent containers from running as root user, the appropriate Security Context Constraints (SCCs) should set.runAsUser.type to MustRunAsRange.

Consider external secret storage
Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets.

Do Not Use Environment Variables with Secrets
Secrets should be mounted as data volumes instead of environment variables.

Restrict Automounting of Service Account Tokens
Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server. To ensure pods do not automatically mount tokens, set automountServiceAccountToken to false.

Ensure Usage of Unique Service Accounts
Using the default service account prevents accurate application rights review and audit tracing. Instead of default , create a new and unique service account with the following command:

$ oc create sa service_account_name


where service_account_name is the name of a service account that is needed in the project namespace.

Ensure the alert receiver is configured
In OpenShift Container Platform, an alert is fired when the conditions defined in an alerting rule are true. An alert provides a notification that a set of circumstances are apparent within a cluster. Firing alerts can be viewed in the Alerting UI in the OpenShift Container Platform web console by default. After an installation, you can configure OpenShift Container Platform to send alert notifications to external systems so that designate personnel can be alerted in real time. OpenShift provides multiple alert receivers integrations to send realtime alerts to different services such as email, slack, pagerduty, webhooks, etc. [1][2] [1]https://docs.openshift.com/container-platform/latest/post_installation_configuration/configuring-alert-notifications.html#configuring-alert-receivers_configuring-alert-notifications [2]https://docs.openshift.com/container-platform/latest/monitoring/managing-alerts.html#applying-custom-alertmanager-configuration_managing-alerts

Apply Security Context to Your Pods and Containers
Apply Security Context to your Pods and Containers

The default namespace should not be used
Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult.

Ensure Seccomp Profile Pod Definitions
Enable default seccomp profiles in your pod definitions.

Create administrative boundaries between resources using namespaces
Use namespaces to isolate your Kubernetes objects.

Ensure that the RBAC setup follows the principle of least privilege
Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. If users or groups exist that are bound to roles they must not have, modify the user or group permissions using the following cluster and local role binding commands: Remove a User from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-user role username Remove a Group from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-group role groupname Remove a User from a Local RBAC role by executing the following: oc adm policy remove-role-from-user role username Remove a Group from a Local RBAC role by executing the following: oc adm policy remove-role-from-group role groupname NOTE: For additional information. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html

Ensure that the cluster-admin role is only used where required
The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.

Limit Access to Kubernetes Secrets
The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation. To restrict users from secrets, remove get , list , and watch access to unauthorized users to secret objects in the cluster.

Minimize Access to Pod Creation
The ability to create pods in a namespace can provide a number of opportunities for privilege escalation. Where applicable, remove create access to pod objects in the cluster.

Minimize Wildcard Usage in Cluster and Local Roles
Kubernetes Cluster and Local Roles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these using a wildcard * which matches all items. This violates the principle of least privilege and leaves a cluster in a more vulnerable state to privilege abuse.

Drop Container Capabilities
Containers should not enable more capabilities than needed as this opens the door for malicious use. To disable the capabilities, the appropriate Security Context Constraints (SCCs) should set all capabilities as * or a list of capabilities in requiredDropCapabilities.

Limit Access to the Host IPC Namespace
Containers should not be allowed access to the host's Interprocess Communication (IPC) namespace. To prevent containers from getting access to a host's IPC namespace, the appropriate Security Context Constraints (SCCs) should set allowHostIPC to false.

Limit Use of the CAP_NET_RAW
Containers should not enable more capabilities than needed as this opens the door for malicious use. CAP_NET_RAW enables a container to launch a network attack on another container or cluster. To disable the CAP_NET_RAW capability, the appropriate Security Context Constraints (SCCs) should set NET_RAW in requiredDropCapabilities.

Limit Access to the Host Network Namespace
Containers should not be allowed access to the host's network namespace. To prevent containers from getting access to a host's network namespace, the appropriate Security Context Constraints (SCCs) should set allowHostNetwork to false.

Limit Containers Ability to Escalate Privileges
Containers should be limited to only the privileges required to run and should not be allowed to escalate their privileges. To prevent containers from escalating privileges, the appropriate Security Context Constraints (SCCs) should set allowPrivilegeEscalation to false.

Limit Privileged Container Use
Containers should be limited to only the privileges required to run. To prevent containers from running as privileged containers, the appropriate Security Context Constraints (SCCs) should set allowPrivilegedContainer to false.

Limit Access to the Host Process ID Namespace
Containers should not be allowed access to the host's process ID namespace. To prevent containers from getting access to a host's process ID namespace, the appropriate Security Context Constraints (SCCs) should set allowHostPID to false.

Limit Container Running As Root User
Containers should run as a random non-privileged user. To prevent containers from running as root user, the appropriate Security Context Constraints (SCCs) should set.runAsUser.type to MustRunAsRange.

Consider external secret storage
Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets.

Do Not Use Environment Variables with Secrets
Secrets should be mounted as data volumes instead of environment variables.

Disable Booting from USB Devices in Boot Firmware
Configure the system boot firmware (historically called BIOS on PC systems) to disallow booting from USB drives.

Ensure /var/log Located On Separate Partition
System logs are stored in the /var/log directory.

Partitioning Red Hat CoreOS is a Day 1 operation and cannot be changed afterwards. For documentation on how to add a MachineConfig manifest that specifies a separate /var/log partition, follow: https://docs.openshift.com/container-platform/latest/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-user-infra-machines-advanced_disk_installing-platform-agnostic

Note that the Red Hat OpenShift documentation often references a block device, such as /dev/vda. The name of the available block devices depends on the underlying infrastructure (bare metal vs cloud), and often the specific instance type. For example in AWS, some instance types have NVMe drives ( /dev/nvme* ), others use /dev/xvda*. You will need to look for relevant documentation for your infrastructure around this. In many cases, the simplest thing is to boot a single machine with an Ignition configuration that just gives you SSH access, and inspect the block devices via e.g. the lsblk command. For physical hardware, a good best practice is to reference devices via the /dev/disk/by-id/ or /dev/disk/by-path links.

Ensure /var/log/audit Located On Separate Partition
Audit logs are stored in the /var/log/audit directory.

Partitioning Red Hat CoreOS is a Day 1 operation and cannot be changed afterwards. For documentation on how to add a MachineConfig manifest that specifies a separate /var/log/audit partition, follow: https://docs.openshift.com/container-platform/latest/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-user-infra-machines-advanced_disk_installing-platform-agnostic

Note that the Red Hat OpenShift documentation often references a block device, such as /dev/vda. The name of the available block devices depends on the underlying infrastructure (bare metal vs cloud), and often the specific instance type. For example in AWS, some instance types have NVMe drives ( /dev/nvme* ), others use /dev/xvda*. You will need to look for relevant documentation for your infrastructure around this. In many cases, the simplest thing is to boot a single machine with an Ignition configuration that just gives you SSH access, and inspect the block devices via e.g. the lsblk command. For physical hardware, a good best practice is to reference devices via the /dev/disk/by-id/ or /dev/disk/by-path links.

Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon.

Disable WiFi or Bluetooth in BIOS
Some machines that include built-in wireless support offer the ability to disable the device through the BIOS. This is hardware-specific; consult your hardware manual or explore the BIOS setup during boot.

Disable Booting from USB Devices in Boot Firmware
Configure the system boot firmware (historically called BIOS on PC systems) to disallow booting from USB drives.

Ensure /var/log Located On Separate Partition
System logs are stored in the /var/log directory.

Partitioning Red Hat CoreOS is a Day 1 operation and cannot be changed afterwards. For documentation on how to add a MachineConfig manifest that specifies a separate /var/log partition, follow: https://docs.openshift.com/container-platform/latest/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-user-infra-machines-advanced_disk_installing-platform-agnostic

Note that the Red Hat OpenShift documentation often references a block device, such as /dev/vda. The name of the available block devices depends on the underlying infrastructure (bare metal vs cloud), and often the specific instance type. For example in AWS, some instance types have NVMe drives ( /dev/nvme* ), others use /dev/xvda*. You will need to look for relevant documentation for your infrastructure around this. In many cases, the simplest thing is to boot a single machine with an Ignition configuration that just gives you SSH access, and inspect the block devices via e.g. the lsblk command. For physical hardware, a good best practice is to reference devices via the /dev/disk/by-id/ or /dev/disk/by-path links.

Ensure /var/log/audit Located On Separate Partition
Audit logs are stored in the /var/log/audit directory.

Partitioning Red Hat CoreOS is a Day 1 operation and cannot be changed afterwards. For documentation on how to add a MachineConfig manifest that specifies a separate /var/log/audit partition, follow: https://docs.openshift.com/container-platform/latest/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-user-infra-machines-advanced_disk_installing-platform-agnostic

Note that the Red Hat OpenShift documentation often references a block device, such as /dev/vda. The name of the available block devices depends on the underlying infrastructure (bare metal vs cloud), and often the specific instance type. For example in AWS, some instance types have NVMe drives ( /dev/nvme* ), others use /dev/xvda*. You will need to look for relevant documentation for your infrastructure around this. In many cases, the simplest thing is to boot a single machine with an Ignition configuration that just gives you SSH access, and inspect the block devices via e.g. the lsblk command. For physical hardware, a good best practice is to reference devices via the /dev/disk/by-id/ or /dev/disk/by-path links.

Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon.

Disable WiFi or Bluetooth in BIOS
Some machines that include built-in wireless support offer the ability to disable the device through the BIOS. This is hardware-specific; consult your hardware manual or explore the BIOS setup during boot.