## Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4

> with profile DISA STIG for Red Hat OpenShift Container Platform 4 - Platform level
> This profile contains configuration checks that align to the DISA STIG for Red Hat OpenShift Container Platform 4.

The ComplianceAsCode Project
https://www.open-scap.org/security-policies/scap-security-guide
This guide presents a catalog of security-relevant configuration settings for Red Hat OpenShift Container Platform 4. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the `scap-security-guide` package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The NIST National Checklist Program (NCP), which provides required settings for the United States Government, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

## Profile Information

Profile Title | DISA STIG for Red Hat OpenShift Container Platform 4 - Platform level
Profile ID | xccdf_org.ssgproject.content_profile_stig-v2r2

#### CPE Platforms

- cpe:/a:redhat:openshift_container_platform_node_on_ovn:4
- cpe:/a:redhat:openshift_container_platform_node_on_sdn:4
- cpe:/o:redhat:openshift_container_platform_node:4
- cpe:/a:redhat:openshift_container_platform_on_aws:4
- cpe:/a:redhat:openshift_container_platform_on_azure:4
- cpe:/a:redhat:openshift_container_platform_on_gcp:4
- cpe:/a:redhat:openshift_container_platform_on_ovn:4
- cpe:/a:redhat:openshift_container_platform_on_sdn:4
- cpe:/a:redhat:openshift_container_platform:4.10
- cpe:/a:redhat:openshift_container_platform:4.11
- cpe:/a:redhat:openshift_container_platform:4.12
- cpe:/a:redhat:openshift_container_platform:4.13
- cpe:/a:redhat:openshift_container_platform:4.14
- cpe:/a:redhat:openshift_container_platform:4.15
- cpe:/a:redhat:openshift_container_platform:4.16
- cpe:/a:redhat:openshift_container_platform:4.17
- cpe:/a:redhat:openshift_container_platform:4.18
- cpe:/a:redhat:openshift_container_platform:4.19
- cpe:/a:redhat:openshift_container_platform:4.20
- cpe:/a:redhat:openshift_container_platform:4.21
- cpe:/a:redhat:openshift_container_platform:4.22
- cpe:/a:redhat:openshift_container_platform:4.23
- cpe:/a:redhat:openshift_container_platform:4.24
- cpe:/a:redhat:openshift_container_platform:4.6
- cpe:/a:redhat:openshift_container_platform:4.7
- cpe:/a:redhat:openshift_container_platform:4.8
- cpe:/a:redhat:openshift_container_platform:4.9
- cpe:/a:redhat:openshift_container_platform:4.1

## Revision History

Current version: 0.1.79

- draft (as of 2025-12-05)

## Table of Contents

1. Kubernetes Settings
   1. System and Software Integrity
   2. OpenShift Kube API Server
   3. Authentication
   4. Kubernetes - General Security Practices
   5. OpenShift - Logging Settings
   6. Kubernetes - Network Configuration and Firewalls
   7. Role-based Access Control
   8. Kubernetes - Registry Security Practices
   9. OpenShift - Risk Assessment Settings
   10. Security Context Constraints (SCC)

## Checklist

Group Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4 Group contains 12 groups and 50 rules
Group Kubernetes Settings Group contains 11 groups and 50 rules

[ref] Each section of this configuration guide includes information about the configuration of a Kubernetes cluster and a set of recommendations for hardening the configuration. For each hardening recommendation, information on how to implement the control and/or how to verify or audit the control is provided. In some cases, remediation information is also provided. Some of the settings in the hardening guide are in place by default. The audit information for these settings is provided in order to verify that the cluster administrator has not made changes that would be less secure. A small number of items require configuration. Finally, there are some recommendations that require decisions by the system operator, such as audit log size, retention, and related settings.

Group System and Software Integrity Group contains 1 group and 3 rules

[ref] System and software integrity can be gained by installing antivirus, increasing system encryption strength with FIPS, verifying installed software, enabling SELinux, installing an Intrusion Prevention System, etc. However, installing or enabling integrity checking tools cannot prevent intrusions, but they can detect that an intrusion may have occurred. Requirements for integrity checking may be highly dependent on the environment in which the system will be used.

Group System Cryptographic Policies Group contains 1 rule
[ref] OpenShift has the capability to centrally configure cryptographic polices.

#### Rule Ensure that FIPS mode is enabled on all cluster nodes [ref]

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.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/machineconfiguration.openshift.io/v1/machineconfigs` API endpoint, filter with with the `jq` utility using the following filter `[.items[] | select(.metadata.name | test("^rendered-worker-[0-9a-z]+$|^rendered-master-[0-9a-z]+$"))] | map(.spec.fips == true)` and persist it to the local `/kubernetes-api-resources/apis/machineconfiguration.openshift.io/v1/machineconfigs#ab7e02a1c3f44ae48f843ce3dee7b948d624d2f702b9428760efbfd4653847ba` file.

Rationale: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Severity: | high
Rule ID: | xccdf_org.ssgproject.content_rule_fips_mode_enabled_on_all_nodes
Identifiers: | CCE-85860-5

References:

nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1
nist | AC-17(2), CM-3(6), SC-12(2), SC-12(3), SC-13, IA-7
pcidss | Req-3.4.1
app-srg-ctr | SRG-APP-000126-CTR-000275, SRG-APP-000219-CTR-000550, SRG-APP-000411-CTR-000995, SRG-APP-000412-CTR-001000, SRG-APP-000416-CTR-001015, SRG-APP-000514-CTR-001315, SRG-APP-000610-CTR-001385, SRG-APP-000635-CTR-001405
stigid | CNTR-OS-000340, CNTR-OS-000510, CNTR-OS-001080
stigref | SV-257536r960951_rule, SV-257546r1043178_rule, SV-257587r961896_rule

#### Rule Ensure that Cluster Version Operator is deployed [ref]

Integrity of the OpenShift platform is handled to start by the cluster version operator. Cluster Version Operator will by default GPG verify the integrity of the release image before applying it. [1] This rule checks if Cluster Version Operator is deployed and available in the system. [1] https://github.com/openshift/machine-config-operator/blob/master/docs/OSUpgrades.md#questions-and-answers
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/config.openshift.io/v1/clusterversions/version` API endpoint, filter with with the `jq` utility using the following filter `[.status.conditions[] | select(.type=="Available") | .status]` and persist it to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/clusterversions/version#588c29ac9d4c67b1444308c5ba310271832895fee54701f7d0cb6cbced390443` file.

Rationale: | Integrity check prevent a malicious actor from using a unauthorized system image, hence it will ensure the image has not been tampered with, or corrupted.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_cluster_version_operator_exists
Identifiers: | CCE-90670-1

References:

nist | SA-10(1)
app-srg-ctr | SRG-APP-000384-CTR-000915
bsi | APP.4.4.A17
stigid | CNTR-OS-000740
stigref | SV-257561r961473_rule

#### Rule Ensure that Cluster Version Operator verifies integrity [ref]

Integrity of the OpenShift platform is handled to start by the cluster version operator. Cluster Version Operator will by default GPG verify the integrity of the release image before applying it. This rule check if there is an unverified cluster image.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/config.openshift.io/v1/clusterversions/version` API endpoint, filter with with the `jq` utility using the following filter `[.status.history[0:-1]|.[]|.verified]` and persist it to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/clusterversions/version#69adcfd65c8b8d723e4a7118c170f634cebbb349e9b554dd15001e6551a586f8` file.

Rationale: | Unverified cluster image will compromise the system integrity. Integrity check prevent a malicious actor from using a unauthorized system image, hence it will ensure the image has not been tampered with, or corrupted.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_cluster_version_operator_verify_integrity
Identifiers: | CCE-90671-9

References:

nist | SA-10(1)
app-srg-ctr | SRG-APP-000384-CTR-000915
bsi | APP.4.4.A17
stigid | CNTR-OS-000740
stigref | SV-257561r961473_rule

Group OpenShift Kube API Server Group contains 3 rules
[ref] This section contains recommendations for kube-apiserver configuration.

#### Rule Configure the Encryption Provider Cipher [ref]

When you enable etcd encryption, the following OpenShift API server and Kubernetes API server resources are encrypted:

- Secrets
- ConfigMaps
- Routes
- OAuth access tokens
- OAuth authorize tokens

When you enable etcd encryption, encryption keys are created. These keys are rotated on a weekly basis. You must have these keys in order to restore from an etcd backup.

To ensure the correct cipher, set the encryption type to `aescbc` or `aesgcm` in the `apiserver` object which configures the API server itself.

    spec:
      encryption:
        type: aescbc

For more information, follow the relevant documentation.

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `{{if ne .hypershift_cluster "None"}}/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}{{else}}/apis/config.openshift.io/v1/apiservers/cluster{{end}}` API endpoint, filter with with the `jq` utility using the following filter `{{if ne .hypershift_cluster "None"}}[.spec.secretEncryption.type]{{else}}[.spec.encryption.type]{{end}}` and persist it to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/apiservers/cluster#a1d4b20a86b76e7e2d634dbeff420b1a80df6800836dad1b552314d1b24a18cb` file.

Rationale:

etcd is a highly available key-value store used by OpenShift deployments for persistent storage of all REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures. Where etcd encryption is used, it is important to ensure that the appropriate set of encryption providers is used. Currently, `aescbc` and `aesgcm` are the only types supported by OCP.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_api_server_encryption_provider_cipher
Identifiers: | CCE-83585-0

References:

nerc-cip | CIP-003-8 R4.2
nist | SC-28, SC-28(1)
pcidss | Req-2.2
app-srg-ctr | SRG-APP-000429-CTR-001060
cis | 1.2.31, 2.8
bsi | SYS.1.6.A8
pcidss4 | 2.2.1, 2.2, 3.5.1.3, 3.5.1, 3.5
stigid | CNTR-OS-000780
stigref | SV-257564r1050650_rule

Remediation Kubernetes snippet ⇲

    ---
    apiVersion: config.openshift.io/v1
    kind: APIServer
    metadata:
      name: cluster
      annotations:
        complianceascode.io/ocp-version: '<4.13.0'
    spec:
      encryption:
        type: "aescbc"
    ---
    apiVersion: config.openshift.io/v1
    kind: APIServer
    metadata:
      name: cluster
      annotations:
        complianceascode.io/ocp-version: '>=4.13.0'
    spec:
      encryption:
        type: "aesgcm"

#### Rule Ensure APIServer is configured with secure tlsSecurityProfile [ref]

The configuration `tlsSecurityProfile` specifies TLS configurations to be used while establishing connections with the externally exposed servers. Though secure transport mode is used for establishing connections, the protocols used may not always be strong enough to avoid interception and manipulation of the data in transport. TLS Security profile configured should not make use of any protocols, ciphers, and algorithms with known security vulnerabilities.

`tlsSecurityProfile` can be configured to use one of custom, intermediate, modern, or old profile. Profile Old should be avoided at all times and when using custom profile one should be extremely careful as invalid configurations can be catastrophic. It is always advised to use highly secure intermediate or modern profiles and if unset a default is chosen.

Update tlsSecurityProfile to Intermediate using the following command:

    oc patch apiservers.config.openshift.io cluster --type 'json' --patch '[{"op": "add", "path": "/spec/tlsSecurityProfile/intermediate", "value": {}}, {"op": "replace", "path": "/spec/tlsSecurityProfile/type", "value": "Intermediate"}'

For more information, follow OpenShift documentation: the relevant documentation.

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/apiservers/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/apiservers/cluster` file.

Rationale: | The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol, cipher, or algorithms is used, during transmission of data, the data can be intercepted and manipulated. To thwart the manipulation of the data during transmission secure protocol, cipher and algorithms must be used.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_api_server_tls_security_profile
Identifiers: | CCE-86232-6

References:

nist | SC-8, SC-8(1)
app-srg-ctr | SRG-APP-000014-CTR-000040, SRG-APP-000560-CTR-001340
pcidss4 | 4.2.1, 4.2
stigid | CNTR-OS-000020
stigref | SV-257506r960759_rule

#### Rule Ensure that Audit Log Forwarding Is Enabled [ref]

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
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders` API endpoint to the local `/kubernetes-api-resources/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders` file `true` `/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance` API endpoint to the local `/kubernetes-api-resources/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance` file `true` .

Rationale: | Retaining logs ensures the ability to go back in time to investigate or correlate any events. Offloading audit logs from the cluster ensures that an attacker that has access to the cluster will not be able to tamper with the logs because of the logs being stored off-site.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_audit_log_forwarding_enabled
Identifiers: | CCE-84076-9

References:

nerc-cip | CIP-003-8 R5.2, CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-004-6 R3.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5
nist | AC-2(12), AU-3(2), AU-5(1), AU-6, AU-6(1), AU-6(3), AU-9(2), SI-4(16), AU-4(1), AU-11, AU-7, AU-7(1), SI-4(20)
pcidss | Req-2.2, Req-10.5.3, Req-10.5.4
app-srg-ctr | SRG-APP-000092-CTR-000165, SRG-APP-000111-CTR-000220, SRG-APP-000358-CTR-000805
cis | 1.2.21
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000170, CNTR-OS-000220
stigref | SV-257519r960888_rule, SV-257524r960918_rule

Group Authentication Group contains 5 rules
[ref] In cloud workloads, there are many ways to create and configure to multiple authentication services. Some of these authentication methods by not be secure or common methodologies, or they may not be secure by default. This section introduces mechanisms for configuring authentication systems Kubernetes.

#### Rule Configure An Identity Provider [ref]

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

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

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

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `{{if ne .hypershift_cluster "None"}}/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}{{else}}/apis/config.openshift.io/v1/oauths/cluster{{end}}` API endpoint, filter with with the `jq` utility using the following filter `{{if ne .hypershift_cluster "None"}}.spec.configuration.oauth{{else}}.spec{{end}}` and persist it to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster#489c53adb0325a207f2120d4dee0ef775dad56dceaa74bafc10bf32c1da46e9e` file.

Rationale:

With any authentication mechanism the ability to revoke credentials if they are compromised or no longer required, is a key control. Kubernetes client certificate authentication does not allow for this due to a lack of support for certificate revocation.

OpenShift's built-in OAuth server allows credential revocation by relying on the Identity provider, as well as giving the administrators the ability to revoke any tokens given to a specific user.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_idp_is_configured
Identifiers: | CCE-84088-4

References:

nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3
nist | AC-2, AC-2(1), AC-2(2), AC-2(3), AC-2(4), AC-2(5), AC-2(6), AC-2(7), AC-2(8), AC-7, AC-12(1), IA-2(8), IA-2(9), SC-12(1)
pcidss | Req-2.2, Req-8.1.1
app-srg-ctr | SRG-APP-000023-CTR-000055
cis | 3.1.1
pcidss4 | 2.2.1, 2.2, 8.2.1, 8.2, 8.3
stigid | CNTR-OS-000030, CNTR-OS-000040, CNTR-OS-000440
stigref | SV-257507r1043176_rule, SV-257508r1043176_rule, SV-257542r960993_rule

#### Rule Configure OAuth tokens to expire after a set period of inactivity [ref]

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
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/oauth.openshift.io/v1/oauthclients` API endpoint to the local `/kubernetes-api-resources/apis/oauth.openshift.io/v1/oauthclients` file `/apis/config.openshift.io/v1/oauths/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster` file .

Rationale: | Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a session that has been left unattended.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_oauth_or_oauthclient_inactivity_timeout
Identifiers: | CCE-83702-1

References:

nerc-cip | CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3
nist | AC-2(5), IA-5(13), SC-10
app-srg-ctr | SRG-APP-000190-CTR-000500
pcidss4 | 8.2.8, 8.2
stigid | CNTR-OS-000400, CNTR-OS-000490
stigref | SV-257540r1051115_rule, SV-257544r1015796_rule

Remediation Kubernetes snippet ⇲

    apiVersion: config.openshift.io/v1
    kind: OAuth
    metadata:
      name: cluster
    spec:
      tokenConfig:
        accessTokenInactivityTimeout: {{.var_oauth_inactivity_timeout}}

#### Rule Configure OAuth tokens to expire after a set period of inactivity [ref]

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
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/oauth.openshift.io/v1/oauthclients` API endpoint to the local `/kubernetes-api-resources/apis/oauth.openshift.io/v1/oauthclients` file `/apis/config.openshift.io/v1/oauths/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster` file .

Rationale: | Setting a token maximum age to a shorter time period reduces the window of opportunity for unauthorized personnel to take control of the session.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_oauth_or_oauthclient_token_maxage
Identifiers: | CCE-84162-7

References:

nist | AC-12
app-srg-ctr | SRG-APP-000400-CTR-000960
stigid | CNTR-OS-000760
stigref | SV-257562r961521_rule

Remediation Kubernetes snippet ⇲

    apiVersion: config.openshift.io/v1
    kind: OAuth
    metadata:
      name: cluster
    spec:
      tokenConfig:
        accessTokenMaxAgeSeconds: {{.var_oauth_token_maxage}}

#### Rule Do Not Use htpasswd-based IdP [ref]

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

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

However, not all Identity Providers supported by OpenShift provide the same level of capabilities. As an example, the htpasswd Identity Provider only checks the username and password match and provides no means of 2FA, account lockout or notification mechanism. This rule therefore only allows a subset of identity providers.

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `{{if ne .hypershift_cluster "None"}}/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}{{else}}/apis/config.openshift.io/v1/oauths/cluster{{end}}` API endpoint, filter with with the `jq` utility using the following filter `{{if ne .hypershift_cluster "None"}}.spec.configuration.oauth{{else}}.spec{{end}}` and persist it to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster#489c53adb0325a207f2120d4dee0ef775dad56dceaa74bafc10bf32c1da46e9e` file.

Rationale:

With any authentication mechanism the ability to revoke credentials if they are compromised or no longer required, is a key control. Kubernetes client certificate authentication does not allow for this due to a lack of support for certificate revocation.

OpenShift's built-in OAuth server allows credential revocation by relying on the Identity provider, as well as giving the administrators the ability to revoke any tokens given to a specific user.

In addition, using an external Identity provider allows for setting up notifications on account creation or deletion, multi-factor authentication, disabling inactive accounts or other features required by different compliance standards.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_ocp_idp_no_htpasswd
Identifiers: | CCE-84209-6

References:

nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3
nist | AC-2(1), AC-2(2), AC-2(3), AC-2(4), AC-2(7), AC-2(8), AC-7, IA-2, IA-2(1), IA-2(2), IA-2(3), IA-2(5), IA-2(8), IA-2(9), IA-2(12), IA-5(4), SC-12(1)
app-srg-ctr | SRG-APP-000023-CTR-000055
pcidss4 | 8.3.4, 8.3
stigid | CNTR-OS-000030, CNTR-OS-000040, CNTR-OS-000440
stigref | SV-257507r1043176_rule, SV-257508r1043176_rule, SV-257542r960993_rule

#### Rule Only Use LDAP-based IdPs with TLS [ref]

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

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

If the identity provider is LDAP, setting the `insecure` flag to true would mean that passwords, such as the one used to authenticate the OAuth proxy to the LDAP server would be transmitted in the clear, potentially allowing an attacker to read the password if they captured the network traffic.

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `{{if ne .hypershift_cluster "None"}}/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}{{else}}/apis/config.openshift.io/v1/oauths/cluster{{end}}` API endpoint, filter with with the `jq` utility using the following filter `{{if ne .hypershift_cluster "None"}}.spec.configuration.oauth{{else}}.spec{{end}}` and persist it to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster#489c53adb0325a207f2120d4dee0ef775dad56dceaa74bafc10bf32c1da46e9e` file.

Rationale: | Transmitting authentication tokens as clear-text may leak them to an attacker.
Severity: | high
Rule ID: | xccdf_org.ssgproject.content_rule_ocp_no_ldap_insecure
Identifiers: | CCE-83699-9

References:

nerc-cip | CIP-003-8 R4.2, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3
nist | IA-2(8), IA-2(9), SC-8
pcidss | Req-2.3
app-srg-ctr | SRG-APP-000023-CTR-000055
pcidss4 | 2.2.7, 2.2, 8.3.2, 8.3
stigid | CNTR-OS-000030, CNTR-OS-000040
stigref | SV-257507r1043176_rule, SV-257508r1043176_rule

Group Kubernetes - General Security Practices Group contains 10 rules
[ref] Contains evaluations for general security practices for operating a Kubernetes environment.

#### Rule Enable Classification Banner on OpenShift Console [ref]

A classification banner can be configured by creating a Console Notification CR on OpenShift
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/console.openshift.io/v1/consolenotifications/classification-banner` API endpoint to the local `/kubernetes-api-resources/apis/console.openshift.io/v1/consolenotifications/classification-banner` file.

Rationale: | Displays to users organization-defined system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_classification_banner
Identifiers: | CCE-84197-3

References:

nist | AC-8
app-srg-ctr | SRG-APP-000068-CTR-000120
stigid | CNTR-OS-000130
stigref | SV-257516r960843_rule

#### Rule Ensure that the kubeadmin secret has been removed [ref]

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
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/api/v1/namespaces/kube-system/secrets/kubeadmin` API endpoint to the local `/kubernetes-api-resources/api/v1/namespaces/kube-system/secrets/kubeadmin` file.

Rationale:

The kubeadmin user has an auto-generated password and a self-signed certificate, and has effectively

    cluster-admin

permissions; therefore, it's considered a security liability.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_kubeadmin_removed
Identifiers: | CCE-90387-2

References:

nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R2, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R6.1, CIP-007-3 R6.2, CIP-007-3 R6.3, CIP-007-3 R6.4
nist | AC-2(2), AC-2(7), AC-2(9), AC-2(10), AC-12(1), IA-2(5), MA-4, SC-12(1)
pcidss | Req-2.1
app-srg-ctr | SRG-APP-000023-CTR-000055
cis | 3.1.1, 5.1.1
bsi | APP.4.4.A3
pcidss4 | 2.2.1, 2.2.2, 2.2, 8.2.2, 8.2, 8.3
stigid | CNTR-OS-000030, CNTR-OS-000040, CNTR-OS-000440
stigref | SV-257507r1043176_rule, SV-257508r1043176_rule, SV-257542r960993_rule

#### Rule Ensure that the OpenShift OAuth login template is set [ref]

A legal notice can be configured via a customized login template.
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
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `{{if ne .hypershift_cluster "None"}}/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}{{else}}/apis/config.openshift.io/v1/oauths/cluster{{end}}` API endpoint, filter with with the `jq` utility using the following filter `{{if ne .hypershift_cluster "None"}}.spec.configuration.oauth{{else}}.spec{{end}}` and persist it to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster#489c53adb0325a207f2120d4dee0ef775dad56dceaa74bafc10bf32c1da46e9e` file.

Rationale: | Displays to users organization-defined system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_oauth_login_template_set
Identifiers: | CCE-84198-1

References:

nist | AC-8
app-srg-ctr | SRG-APP-000068-CTR-000120
stigid | CNTR-OS-000130
stigref | SV-257516r960843_rule

#### Rule Ensure that the OpenShift OAuth logout URL is set [ref]

The user can be redirected to a configured URL upon logout
This is achievable via the OAuth object by setting the `logoutRedirect` attribute. Refer to the relevant documentation
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/consoles/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/consoles/cluster` file.

Rationale:

The web console's default logout will invalidate the user's session token and redirect back to the console page, which will redirect the user to the authentication page. There is no explicit logout message. And in addition, if the IdP provider type is OIDC, the session token from the SSO provider will remain valid, which would effectively keep the user logged in. To correct this, the web console needs to be configured to redirect the user to a logout page. If using an OIDC provider, this would be the logout page for that provider.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_oauth_logout_url_set
Identifiers: | CCE-90780-8

References:

nist | AC-12(1)
app-srg-ctr | SRG-APP-000297-CTR-000705
stigid | CNTR-OS-000650
stigref | SV-257556r961227_rule

#### Rule Ensure that the OpenShift OAuth provider selection is set [ref]

Custom login pages can be helpful to show users a branded page that they trust and expect before being redirected to the authentication provider.
This is achievable via the OAuth object by creating a custom login template, storing it in a Kubernetes Secret and referencing it in the appropriate field as described in the documentation
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `{{if ne .hypershift_cluster "None"}}/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}{{else}}/apis/config.openshift.io/v1/oauths/cluster{{end}}` API endpoint, filter with with the `jq` utility using the following filter `{{if ne .hypershift_cluster "None"}}.spec.configuration.oauth{{else}}.spec{{end}}` and persist it to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster#489c53adb0325a207f2120d4dee0ef775dad56dceaa74bafc10bf32c1da46e9e` file.

Rationale: | Displays to users organization-defined IdP selection
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_oauth_provider_selection_set
Identifiers: | CCE-90666-9

References:

nist | AC-8
app-srg-ctr | SRG-APP-000068-CTR-000120
stigid | CNTR-OS-000130
stigref | SV-257516r960843_rule

#### Rule Ensure that the OpenShift MOTD is set [ref]

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.`
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/api/v1/namespaces/openshift/configmaps/motd` API endpoint to the local `/kubernetes-api-resources/api/v1/namespaces/openshift/configmaps/motd` file.

Rationale:

Display of a standardized and approved use notification before granting access to the system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_openshift_motd_exists
Identifiers: | CCE-84200-5

References:

nist | AC-8
app-srg-ctr | SRG-APP-000068-CTR-000120
stigid | CNTR-OS-000130
stigref | SV-257516r960843_rule

#### Rule Ensure that project templates autocreate Resource Quotas [ref]

Configure a template for newly created projects to use default resource quotas and make sure this template is referenced from the default project template.

The OpenShift Container Platform API server automatically provisions new projects based on the project template that is identified by the `projectRequestTemplate` parameter in the cluster’s project configuration resource.

As a cluster administrator, you can modify the default project template so that new projects created would satisfy the chosen compliance standards.

For more information, follow the relevant documentation.

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/projects/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/projects/cluster` file. This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/template.openshift.io/v1/namespaces/openshift-config/templates` API endpoint, filter with with the `jq` utility using the following filter `[.items[] | any(.objects[]?; .kind == "ResourceQuota") ]` and persist it to the local `/kubernetes-api-resources/apis/template.openshift.io/v1/namespaces/openshift-config/templates#e60f58ef612a182073e9f6fe0ebe9ea96a706422dc65572af8d6aa9839d94f61` file.

Rationale:

Running different applications on the same Kubernetes cluster creates a risk of a "noisy neighbor" when one application monopolizes cluster resources. 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.

Editing the default project template to include ResourceQuotas in all new namespaces ensures that all namespaces include at least some ResourceQuotas objects.

Ensuring that the project configuration references a project template that sets up the required objects for new projects ensures that all new projects will be set in accordance with centralized settings.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_project_config_and_template_resource_quota
Identifiers: | CCE-90734-5

References:

nist | SC-5, SC-5(1)
app-srg-ctr | SRG-APP-000246-CTR-000605, SRG-APP-000435-CTR-001070
bsi | SYS.1.6.A15
stigid | CNTR-OS-000620, CNTR-OS-000630, CNTR-OS-000800, CNTR-OS-000810
stigref | SV-257554r961152_rule, SV-257555r961152_rule, SV-257565r961620_rule, SV-257566r961620_rule

Remediation Kubernetes snippet ⇲

    ---
    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
      name: cluster
    spec:
      projectRequestTemplate:
        name: co-project-request
    ---
    apiVersion: template.openshift.io/v1
    kind: Template
    metadata:
      creationTimestamp: null
      name: co-project-request
      namespace: openshift-config
    objects:
    - apiVersion: project.openshift.io/v1
      kind: Project
      metadata:
        annotations:
          openshift.io/description: ${PROJECT_DESCRIPTION}
          openshift.io/display-name: ${PROJECT_DISPLAYNAME}
          openshift.io/requester: ${PROJECT_REQUESTING_USER}
        creationTimestamp: null
        name: ${PROJECT_NAME}
      spec: {}
      status: {}
    - apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        creationTimestamp: null
        name: admin
        namespace: ${PROJECT_NAME}
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: admin
      subjects:
      - apiGroup: rbac.authorization.k8s.io
        kind: User
        name: ${PROJECT_ADMIN_USER}
    - apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: ${PROJECT_NAME}-quota
      spec:
        hard:
          cpu: "2"
          memory: 5Gi
          pods: "40"
    - apiVersion: "v1"
      kind: "LimitRange"
      metadata:
        name: ${PROJECT_NAME}-limit-range
      spec:
        limits:
          - type: "Container"
            default:
              cpu: "200m"
            defaultRequest:
              cpu: "10m"
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-same-namespace
      spec:
        podSelector: {}
        ingress:
        - from:
          - podSelector: {}
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
    parameters:
    - name: PROJECT_NAME
    - name: PROJECT_DISPLAYNAME
    - name: PROJECT_DESCRIPTION
    - name: PROJECT_ADMIN_USER
    - name: PROJECT_REQUESTING_USER

#### Rule Ensure workloads use resource requests and limits per namespace [ref]

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

To configure ResourceQuota Per Project, follow the directions in the documentation

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/api/v1/resourcequotas` API endpoint, filter with with the `jq` utility using the following filter `[.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default" and .metadata.namespace != "rhacs-operator" and ({{if ne .var_resource_requests_quota_per_project_exempt_regex "None"}}.metadata.namespace | test("{{.var_resource_requests_quota_per_project_exempt_regex}}") | not{{else}}true{{end}})) | .metadata.namespace] | unique` and persist it to the local `/kubernetes-api-resources/api/v1/resourcequotas#4326a181a1e3e8a8e02ffb58e7d3ca9e62ed0e144a5277b1f7551fdbcfeca0a8` file.
- `/api/v1/namespaces` API endpoint, filter with with the `jq` utility using the following filter `[.items[] | select((.metadata.name | startswith("openshift") | not) and (.metadata.name | startswith("kube-") | not) and .metadata.name != "default" and .metadata.name != "rhacs-operator" and ({{if ne .var_resource_requests_quota_per_project_exempt_regex "None"}}.metadata.name | test("{{.var_resource_requests_quota_per_project_exempt_regex}}") | not{{else}}true{{end}}))]` and persist it to the local `/kubernetes-api-resources/api/v1/namespaces#3ae63defe5cbb61225edb84d8e19f601be933d063305c1ea1e0381297c6258d6` file.

Rationale: | Resource quotas provide constraints that limit aggregate resource consumption per project. This helps prevent resource starvation. When deploying your application, it is important to tune based on memory and CPU consumption, allocating enough resources for the application to function properly.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_resource_requests_quota_per_project
Identifiers: | CCE-90582-8

References:

nist | SC-5, SC-5(1), SC-5(2), SI-16
app-srg-ctr | SRG-APP-000246-CTR-000605, SRG-APP-000435-CTR-001070, SRG-APP-000450-CTR-001105
bsi | SYS.1.6.A15
stigid | CNTR-OS-000620, CNTR-OS-000630, CNTR-OS-000800, CNTR-OS-000810, CNTR-OS-000860, CNTR-OS-000870
stigref | SV-257554r961152_rule, SV-257555r961152_rule, SV-257565r961620_rule, SV-257566r961620_rule, SV-257568r961665_rule, SV-257569r961665_rule

#### Rule This is a helper rule to fetch the required api resource for detecting HyperShift OCP version [ref]

no description
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}` API endpoint, filter with with the `jq` utility using the following filter `[.status.version.history[].version]` and persist it to the local `/kubernetes-api-resources/hypershift/version` file. This rule will be a hidden rule `true` `true`

Rationale: | no rationale
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_version_detect_in_hypershift

#### Rule This is a helper rule to fetch the required api resource for detecting OCP version [ref]

no description
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `{{.ocp_version_api_path}}` API endpoint, filter with with the `jq` utility using the following filter `{{.ocp_version_yaml_path}}` and persist it to the local `/kubernetes-api-resources/ocp/version` file. This rule will be a hidden rule `true` `true`

Rationale: | no rationale
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_version_detect_in_ocp

Group OpenShift - Logging Settings Group contains 4 rules
[ref] Contains evaluations for the cluster's logging configuration settings.

#### Rule Ensure that Audit Log Errors Emit Alerts [ref]

OpenShift audit works at the API server level, logging all requests coming to the server. However, if API server instance is unable to write errors, an alert must be issued in order for the organization to take a relevant action. e.g. shutting down that instance.

Kubernetes by default has metrics that enable one to write such alerts:

- `apiserver_audit_event_total`
- `apiserver_audit_error_total`

Such an example is shipped in OCP 4.9+

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: audit-errors
      namespace: openshift-kube-apiserver
    spec:
      groups:
      - name: apiserver-audit
        rules:
        - alert: AuditLogError
          annotations:
            summary: |-
              An API Server instance was unable to write audit logs. This could be
              triggered by the node running out of space, or a malicious actor
              tampering with the audit logs.
            description: An API Server had an error writing to an audit log.
          expr: |
            sum by (apiserver,instance)(rate(apiserver_audit_error_total{apiserver=~".+-apiserver"}[5m])) / sum by (apiserver,instance) (rate(apiserver_audit_event_total{apiserver=~".+-apiserver"}[5m])) > 0
          for: 1m
          labels:
            severity: warning

For more information, consult the official Kubernetes documentation.

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/monitoring.coreos.com/v1/prometheusrules` API endpoint, filter with with the `jq` utility using the following filter `[.items[].spec.groups[].rules[].expr]` and persist it to the local `/kubernetes-api-resources/apis/monitoring.coreos.com/v1/prometheusrules#5fd5244e3dcae63319f7e86b918cb8ea6ce1b4124670ccb43750d7a75ca03cb7` file.

Rationale: | When there are errors writing audit logs, security events will not be logged by that specific API Server instance. Security Incident Response teams use these audit logs, amongst other artifacts, to determine the impact of security breaches or events. Without these logs, it becomes very difficult to assess a situation and do appropriate root cause analysis in such incidents.
Severity: | high
Rule ID: | xccdf_org.ssgproject.content_rule_audit_error_alert_exists
Identifiers: | CCE-90744-4

References:

nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2
nist | AU-5
app-srg-ctr | SRG-APP-000109-CTR-000215
pcidss4 | 10.7.2, 10.7
stigid | CNTR-OS-000200, CNTR-OS-000210
stigref | SV-257522r960903_rule, SV-257523r1050555_rule

Remediation Kubernetes snippet ⇲

    ---
    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: audit-errors
      namespace: openshift-kube-apiserver
    spec:
      groups:
      - name: apiserver-audit
        rules:
        - alert: AuditLogError
          annotations:
            summary: |-
              An API Server instance was unable to write audit logs. This could be
              triggered by the node running out of space, or a malicious actor
              tampering with the audit logs.
            description: An API Server had an error writing to an audit log.
          expr: |
            sum by (apiserver,instance)(rate(apiserver_audit_error_total{apiserver=~".+-apiserver"}[5m])) / sum by (apiserver,instance) (rate(apiserver_audit_event_total{apiserver=~".+-apiserver"}[5m])) > 0
          for: 1m
          labels:
            severity: warning

#### Rule Ensure that Audit Log Forwarding Uses TLS [ref]

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
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the . This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance` API endpoint, filter with with the `jq` utility using the following filter `try [.spec.outputs[].url] catch []` and persist it to the local `/kubernetes-api-resources/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance#71786452ba18c51ba8ad51472a078619e2e8b52a86cd75087af5aab42400f6c0` file. `true`
- `/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders` API endpoint, filter with with the `jq` utility using the following filter `try [.items[].spec.outputs[][]|objects|select(.url != null).url] catch []` and persist it to the local `/kubernetes-api-resources/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders#6130fc8305d3ddbbd4c19894d093ff20666be7e070498439f5dbe08dd4ed0672` file. `true`

Rationale: | It is necessary to ensure that any configured output uses the TLS protocol to receive logs in order to ensure the confidentiality, integrity and authenticity of the logs.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_audit_log_forwarding_uses_tls
Identifiers: | CCE-90688-3

References:

nerc-cip | CIP-003-8 R5.2, CIP-004-6 R3.3, CIP-007-3 R6.5
nist | AU-9, AU-9(2), AU-9(3), AU-10
app-srg-ctr | SRG-APP-000126-CTR-000275
stigid | CNTR-OS-000340, CNTR-OS-000510
stigref | SV-257536r960951_rule, SV-257546r1043178_rule

#### Rule Ensure that the cluster's audit profile is properly set [ref]

OpenShift can audit the details of requests made to the API server through the standard Kubernetes audit capabilities.

In OpenShift, auditing of the API Server is on by default. Audit provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators, or other components of the system. Audit works at the API server level, logging all requests coming to the server. Each audit log contains two entries:

The request line containing:

- A Unique ID allowing to match the response line (see #2)
- The source IP of the request
- The HTTP method being invoked
- The original user invoking the operation
- The impersonated user for the operation (self meaning himself)
- The impersonated group for the operation (lookup meaning user's group)
- The namespace of the request or none
- The URI as requested

The response line containing:

- The aforementioned unique ID
- The response code

For more information on how to configure the audit profile, please visit the documentation

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/apiservers/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/apiservers/cluster` file.

Rationale: | Logging is an important detective control for all systems, to detect potential unauthorised access.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_audit_profile_set
Identifiers: | CCE-83577-7

References:

nerc-cip | CIP-003-8 R4, CIP-003-8 R4.1, CIP-003-8 R4.2, CIP-003-8 R5.2, CIP-003-8 R6, CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-004-6 R3.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5
nist | AU-2, AU-3, AU-3(1), AU-6, AU-6(1), AU-7, AU-7(1), AU-8, AU-8(1), AU-9, AU-12, AU-12(1), AU-12(3), CM-5(1), SI-11, SI-12, SI-4(20), SI-4(23)
pcidss | Req-2.2, Req-12.5.5
app-srg-ctr | SRG-APP-000089-CTR-000150, SRG-APP-000090-CTR-000155, SRG-APP-000101-CTR-000205
cis | 3.2.2
pcidss4 | 2.2.1, 2.2, 10.2.2, 10.2
stigid | CNTR-OS-000150
stigref | SV-257517r960879_rule

Remediation Kubernetes snippet ⇲

    ---
    apiVersion: config.openshift.io/v1
    kind: APIServer
    metadata:
      name: cluster
    spec:
      audit:
        profile: {{.var_openshift_audit_profile}}

#### Rule Ensure that OpenShift Logging Operator is scanning the cluster [ref]

OpenShift Logging Operator provides ability to aggregate all the logs from the OpenShift Container Platform cluster, such as node system audit logs, application container logs, and infrastructure logs. OpenShift Logging aggregates these logs from throughout OpenShift cluster and stores them in a default log store. [1] [1]https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-about.html
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterloggings/instance` API endpoint to the local `/kubernetes-api-resources/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterloggings/instance` file `/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders` API endpoint to the local `/kubernetes-api-resources/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders` file .

Rationale: | OpenShift Logging Operator is able to collect, aggregate, and manage logs.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_cluster_logging_operator_exist
Identifiers: | CCE-85918-1

References:

nist | AU-3(2)
app-srg-ctr | SRG-APP-000092-CTR-000165, SRG-APP-000111-CTR-000220, SRG-APP-000358-CTR-000805
stigid | CNTR-OS-000170, CNTR-OS-000220
stigref | SV-257519r960888_rule, SV-257524r960918_rule

Group Kubernetes - Network Configuration and Firewalls Group contains 5 rules

[ref] Most systems must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system.
This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks.

#### Rule Ensure that the CNI in use supports Network Policies [ref]

There are a variety of CNI plugins available for Kubernetes. If the CNI in use does not support Network Policies it may not be possible to effectively restrict traffic in the cluster. OpenShift supports Kubernetes NetworkPolicy using a Kubernetes Container Network Interface (CNI) plug-in.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/operator.openshift.io/v1/networks/cluster` API endpoint, filter with with the `jq` utility using the following filter `[.spec.defaultNetwork.type]` and persist it to the local `/kubernetes-api-resources/apis/operator.openshift.io/v1/networks/cluster#35e33d6dc1252a03495b35bd1751cac70041a511fa4d282c300a8b83b83e3498` file.

Rationale: | Kubernetes network policies are enforced by the CNI plugin in use. As such it is important to ensure that the CNI plugin supports both Ingress and Egress network policies.
Severity: | high
Rule ID: | xccdf_org.ssgproject.content_rule_configure_network_policies

References:

nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1
nist | CM-6, CM-6(1)
pcidss | Req-1.1.4, Req-1.2, Req-2.2
app-srg-ctr | SRG-APP-000038-CTR-000105
cis | 5.3.1
bsi | APP.4.4.A7, APP.4.4.A18, SYS.1.6.A5, SYS.1.6.A21
pcidss4 | 1.4.1, 1.4, 2.2.1, 2.2
stigid | CNTR-OS-000100
stigref | SV-257514r960801_rule

#### Rule Ensure that application Namespaces have Network Policies defined. [ref]

Use network policies to isolate traffic in your cluster network.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/networking.k8s.io/v1/networkpolicies` API endpoint, filter with with the `jq` utility using the following filter `[.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default" and ({{if ne .var_network_policies_namespaces_exempt_regex "None"}}.metadata.namespace | test("{{.var_network_policies_namespaces_exempt_regex}}") | not{{else}}true{{end}})) | .metadata.namespace] | unique` and persist it to the local `/kubernetes-api-resources/apis/networking.k8s.io/v1/networkpolicies#7400bb301fff2f7fc7b1b0fb7448b8e3f15222a8d23f992204315b19eeefa72f` file.
- `/api/v1/namespaces` API endpoint, filter with with the `jq` utility using the following filter `[.items[] | select((.metadata.name | startswith("openshift") | not) and (.metadata.name | startswith("kube-") | not) and .metadata.name != "default" and ({{if ne .var_network_policies_namespaces_exempt_regex "None"}}.metadata.name | test("{{.var_network_policies_namespaces_exempt_regex}}") | not{{else}}true{{end}}))]` and persist it to the local `/kubernetes-api-resources/api/v1/namespaces#f673748db2dd4e4f0ad55d10ce5e86714c06da02b67ddb392582f71ef81efab2` file.

Rationale:

Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace.

Severity: | high
Rule ID: | xccdf_org.ssgproject.content_rule_configure_network_policies_namespaces

References:

nerc-cip | CIP-003-8 R4, CIP-003-8 R4.2, CIP-003-8 R5, CIP-003-8 R6, CIP-004-6 R2.2.4, CIP-004-6 R3, CIP-007-3 R2, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R6.1
nist | AC-4, AC-4(21), CA-3(5), CM-6, CM-6(1), CM-7, CM-7(1), SC-7, SC-7(3), SC-7(5), SC-7(8), SC-7(12), SC-7(13), SC-7(18), SC-7(10), SI-4(22)
pcidss | Req-1.1.4, Req-1.2, Req-1.2.1, Req-1.3.1, Req-1.3.2, Req-2.2
app-srg-ctr | SRG-APP-000038-CTR-000105
cis | 5.3.2
bsi | APP.4.4.A7, APP.4.4.A18, SYS.1.6.A5, SYS.1.6.A21
pcidss4 | 1.2.6, 1.2, 1.3.1, 1.3, 1.4.1, 1.4, 2.2.1, 2.2
stigid | CNTR-OS-000100
stigref | SV-257514r960801_rule

#### Rule Ensure IngressController is configured to use secure tlsSecurityProfile [ref]

The configuration `tlsSecurityProfile` specifies TLS configurations to be used while establishing connections with the externally exposed servers. Though secure transport mode is used for establishing connections, the protocols used may not always be strong enough to avoid interception and manipulation of the data in transport. TLS Security profile configured should not make use of any protocols, ciphers, and algorithms with known security vulnerabilities.

`tlsSecurityProfile` can be configured to use one of custom, intermediate, modern, or old profile. Profile Old should be avoided at all times and when using custom profile one should be extremely careful as invalid configurations can be catastrophic. It is always advised to use highly secure intermediate or modern profiles and if unset profile configured in apiservers.config.openshift.io/cluster resource will be used as default.

To update tlsSecurityProfile to Intermediate use the following command:

    oc patch -n openshift-ingress-operator ingresscontrollers.operator.openshift.io default --type 'json' --patch '[{"op": "add", "path": "/spec/tlsSecurityProfile/intermediate", "value": {}}, {"op": "replace", "path": "/spec/tlsSecurityProfile/type", "value": "Intermediate"}'

For more information, follow OpenShift documentation: the relevant documentation.

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default` API endpoint to the local `/kubernetes-api-resources/apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default` file.

Rationale: | The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol, cipher, or algorithms is used, during transmission of data, the data can be intercepted and manipulated. To thwart the manipulation of the data during transmission secure protocol, cipher and algorithms must be used.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_ingress_controller_tls_security_profile
Identifiers: | CCE-86234-2

References:

nist | SC-8, SC-8(1)
app-srg-ctr | SRG-APP-000014-CTR-000040, SRG-APP-000560-CTR-001340
pcidss4 | 4.2.1, 4.2
stigid | CNTR-OS-000020
stigref | SV-257506r960759_rule

#### Rule Ensure that project templates autocreate Network Policies [ref]

Configure a template for newly created projects to use default network policies and make sure this template is referenced from the default project template. The OpenShift Container Platform API server automatically provisions new projects based on the project template that is identified by the `projectRequestTemplate` parameter in the cluster’s project configuration resource. As a cluster administrator, you can modify the default project template so that new projects created would satisfy the chosen compliance standards. For more information on configuring default network policies, follow the relevant documentation.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/projects/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/projects/cluster` file. This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/template.openshift.io/v1/namespaces/openshift-config/templates` API endpoint, filter with with the `jq` utility using the following filter `[.items[] | any(.objects[]?; .kind == "NetworkPolicy") ]` and persist it to the local `/kubernetes-api-resources/apis/template.openshift.io/v1/namespaces/openshift-config/templates#8044d7f899788c96acdbb06244837a64dfa1e0973c59b2ad26596e080e12482d` file.

Rationale:

Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. Editing the default project template to include NetworkPolicies in all new namespaces ensures that all namespaces include at least some NetworkPolicy objects. Ensuring that the project configuration references a project template that sets up the required objects for new projects ensures that all new projects will be set in accordance with centralized settings.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_project_config_and_template_network_policy
Identifiers: | CCE-86070-0

References:

app-srg-ctr | SRG-APP-000039-CTR-000110
bsi | APP.4.4.A7, APP.4.4.A18
stigid | CNTR-OS-000110
stigref | SV-257515r960804_rule

Remediation Kubernetes snippet ⇲

    ---
    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
      name: cluster
    spec:
      projectRequestTemplate:
        name: co-project-request
    ---
    apiVersion: template.openshift.io/v1
    kind: Template
    metadata:
      creationTimestamp: null
      name: co-project-request
      namespace: openshift-config
    objects:
    - apiVersion: project.openshift.io/v1
      kind: Project
      metadata:
        annotations:
          openshift.io/description: ${PROJECT_DESCRIPTION}
          openshift.io/display-name: ${PROJECT_DISPLAYNAME}
          openshift.io/requester: ${PROJECT_REQUESTING_USER}
        creationTimestamp: null
        name: ${PROJECT_NAME}
      spec: {}
      status: {}
    - apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        creationTimestamp: null
        name: admin
        namespace: ${PROJECT_NAME}
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: admin
      subjects:
      - apiGroup: rbac.authorization.k8s.io
        kind: User
        name: ${PROJECT_ADMIN_USER}
    - apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: ${PROJECT_NAME}-quota
      spec:
        hard:
          cpu: "2"
          memory: 5Gi
          pods: "40"
    - apiVersion: "v1"
      kind: "LimitRange"
      metadata:
        name: ${PROJECT_NAME}-limit-range
      spec:
        limits:
          - type: "Container"
            default:
              cpu: "200m"
            defaultRequest:
              cpu: "10m"
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-same-namespace
      spec:
        podSelector: {}
        ingress:
        - from:
          - podSelector: {}
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
    parameters:
    - name: PROJECT_NAME
    - name: PROJECT_DISPLAYNAME
    - name: PROJECT_DESCRIPTION
    - name: PROJECT_ADMIN_USER
    - name: PROJECT_REQUESTING_USER

#### Rule Ensure that all Routes has rate limit enabled [ref]

OpenShift has an option to set the rate limit for Routes [1] when creating new Routes. All routes outside the excluded namespaces (as defined by the variable `ocp4-var-routes-excluded-namespaces-regex`) should use the rate-limiting annotations. [1] https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/route.openshift.io/v1/routes?limit=500` API endpoint, filter with with the `jq` utility using the following filter `[.items[] | select(.metadata.namespace | test("{{.var_routes_excluded_namespaces_regex}}"; "") | not) | select(.metadata.annotations["haproxy.router.openshift.io/rate-limit-connections"] == "true" | not) | .metadata.name]` and persist it to the local `/kubernetes-api-resources/apis/route.openshift.io/v1/routes?limit=500#c164470de9c6e753bac432d8c3f994b5ff7a8d0cd3d072d6f7f63c7a35937424` file.

Rationale: | The usage of rate limit for Routes provides basic protection against distributed denial-of-service (DDoS) attacks.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_routes_rate_limit
Identifiers: | CCE-90779-0

References:

nist | SC-5, SC-5(1), SC-5(2)
app-srg-ctr | SRG-APP-000246-CTR-000605, SRG-APP-000435-CTR-001070
stigid | CNTR-OS-000620, CNTR-OS-000630, CNTR-OS-000800, CNTR-OS-000810
stigref | SV-257554r961152_rule, SV-257555r961152_rule, SV-257565r961620_rule, SV-257566r961620_rule

Group Role-based Access Control Group contains 4 rules

[ref] Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. Cluster administrators can use the cluster roles and bindings to control who has various access levels to the OpenShift Container Platform platform itself and all projects. Developers can use local roles and bindings to control who has access to their projects. Note that authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.

#### Rule Ensure that the RBAC setup follows the principle of least privilege [ref]

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

Rationale:

Controlling and limiting users access to system services and resources is key to securing the platform and limiting the intentional or unintentional comprimising of the system and its services. OpenShift provides a robust RBAC policy system that allows for authorization policies to be as detailed as needed. Additionally there are two layers of RBAC policies, the first is Cluster RBAC policies which administrators can control who has what access to cluster level services. The other is Local RBAC policies, which allow project developers/administrators to control what level of access users have to a given project or namespace.

Severity: | high
Rule ID: | xccdf_org.ssgproject.content_rule_rbac_least_privilege
Identifiers: | CCE-90678-4

References:

nist | AC-3, CM-5(6), IA-2, IA-2(5), AC-6(10), CM-11(2), CM-5(1), CM-7(5)(b)

app-srg-ctr

SRG-APP-000033-CTR-000090, SRG-APP-000033-CTR-000095, SRG-APP-000033-CTR-000100, SRG-APP-000133-CTR-000290, SRG-APP-000133-CTR-000295, SRG-APP-000133-CTR-000300, SRG-APP-000133-CTR-000305, SRG-APP-000133-CTR-000310, SRG-APP-000148-CTR-000350, SRG-APP-000153-CTR-000375, SRG-APP-000340-CTR-000770, SRG-APP-000378-CTR-000880, SRG-APP-000378-CTR-000885, SRG-APP-000378-CTR-000890, SRG-APP-000380-CTR-000900, SRG-APP-000386-CTR-000920

cis | 5.2.10
bsi | APP.4.4.A3, APP.4.4.A7, APP.4.4.A9, SYS.1.6.A8, SYS.1.6.A19
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000090
stigref | SV-257513r1015793_rule

#### Rule Ensure that the ClusterLogging and ClusterLoggingForwarder resources are protected from unauthorized deletion [ref]

The ClusterLogging and ClusterLoggingForwarder Custom Resources provide a way to configure the logging forwarding subsystem and delete access to it should be restricted to as-needed basis. Remove delete permissions from any unauthorized user or group by performing one or more of the following commands: * Remove role from user > oc adm policy remove-role-from-user ROLE USER -n openshift-logging * Remove role from group > oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging * Remove cluster role from user > oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging * Remove cluster role from group > oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging Where ROLE/CLUSTER_ROLE is the role granting user delete permission to resources in openshift-logging namespace.}

Rationale: | Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_rbac_logging_del
Identifiers: | CCE-90433-4

References:

nist | AU-9
app-srg-ctr | SRG-APP-000123-CTR-000265
stigid | CNTR-OS-000330
stigref | SV-257535r960939_rule

#### Rule Ensure that the ClusterLogging and ClusterLoggingForwarder resources are protected from unauthorized modification [ref]

The ClusterLogging and ClusterLoggingForwarder Custom Resources provide a way to configure the logging forwarding subsystem and modification access to it should be restricted to as-needed basis. Remove edit permissions from any unauthorized user or group by performing one or more of the following commands: * Remove role from user > oc adm policy remove-role-from-user ROLE USER -n openshift-logging * Remove role from group > oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging * Remove cluster role from user > oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging * Remove cluster role from group > oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging Where ROLE/CLUSTER_ROLE is the role granting user edit permission to resources in openshift-logging namespace.}

Rationale: | Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_rbac_logging_mod
Identifiers: | CCE-90717-0

References:

nist | AU-9
app-srg-ctr | SRG-APP-000122-CTR-000260
stigid | CNTR-OS-000330
stigref | SV-257535r960939_rule

#### Rule Ensure that the ClusterLogging and ClusterLoggingForwarder resources are protected from unauthorized access [ref]

The ClusterLogging and ClusterLoggingForwarder Custom Resources provide a way to configure the logging forwarding subsystem and view access to it should be restricted to as-needed basis. Remove view permissions from any unauthorized user or group by performing one or more of the following commands: * Remove role from user > oc adm policy remove-role-from-user ROLE USER -n openshift-logging * Remove role from group > oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging * Remove cluster role from user > oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging * Remove cluster role from group > oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging Where ROLE/CLUSTER_ROLE is the role granting user view permission to resources in openshift-logging namespace.}

Rationale: | Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_rbac_logging_view
Identifiers: | CCE-90648-7

References:

nist | AU-9
app-srg-ctr | SRG-APP-000121-CTR-000255
stigid | CNTR-OS-000320, CNTR-OS-000330
stigref | SV-257534r960939_rule, SV-257535r960939_rule

Group Kubernetes - Registry Security Practices Group contains 6 rules
[ref] Contains evaluations for Kubernetes registry security practices, and cluster-wide registry configuration.

#### Rule Configure ImagePruner so that images that are no longer needed are automatically removed [ref]

Images from the internal registry that are no longer required by the system due to age, status, or exceed limits are automatically pruned. Cluster administrators can configure the Pruning Custom Resource, or suspend it.

For more information on configuring the ImagePruner, consult the OpenShift documentation: https://access.redhat.com/documentation/en-us/openshift_container_platform/latest/html/building_applications/pruning-objects

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/imageregistry.operator.openshift.io/v1/imagepruners/cluster` API endpoint to the local `/kubernetes-api-resources/apis/imageregistry.operator.openshift.io/v1/imagepruners/cluster` file.

Rationale:

Obsolete and stale images need to be removed from the registry to ensure the container platform maintains a secure posture. While the storing of these images does not directly pose a threat, they do increase the likelihood of these images being deployed.

Removing stale or obsolete images and only keeping the most recent versions of those that are still in use removes any possibility of vulnerable images being deployed.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_image_pruner_active
Identifiers: | CCE-86480-1

References:

nist | SI-2(6)
app-srg-ctr | SRG-APP-000454-CTR-001110, SRG-APP-000454-CTR-001115
stigid | CNTR-OS-000880
stigref | SV-257570r961677_rule

#### Rule All configured ImageStreams are configured to periodically check for updates [ref]

The configuration `imagestream.spec.tags.importPolicy.scheduled` determines whether the imagestream is configured to periodically check for updates. This is useful when working with an external container image registry, to periodically re-import an image, for example to get latest security updates.

You can set the scheduled update by calling:

    $ oc patch imagestream NAME -n NAMESPACE --type merge -p '{"spec":{"tags":[{"name":"TAG_NAME","importPolicy":{"scheduled":true}}]}}'

For more information, follow the ImageStreams documentation

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/image.openshift.io/v1/imagestreams` API endpoint, filter with with the `jq` utility using the following filter `[[.items[] | ( .spec.tags[]?.from.kind != "ImageStreamTag" and ([.spec.tags[]? | (.importPolicy.scheduled == null or .importPolicy.scheduled == false)] | any) ) and ((.metadata.labels == null) or (.metadata.labels."samples.operator.openshift.io/managed" == null) or (.metadata.labels."samples.operator.openshift.io/managed" != "true")) and ((.metadata.ownerReferences == null) or (.metadata.ownerReferences | length == 0) or (.metadata.ownerReferences?[].kind == null) or (isempty(.metadata.ownerReferences?[] | select(.kind == "ClusterVersion"))))] | any]` and persist it to the local `/kubernetes-api-resources/apis/image.openshift.io/v1/imagestreams#49d105fb783b79a6715948aa324d171607e5367a9f463a3727a84c129782e6c2` file.

Rationale: | Periodical refresh of container images helps keep the images up-to-date and apply any relevant updates in a timely manner.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_imagestream_sets_schedule

References:

nist | SI-2(c)
app-srg-ctr | SRG-APP-000456-CTR-001125
stigid | CNTR-OS-000890, CNTR-OS-000900
stigref | SV-257571r961683_rule, SV-257572r961683_rule

#### Rule Allowed registries are configured [ref]

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

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/images/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/images/cluster` file.

Rationale: | Allowed registries should be configured to restrict the registries that the OpenShift container runtime can access, and all other registries should be blocked.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_ocp_allowed_registries

References:

nist | CM-5(3), CM-7(2), CM-7(5), CM-11
app-srg-ctr | SRG-APP-000456-CTR-001125
cis | 5.5.1
bsi | SYS.1.6.A6, SYS.1.6.A12
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000890, CNTR-OS-000900
stigref | SV-257571r961683_rule, SV-257572r961683_rule

#### Rule Allowed registries for import are configured [ref]

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

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/images/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/images/cluster` file.

Rationale: | Allowed registries for import should be specified to limit the registries from which users may import images.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_ocp_allowed_registries_for_import

References:

nist | CM-5(3), CM-7(2), CM-7(5), CM-11
app-srg-ctr | SRG-APP-000456-CTR-001125
cis | 5.5.1
bsi | SYS.1.6.A6, SYS.1.6.A12
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000890, CNTR-OS-000900
stigref | SV-257571r961683_rule, SV-257572r961683_rule

#### Rule Check configured allowed registries for import uses secure protocol [ref]

The configuration `allowedRegistriesForImport` limits the container image registries from which normal users may import images. This is a list of the registries that can be trusted to contain valid images and the image location configured is assumed to be secured unless configured otherwise. It is important to allow only secure registries to avoid man in the middle attacks, as the insecure image import request can be impersonated and could lead to fetching malicious content. List all the allowed repositories for import configured with insecure set to true using the following command:

    oc get image.config.openshift.io/cluster -o json | jq '.spec | (.allowedRegistriesForImport[])? | select(.insecure==true)'

Remove or edit the listed registries having insecure set by using the command:

    oc edit image.config.openshift.io/cluster

For more information, follow the relevant documentation.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/images/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/images/cluster` file.

Rationale: | Configured list of allowed registries for import should be from the secure source.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_ocp_insecure_allowed_registries_for_import
Identifiers: | CCE-86235-9

References:

nist | CM-5(3)
app-srg-ctr | SRG-APP-000014-CTR-000035
cis | 5.5.1
bsi | APP.4.4.A12, SYS.1.6.A6
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000010
stigref | SV-257505r960759_rule

#### Rule Check if any insecure registry sources is configured [ref]

The configuration `registrySources.insecureRegistries` determines the insecure registries that the OpenShift container runtime can access for builds and pods. This configuration setting is for accessing the configured registries without TLS validation which could lead to security breaches and should be avoided. Remove any insecureRegistries configured using the following command:

    oc patch image.config.openshift.io cluster --type=json -p "[{'op': 'remove', 'path': '/spec/registrySources/insecureRegistries'}]"

For more information, follow the relevant documentation.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/config.openshift.io/v1/images/cluster` API endpoint to the local `/kubernetes-api-resources/apis/config.openshift.io/v1/images/cluster` file.

Rationale: | Insecure registries should not be configured, which would restrict the possibilities of OpenShift container runtime accessing registries which cannot be validated.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_ocp_insecure_registries
Identifiers: | CCE-86123-7

References:

nist | CM-5(3)
app-srg-ctr | SRG-APP-000014-CTR-000035
cis | 5.5.1
bsi | APP.4.4.A12, SYS.1.6.A6
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000010
stigref | SV-257505r960759_rule

Group OpenShift - Risk Assessment Settings Group contains 3 rules
[ref] Contains evaluations for the cluster's risk assessment configuration settings.

#### Rule Make sure the Container Security Operator is installed [ref]

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

Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/operators.coreos.com/v1alpha1/namespaces/openshift-operators/subscriptions/container-security-operator` API endpoint to the local `/kubernetes-api-resources/apis/operators.coreos.com/v1alpha1/namespaces/openshift-operators/subscriptions/container-security-operator` file.

Rationale: | Vulnerabilities in software packages can be exploited by hackers or malicious users to obtain unauthorized access to resources.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_container_security_operator_exists
Identifiers: | CCE-90613-1

References:

nist | CM-6(b)
app-srg-ctr | SRG-APP-000516-CTR-001335
pcidss4 | 6.4.2, 6.4
stigid | CNTR-OS-001060
stigref | SV-257586r961863_rule

#### Rule Ensure that Compliance Operator is scanning the cluster [ref]

The Compliance Operator scans the hosts and the platform (OCP) configurations for software flaws and improper configurations according to different compliance benchmarks. It uses OpenSCAP as a backend, which is a known and certified tool to do such scans.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the `/apis/compliance.openshift.io/v1alpha1/scansettingbindings?limit=5` API endpoint to the local `/kubernetes-api-resources/apis/compliance.openshift.io/v1alpha1/scansettingbindings?limit=5` file.

Rationale: | Vulnerability scanning and risk management are important detective controls for all systems, to detect potential flaws and unauthorised access.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scansettingbinding_exists
Identifiers: | CCE-83697-3

References:

nerc-cip | CIP-003-8 R1.3, CIP-003-8 R4.3, CIP-003-8 R6, CIP-004-6 4.1, CIP-004-6 4.2, CIP-004-6 R3, CIP-004-6 R4, CIP-004-6 R4.2, CIP-005-6 R1, CIP-005-6 R1.1, CIP-005-6 R1.2, CIP-007-3 R3, CIP-007-3 R3.1, CIP-007-3 R6.1, CIP-007-3 R8.4
nist | CM-6, CM-6(1), RA-5, RA-5(5), SA-4(8)
pcidss | Req-2.2.4
app-srg-ctr | SRG-APP-000472-CTR-001170
bsi | APP.4.4.A13
pcidss4 | 2.2.1, 2.2.6, 2.2
stigid | CNTR-OS-000910
stigref | SV-257573r961731_rule

#### Rule Ensure that Compliance Operator scans are running periodically [ref]

The Compliance Operator scans the hosts and the platform (OCP) configurations for software flaws and improper configurations according to different compliance benchmarks. Compliance Operator allows its scans to be scheduled periodically using the `ScanSetting` Custom Resource.
Warning: This rule's check operates on the cluster configuration dump. Therefore, you need to use a tool that can query the OCP API, retrieve the following:

- `/apis/compliance.openshift.io/v1alpha1/scansettings` API endpoint, filter with with the `jq` utility using the following filter `[.items[]] | map(.schedule != "" and .schedule != null)` and persist it to the local `/kubernetes-api-resources/apis/compliance.openshift.io/v1alpha1/scansettings#c9e8242304a62f077a87b2b045f62b01340e80a8798e58477faa58c06e918211` file.

Rationale: | Without periodical scanning and verification, security functions may not operate correctly and this failure may go unnoticed within the container platform.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scansettings_have_schedule
Identifiers: | CCE-90762-6

References:

nist | SI-6(b)
app-srg-ctr | SRG-APP-000473-CTR-001175
bsi | APP.4.4.A13
stigid | CNTR-OS-000920
stigref | SV-257574r961734_rule

Group Security Context Constraints (SCC) Group contains 7 rules
[ref] Similar to the way that RBAC resources control user access, administrators can use Security Context Constraints (SCCs) to control permissions for pods. These permissions include actions that a pod, a collection of containers, can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with in order to be accepted into the system.

#### Rule Limit Containers Ability to use the HostDir volume plugin [ref]

Containers should be allowed to use the `hostPath` volume type unless necessary. To prevent containers from using the host filesystem the appropriate Security Context Constraints (SCCs) should set `allowHostDirVolumePlugin` to `false`.
Rationale: | `hostPath` volumes allow workloads to access the host filesystem from the workload. Access to the host filesystem can be used to escalate privileges and access resources such as keys or access tokens.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_host_dir_volume_plugin
Identifiers: | CCE-86255-7

References:

nist | AC-6, AC-6(1)
app-srg-ctr | SRG-APP-000142-CTR-000330
cis | 5.2.12
bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A17, SYS.1.6.A18, SYS.1.6.A19, SYS.1.6.A21
stigid | CNTR-OS-000660
stigref | SV-257557r961359_rule

#### Rule Limit Containers Ability to bind to privileged ports [ref]

Containers should be limited to bind to non-privileged ports directly on the hosts. To prevent containers from binding to privileged ports on the host the appropriate Security Context Constraints (SCCs) should set `allowHostPorts` to `false`.

Rationale:

Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_host_ports
Identifiers: | CCE-86205-2

References:

nist | CM-6, CM-6(1)
app-srg-ctr | SRG-APP-000142-CTR-000330
bsi | APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A17
stigid | CNTR-OS-000660
stigref | SV-257557r961359_rule

#### Rule Limit Access to the Host IPC Namespace [ref]

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`.
Rationale: | A container running in the host's IPC namespace can use IPC to interact with processes outside the container potentially allowing an attacker to exploit a host process thereby enabling an attacker to exploit other services.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_ipc_namespace
Identifiers: | CCE-84042-1

References:

nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1
nist | CM-6, CM-6(1)
pcidss | Req-2.2
app-srg-ctr | SRG-APP-000516-CTR-001325
cis | 5.2.3
bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A17, SYS.1.6.A18, SYS.1.6.A21
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000660
stigref | SV-257557r961359_rule

#### Rule Limit Access to the Host Network Namespace [ref]

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`.
Rationale: | A container running in the host's network namespace could access the host network traffic to and from other pods potentially allowing an attacker to exploit pods and network traffic.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_network_namespace
Identifiers: | CCE-83492-9

References:

nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1
nist | CM-6, CM-6(1)
pcidss | Req-2.2
app-srg-ctr | SRG-APP-000142-CTR-000330
cis | 5.2.4
bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A17, SYS.1.6.A18, SYS.1.6.A21
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000660
stigref | SV-257557r961359_rule

#### Rule Limit Privileged Container Use [ref]

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`.
Rationale: | Privileged containers have access to all Linux Kernel capabilities and devices. If a privileged container were compromised, an attacker would have full access to the container and host.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_privileged_containers

References:

nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1
nist | CM-6, CM-6(1)
pcidss | Req-2.2
app-srg-ctr | SRG-APP-000342-CTR-000775, SRG-APP-000142-CTR-000330
cis | 5.2.1
bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A17, SYS.1.6.A18, SYS.1.6.A21
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000660
stigref | SV-257557r961359_rule

#### Rule Limit Access to the Host Process ID Namespace [ref]

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`.
Rationale: | A container running in the host's PID namespace can inspect processes running outside the container which can be used to escalate privileges outside of the container.
Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_process_id_namespace

References:

nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1
nist | CM-6, CM-6(1)
pcidss | Req-2.2
app-srg-ctr | SRG-APP-000516-CTR-001325
cis | 5.2.2
bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A17, SYS.1.6.A18, SYS.1.6.A21
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000660
stigref | SV-257557r961359_rule

#### Rule Limit Container Running As Root User [ref]

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

Rationale:

It is strongly recommended that containers running on OpenShift should support running as any arbitrary UID. OpenShift will then assign a random, non-privileged UID to the running container instance. This avoids the risk from containers running with specific uids that could map to host service accounts, or an even greater risk of running as root level service. OpenShift uses the default security context constraints (SCC), restricted, to prevent containers from running as root or other privileged user ids. Pods may be configured to use an scc policy that allows the container to run as a specific uid, including root(0) when approved. Only a cluster administrator may grant the change of an scc policy.

Severity: | medium
Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_root_containers

References:

nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1
nist | CM-6, CM-6(1)
pcidss | Req-2.2
app-srg-ctr | SRG-APP-000342-CTR-000775
cis | 5.2.6
bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A17, SYS.1.6.A18, SYS.1.6.A21
pcidss4 | 2.2.1, 2.2
stigid | CNTR-OS-000660
stigref | SV-257557r961359_rule

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.