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

with profile BSI IT-Grundschutz (Basic Protection) Building Block SYS.1.6 and APP.4.4
This profile defines a baseline that aligns to the BSI (Federal Office for Security Information) IT-Grundschutz Basic-Protection. This baseline implements configuration requirements from the following sources: - Building-Block SYS.1.6 Containerisation - Building-Block APP.4.4 Kubernetes
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 TitleBSI IT-Grundschutz (Basic Protection) Building Block SYS.1.6 and APP.4.4
Profile IDxccdf_org.ssgproject.content_profile_bsi

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

  • draft (as of 2024-02-23)

Table of Contents

  1. Kubernetes Settings
    1. OpenShift Kube API Server
    2. Kubernetes - General Security Practices
    3. Role-based Access Control
    4. Kubernetes - Registry Security Practices
    5. Security Context Constraints (SCC)

Checklist

Group   Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4   Group contains 6 groups and 14 rules
Group   Kubernetes Settings   Group contains 5 groups and 14 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   OpenShift Kube API Server   Group contains 1 rule
[ref]   This section contains recommendations for kube-apiserver configuration.

Rule   Ensure that anonymous requests to the API Server are authorized   [ref]

By default, anonymous access to the OpenShift API is enabled, but at the same time, all requests must be authorized. If no authentication mechanism is used, the request is assigned the system:anonymous virtual user and the system:unauthenticated virtual group. This allows the authorization layer to determine which requests, if any, is an anonymous user authorized to make. To verify the authorization rules for anonymous requests run the following:
$ oc describe clusterrolebindings
and inspect the bindings of the system:anonymous virtual user and the system:unauthenticated virtual group. To test that an anonymous request is authorized to access the readyz endpoint, run:
$ oc get --as="system:anonymous" --raw='/readyz?verbose'
In contrast, a request to list all projects should not be authorized:
$ oc get --as="system:anonymous" projects
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/rbac.authorization.k8s.io/v1/clusterrolebindings API endpoint to the local /kubernetes-api-resources/apis/rbac.authorization.k8s.io/v1/clusterrolebindings file.
Rationale:
When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the API server. If you are using RBAC authorization, it is generally considered reasonable to allow anonymous access to the API Server for health checks and discovery purposes, and hence this recommendation is not scored. However, you should consider whether anonymous discovery is an acceptable risk for your purposes.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_anonymous_auth
Identifiers and References

References:  APP.4.4.A3, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-2.2, SRG-APP-000516-CTR-001325, 1.2.1

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

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 and References

Identifiers:  CCE-90387-2

References:  APP.4.4.A3, 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, AC-2(2), AC-2(7), AC-2(9), AC-2(10), AC-12(1), IA-2(5), MA-4, SC-12(1), Req-2.1, SRG-APP-000023-CTR-000055, 3.1.1, 5.1.1

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
Identifiers and References

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
Identifiers and References
Group   Role-based Access Control   Group contains 1 rule
[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 and References

Identifiers:  CCE-90678-4

References:  APP.4.4.A3, AC-3, CM-5(6), IA-2, IA-2(5), AC-6(10), CM-11(2), CM-5(1), CM-7(5)(b), 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, 5.2.10

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

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 and References

Identifiers:  CCE-86235-9

References:  APP.4.4.A12, CM-5(3), SRG-APP-000014-CTR-000035, 5.5.1

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 and References

Identifiers:  CCE-86123-7

References:  APP.4.4.A12, CM-5(3), SRG-APP-000014-CTR-000035, 5.5.1

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 and References

Identifiers:  CCE-86255-7

References:  APP.4.4.A4, AC-6, AC-6(1), SRG-APP-000142-CTR-000330, 5.2.12

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 and References

Identifiers:  CCE-84042-1

References:  APP.4.4.A4, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-2.2, SRG-APP-000516-CTR-001325, 5.2.3

Rule   Limit Use of the CAP_NET_RAW   [ref]

Containers should not enable more capabilities than needed as this opens the door for malicious use. CAP_NET_RAW enables a container to launch a network attack on another container or cluster. To disable the CAP_NET_RAW capability, the appropriate Security Context Constraints (SCCs) should set NET_RAW in requiredDropCapabilities.
Rationale:
By default, containers run with a default set of capabilities as assigned by the Container Runtime which can include dangerous or highly privileged capabilities. If the CAP_NET_RAW is enabled, it may be misused by malicious containers or attackers.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_scc_limit_net_raw_capability
Identifiers and References

References:  APP.4.4.A4, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-2.2, SRG-APP-000516-CTR-001325, 5.2.7

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 and References

Identifiers:  CCE-83492-9

References:  APP.4.4.A4, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-2.2, SRG-APP-000142-CTR-000330, 5.2.4

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
Identifiers and References

References:  APP.4.4.A4, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-2.2, SRG-APP-000342-CTR-000775, SRG-APP-000142-CTR-000330, 5.2.1

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
Identifiers and References

References:  APP.4.4.A4, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-2.2, SRG-APP-000516-CTR-001325, 5.2.2

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
Identifiers and References

References:  APP.4.4.A4, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-2.2, SRG-APP-000342-CTR-000775, 5.2.6

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.