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

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	BSI IT-Grundschutz (Basic Protection) Building Block SYS.1.6 and APP.4.4
Profile ID	xccdf_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.74

draft (as of 2024-07-25)

Kubernetes Settings

Checklist

Group Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4 Group contains 10 groups and 35 rules

Group Kubernetes Settings Group contains 9 groups and 35 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 Kubernetes - Account and Access Control Group contains 4 rules

[ref] In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. The same idea applies to cloud technology such as Kubernetes. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Kubernetes.

Rule Ensure no ClusterRoleBindings set for default Service Account [ref]

Using the default service account prevents accurate application rights review and audit tracing. Instead of default, create a new and unique service account and associate the required ClusterRoleBindings.

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/rbac.authorization.k8s.io/v1/clusterrolebindings?limit=10000 API endpoint, filter with with the jq utility using the following filter [.items[] | select ( .subjects[]?.name == "default" ) | select(.subjects[].namespace | startswith("kube-") or startswith("openshift-") | not) | .metadata.name ] | unique and persist it to the local /kubernetes-api-resources/apis/rbac.authorization.k8s.io/v1/clusterrolebindings?limit=10000#79f26213dd0c77369a3262d04a79b049cbe657d6816bca60a341434f2ee8d280 file.

Rationale:

Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. This increases auditability of service account rights and access making it easier and more accurate to trace potential malicious behaviors to a specific service account and project.

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_accounts_no_clusterrolebindings_default_service_account

References:

bsi	APP.4.4.A9

Rule Ensure no RoleBindings set for default Service Account [ref]

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/rbac.authorization.k8s.io/v1/rolebindings?limit=10000 API endpoint, filter with with the jq utility using the following filter [.items[] | select(.metadata.namespace | startswith("kube-") or startswith("openshift-") | not) | select ( .subjects[]?.name == "default" ) | .metadata.namespace + "/" + .metadata.name ] | unique and persist it to the local /kubernetes-api-resources/apis/rbac.authorization.k8s.io/v1/rolebindings?limit=10000#00c457af66396f1f78aa74c5eb2177980c74419afc15a46a16b38a8712ca0b70 file.

Rationale:

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_accounts_no_rolebindings_default_service_account

References:

bsi	APP.4.4.A9

Rule Restrict Automounting of Service Account Tokens [ref]

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

Rationale:

Mounting service account tokens inside pods can provide an avenue for privilege escalation attacks where an attacker is able to compromise a single pod in the cluster.

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_accounts_restrict_service_account_tokens

References:

bsi	APP.4.4.A9
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.1.6

Rule Ensure Usage of Unique Service Accounts [ref]

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

$ oc create sa service_account_name

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

Rationale:

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_accounts_unique_service_account

References:

bsi	APP.4.4.A9
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.1.5

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

References:

bsi	APP.4.4.A3
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	1.2.1

Group OpenShift etcd Settings Group contains 1 rule

[ref] Contains rules that check correct OpenShift etcd settings.

Rule Configure Recurring Backups For etcd [ref]

Back up your clusters etcd data regularly and store in a secure location ideally outside the OpenShift Container Platform environment. Do not take an etcd backup before the first certificate rotation completes, which occurs 24 hours after installation, otherwise the backup will contain expired certificates. It is also recommended to take etcd backups during non-peak usage hours because the etcd snapshot has a high I/O cost.

For more information, follow the relevant documentation.

Rationale:

While etcd automatically recovers from temporary failures, issues may arise if an etcd cluster loses more than (N-1)/2 or when an update goes wrong. Recurring backups of etcd enable you to recover from a disastrous fail.

Severity:

medium

Rule ID:

xccdf_org.ssgproject.content_rule_etcd_backup

Identifiers:

CCE-88188-8

References:

bsi	APP.4.4.A5

Group Kubernetes - General Security Practices Group contains 8 rules

[ref] Contains evaluations for general security practices for operating a Kubernetes environment.

Rule A Backup Solution Has To Be Installed [ref]

Backup and Restore are fundamental practices when it comes to disaster recovery. By utilizing a Backup Software you are able to backup (and restore) data, which is lost, if your cluster crashes beyong recoverability. There are multiple Backup Solutions on the Market which diverge in Features. Thus some of them might only backup your cluster, others might also be able to backup VMs or PVCs running in your Cluster.

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/apiextensions.k8s.io/v1/customresourcedefinitions?limit=500 API endpoint, filter with with the jq utility using the following filter [.items[] | if select(.metadata.name | test("{{.var_backup_solution_crds_regex}}"))!=null then true else false end] and persist it to the local /kubernetes-api-resources/apis/apiextensions.k8s.io/v1/customresourcedefinitions?limit=500#5ecc4195e33073b3ebac60dfafee48c8b29e3e0f551fd8fc26ba9271eb059d88 file.

Rationale:

Backup and Recovery abilities are a necessity to recover from a disaster.

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_general_backup_solution_installed

Identifiers:

CCE-90185-0

References:

bsi	APP.4.4.A5

Rule Each Namespace should only host one application [ref]

Use namespaces to isolate your Kubernetes objects.

Rationale:

Assigning a dedicated namespace to an application (or parts of an application) allows you to granularly control the access to this application on a kubernetes level. It also allows you control the network flow from and to other namespaces more easily.

Severity:

medium

Rule ID:

xccdf_org.ssgproject.content_rule_general_namespace_separation

Identifiers:

CCE-90279-1

References:

bsi	APP.4.4.A1

Rule Create Network Boundaries between Functional Different Nodes [ref]

Use different Networks for Control Plane, Worker and Individual Application Services.

Rationale:

Separation on a Network level might help to hinder lateral movement of an attacker and subsequently reduce the impact of an attack. It might also enable you to provide additional external network control (like firewalls).

Severity:

medium

Rule ID:

xccdf_org.ssgproject.content_rule_general_network_separation

Identifiers:

CCE-86851-3

References:

bsi	APP.4.4.A7

Rule Create Boundaries between Resources using Nodes or Clusters [ref]

Use Nodes or Clusters to isolate Workloads with high protection requirements. Run the following command and review the pods and how they are deployed on Nodes.

$ oc get pod -o=custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace,APP:.metadata.labels.app\.kubernetes\.io/name,NODE:.spec.nodeName --all-namespaces | grep -v "openshift-"

You can use labels or other data as custom field which helps you to identify parts of an application. Ensure that Applications with high protection requirements are not colocated on Nodes or in Clusters with workloads of lower protection requirements.

Rationale:

Assigning workloads with high protection requirements to specific nodes creates and additional boundary (the node) between workloads of high protection requirements and workloads which might follow less strict requirements. An adversary which attacked a lighter protected workload now has additional obstacles for their movement towards the higher protected workloads.

Severity:

medium

Rule ID:

xccdf_org.ssgproject.content_rule_general_node_separation

References:

bsi	APP.4.4.A15

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:

bsi	APP.4.4.A3
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, CNTR-OS-000030, CNTR-OS-000040, CNTR-OS-000440
cis	3.1.1, 5.1.1
stigref	SV-257507r921464_rule, SV-257508r921467_rule, SV-257542r921569_rule

Rule Ensure that all workloads have liveness and readiness probes [ref]

Configuring Kubernetes liveness and readiness probes is essential for ensuring the security and reliability of a system. These probes actively monitor container health and readiness, facilitating automatic actions like restarting or rescheduling unresponsive instances for improved reliability. They play a proactive role in issue detection, allowing timely problem resolution and contribute to efficient scaling and traffic distribution.

Rationale:

Many applications running for long periods of time eventually transition to broken states, and cannot recover except by being restarted. Kubernetes provides liveness probes to detect and remedy such situations. Sometimes, applications are temporarily unable to serve traffic. For example, an application might need to load large data or configuration files during startup, or depend on external services after startup. In such cases, you don't want to kill the application, but you don't want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations. A pod with containers reporting that they are not ready does not receive traffic through Kubernetes Services.

Severity:

medium

Rule ID:

xccdf_org.ssgproject.content_rule_liveness_readiness_probe_in_workload

References:

bsi	APP.4.4.A11

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 Kubernetes - Network Configuration and Firewalls Group contains 3 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:

bsi	APP.4.4.A7
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, CNTR-OS-000100
cis	5.3.1
stigref	SV-257514r921485_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:

Severity:

high

Rule ID: xccdf_org.ssgproject.content_rule_configure_network_policies_namespaces

References:

bsi	APP.4.4.A7
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, CNTR-OS-000100
cis	5.3.2
stigref	SV-257514r921485_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:

bsi	APP.4.4.A7
app-srg-ctr	SRG-APP-000039-CTR-000110, CNTR-OS-000110
stigref	SV-257515r921488_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

Group Role-based Access Control Group contains 2 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:

bsi	APP.4.4.A3, APP.4.4.A7, APP.4.4.A9
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, CNTR-OS-000090
cis	5.2.10
stigref	SV-257513r921482_rule

Rule Minimize Wildcard Usage in Cluster and Local Roles [ref]

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

Rationale:

The principle of least privilege recommends that users are provided only the access required for their role and nothing more. The use of wildcard rights grants is likely to provide excessive rights to the Kubernetes API.

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_rbac_wildcard_use

References:

bsi	APP.4.4.A9
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.1.3

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.

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:

bsi	APP.4.4.A12
nist	CM-5(3)
app-srg-ctr	SRG-APP-000014-CTR-000035, CNTR-OS-000010
cis	5.5.1
stigref	SV-257505r921458_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.

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:

bsi	APP.4.4.A12
nist	CM-5(3)
app-srg-ctr	SRG-APP-000014-CTR-000035, CNTR-OS-000010
cis	5.5.1
stigref	SV-257505r921458_rule

Group OpenShift - Risk Assessment Settings Group contains 3 rules

[ref] Contains evaluations for the cluster's risk assessment configuration settings.

Rule Enable AutoApplyRemediation for at least One ScanSetting [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 automatically apply remediations for failed rules, if such remediations exist. Applying remediations automatically should only be done with careful consideration. The Compliance Operator does not automatically resolve dependency issues that can occur between remediations. Users should perform a rescan after remediations are applied to ensure accurate results.

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/scansettings API endpoint to the local /kubernetes-api-resources/apis/compliance.openshift.io/v1alpha1/scansettings file.

Rationale:

With enabled AutoApplyRemediation compliance failures get automatically corrected.

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_scansetting_has_autoapplyremediations

References:

bsi	APP.4.4.A13

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:

bsi	APP.4.4.A13
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, CNTR-OS-000910
stigref	SV-257573r921662_rule

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

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:

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

Group Security Context Constraints (SCC) Group contains 11 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 Drop Container Capabilities [ref]

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

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. Capabilities should be dropped unless absolutely critical for the container to run software as added capabilities that are not required allow for malicious containers or attackers.

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_scc_drop_container_capabilities

References:

bsi	APP.4.4.A9
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.9

Rule Limit Container Capabilities [ref]

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

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

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

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

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/security.openshift.io/v1/securitycontextconstraints API endpoint, filter with with the jq utility using the following filter [.items[] | select(.metadata.name | test("{{.var_sccs_with_allowed_capabilities_regex}}"; "") | not) | select(.allowedCapabilities != null) | .metadata.name] and persist it to the local /kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints#821f2c3e5c4100d5609ac6070d8a51075295651614a05c65a5f744ba751c15b0 file.

Rationale:

Severity:

medium

Rule ID: xccdf_org.ssgproject.content_rule_scc_limit_container_allowed_capabilities

References:

bsi	APP.4.4.A9
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.8

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:

bsi	APP.4.4.A4, APP.4.4.A9
nist	AC-6, AC-6(1)
app-srg-ctr	SRG-APP-000142-CTR-000330, CNTR-OS-000660
cis	5.2.12
stigref	SV-257557r921614_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:

bsi	APP.4.4.A9
nist	CM-6, CM-6(1)
app-srg-ctr	SRG-APP-000142-CTR-000330, CNTR-OS-000660
stigref	SV-257557r921614_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:

bsi	APP.4.4.A4, APP.4.4.A9
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, CNTR-OS-000660
cis	5.2.3
stigref	SV-257557r921614_rule

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

References:

bsi	APP.4.4.A4, APP.4.4.A9
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.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:

CCE-83492-9

References:

bsi	APP.4.4.A4, APP.4.4.A9
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, CNTR-OS-000660
cis	5.2.4
stigref	SV-257557r921614_rule

Rule Limit Containers Ability to Escalate Privileges [ref]

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

Rationale:

Privileged containers have access to more of the 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_privilege_escalation

Identifiers:

CCE-83447-3

References:

bsi	APP.4.4.A9
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.5

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:

bsi	APP.4.4.A4, APP.4.4.A9
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, CNTR-OS-000660
cis	5.2.1
stigref	SV-257557r921614_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:

bsi	APP.4.4.A4, APP.4.4.A9
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, CNTR-OS-000660
cis	5.2.2
stigref	SV-257557r921614_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:

bsi	APP.4.4.A4, APP.4.4.A9
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, CNTR-OS-000660
cis	5.2.6
stigref	SV-257557r921614_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.