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

with profile DISA STIG for Red Hat OpenShift Container Platform 4 - Node 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 TitleDISA STIG for Red Hat OpenShift Container Platform 4 - Node level
Profile IDxccdf_org.ssgproject.content_profile_stig-node-v2r1

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

  • draft (as of 2024-10-11)

Table of Contents

  1. Kubernetes Settings
    1. System and Software Integrity
    2. Kubernetes - General Security Practices
    3. Kubernetes Kubelet Settings

Checklist

Group   Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4   Group contains 4 groups and 3 rules
Group   Kubernetes Settings   Group contains 3 groups and 3 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 rule
[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.

Rule   Ensure the Container Runtime rejects unsigned images by default   [ref]

The OpenShift Platform allows for verifying the signature of a container image before pulling it. this is done via the policy.json file [1] which needs to be configured via the Machine Config Operator [2].

Ensure that the default policy is "reject" in /etc/containers/policy.json, which should look as follows: 

  {
    "default": [{"type": "reject"}],
    "transports":
    ...
  }
Addition of allowed registries must be an explicit action to ensure that only containers from allowed registries are used.

[1] https://github.com/containers/image/blob/main/docs/containers-policy.json.5.md

[2] https://docs.openshift.com/container-platform/latest/security/container_security/security-container-signature.html

Rationale:
By ensuring that the container runtime verifies the integrity of container images before pulling them one is able to prevent a malicious actor from introducing unauthorized images into the deployment.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_reject_unsigned_images_by_default
Identifiers:

CCE-90254-4

References:
nistCM-5(3), CM-7(2), CM-7(5), CM-11, SA-10(1)
app-srg-ctrSRG-APP-000131-CTR-000285, CNTR-OS-000360
bsiSYS.1.6.A6
stigrefSV-257537r921554_rule
Group   Kubernetes - General Security Practices   Group contains 1 rule
[ref]   Contains evaluations for general security practices for operating a Kubernetes environment.

Rule   Kubernetes Pod Logs Must Be Owned and Group Owned By Root and have permissions 755   [ref]

All logs must be owned by root user and group and have permissions 755. By default, the path for the Kubernetes pod logs is 

/var/log/pods/
.

If any of the files have incorrect permissions or ownerhship, change the permissions and ownership of files located under "/var/log/pods" to protect from unauthorized access. 1. Execute the following to set the output of pods readable only by the owner: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; find /var/log/pods/ -type f \( -perm /022 -o -perm /044 \) | xargs -r chmod 600' 2>/dev/null; done 2. Execute the following to set the group and group-ownership to root for files that store the output of pods: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; find /var/log/pods/ -type f \! -user 0 | xargs -r chown root:root' 2>/dev/null; done

Rationale:
Pod log files may contain sensitive information such as application data, user credentials, or system configurations. Unauthorized access to these log files can expose sensitive data to malicious actors. By setting owner permissions, OpenShift ensures that only authorized users or processes with the necessary privileges can access the pod log files, preserving the confidentiality of the logged information.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_groupowner_permissions_pod_logs
Identifiers:

CCE-88593-9

References:
app-srg-ctrSRG-APP-000118-CTR-000240, CNTR-OS-000250, CNTR-OS-000260, CNTR-OS-000270, CNTR-OS-000280, CNTR-OS-000290, CNTR-OS-000300
stigrefSV-257527r921524_rule, SV-257528r921527_rule, SV-257529r921530_rule, SV-257530r921533_rule, SV-257531r921536_rule, SV-257532r921539_rule
Group   Kubernetes Kubelet Settings   Group contains 1 rule
[ref]   The Kubernetes Kubelet is an agent that runs on each node in the cluster. It makes sure that containers are running in a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not created by Kubernetes.

Rule   Ensure Kubelet is configured with allowed TLS versions   [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 configure minimum TLS version to TLSv1.2 or latest when using Custom profile or to use predefined profiles Intermediate or modern. If a TLS security profile is not configured, the default TLS security profile is Intermediate.

To configure Custom tlsSecurityProfile for the Kubelet with TLSv1.2 as minimum TLS version, create a new or modify existing KubeletConfig object along these lines, one for every MachineConfigPool: 

  apiVersion: machineconfiguration.openshift.io/v1
  kind: KubeletConfig
  metadata:
      name: kubelet-tls-config-$pool
  spec:
      tlsSecurityProfile:
          type: Custom
          custom:
              ciphers:
              - ECDHE-ECDSA-CHACHA20-POLY1305
              - ECDHE-RSA-CHACHA20-POLY1305
              - ECDHE-RSA-AES128-GCM-SHA256
              - ECDHE-ECDSA-AES128-GCM-SHA256
              minTLSVersion: VersionTLS12
      machineConfigPoolSelector:
          matchLabels:
              pools.operator.machineconfiguration.openshift.io/$pool_name: ""
In order to configure this rule to check for an alternate TLS version, both var_kubelet_tls_min_version_regex and var_kubelet_tls_min_version should be updated.

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

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_kubelet_configure_tls_min_version
Identifiers:

CCE-86623-6

References:
nistSC-8, SC-8(1)
app-srg-ctrSRG-APP-000014-CTR-000040, SRG-APP-000560-CTR-001340, CNTR-OS-000020
pcidss44.2.1, 4.2
stigrefSV-257506r921461_rule

---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
spec:
  kubeletConfig:
    tlsMinVersion: "{{.var_kubelet_tls_min_version}}"
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.