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

with profile CIS Red Hat OpenShift Container Platform 4 Benchmark
This profile defines a baseline that aligns to the Center for Internet Security® Red Hat OpenShift Container Platform 4 Benchmark™, V1.1. This profile includes Center for Internet Security® Red Hat OpenShift Container Platform 4 CIS Benchmarks™ content. Note that this part of the profile is meant to run on the Platform that Red Hat OpenShift Container Platform 4 runs on top of. This profile is applicable to OpenShift versions 4.6 and greater.
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 TitleCIS Red Hat OpenShift Container Platform 4 Benchmark
Profile IDxccdf_org.ssgproject.content_profile_cis

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

  • draft (as of 2023-06-15)

Table of Contents

  1. Kubernetes Settings
    1. Kubernetes - Account and Access Control
    2. OpenShift Kube API Server
    3. Authentication
    4. OpenShift Controller Settings
    5. OpenShift etcd Settings
    6. Kubernetes - General Security Practices
    7. Kubernetes Kubelet Settings
    8. OpenShift - Logging Settings
    9. Kubernetes - Network Configuration and Firewalls
    10. OpenShift API Server
    11. Role-based Access Control
    12. Security Context Constraints (SCC)
    13. OpenShift - Kubernetes - Scheduler Settings
    14. Kubernetes Secrets Management
    15. Kubernetes - Worker Node Settings

Checklist

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

Rule   Disable the AlwaysAdmit Admission Control Plugin   [ref]

To ensure OpenShift only responses to requests explicitly allowed by the admission control plugin. Check that the config ConfigMap object does not contain the AlwaysAdmit plugin.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson]{{else}}[.data."config.yaml" | fromjson]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#ffe65d9fac11909686e59349c6a0111aaf57caa26bd2db3e7dcb1a0a22899145 file.
Rationale:
Enabling the admission control plugin AlwaysAdmit allows all requests and does not provide any filtering.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_alwaysadmit
Identifiers and References

Identifiers:  CCE-84148-6

References:  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.11

Rule   Ensure that the Admission Control Plugin AlwaysPullImages is not set   [ref]

The AlwaysPullImages admission control plugin should be disabled, since it can introduce new failure modes for control plane components if an image registry is unreachable.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson]{{else}}[.data."config.yaml" | fromjson]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#ffe65d9fac11909686e59349c6a0111aaf57caa26bd2db3e7dcb1a0a22899145 file.
Rationale:
Setting admission control policy to AlwaysPullImages forces every new pod to pull the required images every time. In a multi-tenant cluster users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission control policy, once an image has been pulled to a node, any pod from any user can use it simply by knowing the image’s name, without any authorization check against the image ownership. When this plug-in is enabled, images are always pulled prior to starting containers, which means valid credentials are required. However, turning on this admission plugin can introduce new kinds of cluster failure modes. OpenShift 4 master and infrastructure components are deployed as pods. Enabling this feature can result in cases where loss of contact to an image registry can cause a redeployed infrastructure pod (oauth-server for example) to fail on an image pull for an image that is currently present on the node. We use PullIfNotPresent so that a loss of image registry access does not prevent the pod from starting. If it becomes PullAlways, then an image registry access outage can cause key infrastructure components to fail. The pull policy can be managed per container, using imagePullPolicy.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_alwayspullimages
Identifiers and References

References:  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.12

Rule   Enable the NamespaceLifecycle Admission Control Plugin   [ref]

OpenShift enables the NamespaceLifecycle plugin by default.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
Setting admission control policy to NamespaceLifecycle ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of new objects.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_namespacelifecycle
Identifiers and References

Identifiers:  CCE-83854-0

References:  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.15

Rule   Enable the NodeRestriction Admission Control Plugin   [ref]

To limit the Node and Pod objects that a kubelet could modify, ensure that the NodeRestriction plugin on kubelets is enabled in the api-server configuration by running the following command:
$ oc -n openshift-kube-apiserver get configmap config -o json | jq -r '.data."config.yaml"' | jq '.apiServerArguments."enable-admission-plugins"'
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
Using the NodeRestriction plugin ensures that the kubelet is restricted to the Node and Pod objects that it could modify as defined. Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_noderestriction
Identifiers and References

Identifiers:  CCE-83753-4

References:  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.17

Rule   Enable the SecurityContextConstraint Admission Control Plugin   [ref]

To ensure pod permissions are managed, make sure that the SecurityContextConstraint admission control plugin is used.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
A Security Context Constraint is a cluster-level resource that controls the actions which a pod can perform and what the pod may access. The SecurityContextConstraint objects define a set of conditions that a pod must run with in order to be accepted into the system. Security Context Constraints are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_scc
Identifiers and References

Identifiers:  CCE-83602-3

References:  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.16

Rule   Ensure that the admission control plugin SecurityContextDeny is set if PodSecurityPolicy is not used   [ref]

Instead of using a customized SecurityContext for pods, a Pod Security Policy (PSP) or a SecurityContextConstraint should be used. These are cluster-level resources that control the actions that a pod can perform and what resource the pod may access. The SecurityContextDeny disallows folks from setting a pod's securityContext fields. Ensure that the list of admission controllers does not include SecurityContextDeny:
$ oc -n openshift-kube-apiserver get configmap config -o json | jq -r '.data."config.yaml"' | jq '.apiServerArguments."enable-admission-plugins"' 
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson]{{else}}[.data."config.yaml" | fromjson]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#ffe65d9fac11909686e59349c6a0111aaf57caa26bd2db3e7dcb1a0a22899145 file.
Rationale:
The SecurityContextDeny admission control plugin disallows setting any security options for your pods. SecurityContextConstraints allow you to enforce RBAC rules on who can set these options on the pods, and what they're allowed to set. Thus, using the SecurityContextDeny will deter you from enforcing granular permissions on your pods.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_securitycontextdeny
Identifiers and References

Identifiers:  CCE-83586-8

References:  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.13

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

Rule   Ensure catch-all FlowSchema object for API Priority and Fairness Exists   [ref]

Using APIPriorityAndFairness feature provides a fine-grained way to control the behaviour of the Kubernetes API server in an overload situation. The well-known FlowSchema catch-all should be available to make sure that every request gets some kind of classification. By default, the catch-all priority level only allows one concurrency share and does not queue requests. To inspect all the FlowSchema objects, run:
oc get flowschema
To inspect the well-known catch-all object, run the following:
oc describe flowschema catch-all
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/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/catch-all API endpoint to the local /kubernetes-api-resources/apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/catch-all file/apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/catch-all API endpoint to the local /kubernetes-api-resources/apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/catch-all file/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/catch-all API endpoint to the local /kubernetes-api-resources/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/catch-all file.
Rationale:
The FlowSchema API objects enforce a limit on the number of events that the API Server will accept in a given time slice In a large multi-tenant cluster, there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. It is recommended to limit the rate of events that the API Server will accept.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_api_priority_flowschema_catch_all
Identifiers and References

Identifiers:  CCE-85891-0

References:  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.10

Rule   Enable the APIPriorityAndFairness feature gate   [ref]

To limit the rate at which the API Server accepts requests, make sure that the API Priority and Fairness feature is enabled. Using APIPriorityAndFairness feature provides a fine-grained way to control the behaviour of the Kubernetes API server in an overload situation. To enable the APIPriorityAndFairness feature gate, make sure that the feature-gates API server argument, typically set in the config configMap in the openshift-kube-apiserver namespace contains APIPriorityAndFairness=true. Note that since Kubernetes 1.20, this feature gate is enabled by default. As a result, this rule is only applicable to OpenShift releases prior to 4.7 which was the first OCP release to ship Kubernetes 1.20.
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/kubeapiservers/cluster API endpoint to the local /kubernetes-api-resources/apis/operator.openshift.io/v1/kubeapiservers/cluster file.
Rationale:
The APIPriorityAndFairness feature gate enables the use of the FlowSchema API objects which enforce a limit on the number of events that the API Server will accept in a given time slice In a large multi-tenant cluster, there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. It is recommended to limit the rate of events that the API Server will accept.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_api_priority_gate_enabled
Identifiers and References

Identifiers:  CCE-83656-9

References:  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.10

Rule   Configure the Kubernetes API Server Maximum Retained Audit Logs   [ref]

To configure how many rotations of audit logs are retained, edit the openshift-kube-apiserver configmap and set the audit-log-maxbackup parameter to 10 or to an organizationally appropriate value:
"apiServerArguments":{
  ...
  "audit-log-maxbackup": [10],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
OpenShift automatically rotates the log files. Retaining old log files ensures OpenShift Operators will have sufficient log data available for carrying out any investigation or correlation. For example, if the audit log size is set to 100 MB and the number of retained log files is set to 10, OpenShift Operators would have approximately 1 GB of log data to use during analysis.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_api_server_audit_log_maxbackup
Identifiers and References

Identifiers:  CCE-83739-3

References:  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.24

Rule   Configure Kubernetes API Server Maximum Audit Log Size   [ref]

To rotate audit logs upon reaching a maximum size, edit the openshift-kube-apiserver configmap and set the audit-log-maxsize parameter to an appropriate size in MB. For example, to set it to 100 MB:
"apiServerArguments":{
  ...
  "audit-log-maxsize": ["100"],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
OpenShift automatically rotates log files. Retaining old log files ensures that OpenShift Operators have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, there would be approximately 1 GB of log data available for use in analysis.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_audit_log_maxsize
Identifiers and References

Identifiers:  CCE-83607-2

References:  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.25

Rule   Configure the Audit Log Path   [ref]

To enable auditing on the Kubernetes API Server, the audit log path must be set. Edit the openshift-kube-apiserver configmap and set the audit-log-path to a suitable path and file where audit logs should be written. For example:
"apiServerArguments":{
  ...
  "audit-log-path":"/var/log/kube-apiserver/audit.log",
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
Auditing of the Kubernetes API Server is not enabled by default. Auditing the API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected the system by users, administrators, or other system components.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_audit_log_path
Identifiers and References

Identifiers:  CCE-84020-7

References:  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.22

Rule   The authorization-mode cannot be AlwaysAllow   [ref]

Do not always authorize all requests.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson]{{else}}[.data."config.yaml" | fromjson]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#ffe65d9fac11909686e59349c6a0111aaf57caa26bd2db3e7dcb1a0a22899145 file.
Rationale:
The API Server, can be configured to allow all requests. This mode should not be used on any production cluster.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_auth_mode_no_aa
Identifiers and References

Identifiers:  CCE-84207-0

References:  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.7

Rule   Ensure authorization-mode Node is configured   [ref]

Restrict kubelet nodes to reading only objects associated with them.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
The Node authorization mode only allows kubelets to read Secret, ConfigMap, PersistentVolume, and PersistentVolumeClaim objects associated with their nodes.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_auth_mode_node
Identifiers and References

Identifiers:  CCE-83889-6

References:  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.8

Rule   Ensure authorization-mode RBAC is configured   [ref]

To ensure OpenShift restricts different identities to a defined set of operations they are allowed to perform, check that the API server's authorization-mode configuration option list contains RBAC.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. Enabling RBAC is critical in regulating access to an OpenShift cluster as the RBAC rules specify, given a user, which operations can be executed over a set of namespaced or cluster-wide resources.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_auth_mode_rbac
Identifiers and References

Identifiers:  CCE-84102-3

References:  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.9

Rule   Disable basic-auth-file for the API Server   [ref]

Basic Authentication should not be used for any reason. If needed, edit API Edit the openshift-kube-apiserver configmap and remove the basic-auth-file parameter:
"apiServerArguments":{
  ...
  "basic-auth-file":[
    "/path/to/any/file"
  ],
  ...
Alternate authentication mechanisms such as tokens and certificates will need to be used. Username and password for basic authentication will be disabled.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
Basic authentication uses plaintext credentials for authentication. Currently the basic authentication credentials last indefinitely, and the password cannot be changed without restarting the API Server. The Basic Authentication is currently supported for convenience and is not intended for production workloads.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_basic_auth
Identifiers and References

Identifiers:  CCE-83936-5

References:  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.2

Rule   Ensure that the bindAddress is set to a relevant secure port   [ref]

The bindAddress is set by default to 0.0.0.0:6443, and listening with TLS enabled.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
The OpenShift API server is served over HTTPS with authentication and authorization; the secure API endpoint is bound to 0.0.0.0:6443 by default. In OpenShift, the only supported way to access the API server pod is through the load balancer and then through the internal service. The value is set by the bindAddress argument under the servingInfo parameter.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_api_server_bind_address
Identifiers and References

Identifiers:  CCE-83646-0

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

Rule   Configure the Client Certificate Authority for the API Server   [ref]

Certificates must be provided to fully setup TLS client certificate authentication. To ensure the API Server utilizes its own TLS certificates, the clientCA must be configured. Verify that servingInfo has the clientCA configured in the openshift-kube-apiserver config configmap to something similar to:
"apiServerArguments": {
  ...
    "client-ca-file": [
      "/etc/kubernetes/static-pod-certs/configmaps/client-ca/ca-bundle.crt"
    ],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["client-ca-file"]) | .apiServerArguments["client-ca-file"][] | select(test("/etc/kubernetes/certs/client-ca/ca.crt"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["client-ca-file"]) | .apiServerArguments["client-ca-file"][] | select(test("{{.var_apiserver_client_ca}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#d56e72c377d8f85e0601a704d4218064a0ea4a2235ceee82d20db6cdafc74608 file.
Rationale:
API Server communication contains sensitive parameters that should remain encrypted in transit. Configure the API Server to serve only HTTPS traffic. If -clientCA is set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_client_ca
Identifiers and References

Identifiers:  CCE-84284-9

References:  CIP-003-8 R4.2, CIP-007-3 R5.1, SC-8, SC-8(1), SC-8(2), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000441-CTR-001090, SRG-APP-000442-CTR-001095, 1.2.31

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 aescbc 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/clusters/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 is the only type supported by OCP.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_encryption_provider_cipher
Identifiers and References

Identifiers:  CCE-83585-0

References:  CIP-003-8 R4.2, SC-28, SC-28(1), Req-2.2, SRG-APP-000429-CTR-001060, 1.2.33, 1.2.34


---
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  encryption:
    type: aescbc

Rule   Configure the etcd Certificate Authority for the API Server   [ref]

To ensure etcd is configured to make use of TLS encryption for client connections, follow the OpenShift documentation and setup the TLS connection between the API Server and etcd. Then, verify that apiServerArguments has the etcd-cafile configured in the openshift-kube-apiserver config configmap to something similar to:
"apiServerArguments": {
  ...
    "etcd-cafile": [
        "/etc/kubernetes/static-pod-resources/configmaps/etcd-serving-ca/ca-bundle.crt"
    ],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["etcd-cafile"]) | .apiServerArguments["etcd-cafile"][] | select(test("/etc/kubernetes/certs/etcd-ca/ca.crt"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["etcd-cafile"]) | .apiServerArguments["etcd-cafile"][] | select(test("{{.var_apiserver_etcd_ca}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#33769e7a3c14dd6dc237eb2b13a72140eeadf2ce49578f57bc9e0fd096cf4e9a 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 protected by client authentication. This requires the API Server to identify itself to the etcd server using a SSL Certificate Authority file.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_etcd_ca
Identifiers and References

Identifiers:  CCE-84216-1

References:  CIP-003-8 R4.2, CIP-007-3 R5.1, SC-8, SC-8(1), SC-8(2), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000441-CTR-001090, SRG-APP-000442-CTR-001095, 1.2.32

Rule   Configure the etcd Certificate for the API Server   [ref]

To ensure etcd is configured to make use of TLS encryption for client communications, follow the OpenShift documentation and setup the TLS connection between the API Server and etcd. Then, verify that apiServerArguments has the etcd-certfile configured in the openshift-kube-apiserver configmap to something similar to:
...
"etcd-certfile": [
    "/etc/kubernetes/static-pod-resources/secrets/etcd-client/tls.crt"
],
...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 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 protected by client authentication. This requires the API Server to identify itself to the etcd server using a client certificate and key.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_etcd_cert
Identifiers and References

Identifiers:  CCE-83876-3

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 1.2.29

Rule   Configure the etcd Certificate Key for the API Server   [ref]

To ensure etcd is configured to make use of TLS encryption for client communications, follow the OpenShift documentation and setup the TLS connection between the API Server and etcd. Then, verify that apiServerArguments has the etcd-keyfile configured in the openshift-kube-apiserver configmap to something similar to:
...
"etcd-keyfile": [
    "/etc/kubernetes/static-pod-resources/secrets/etcd-client/tls.key"
],
...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 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 protected by client authentication. This requires the API Server to identify itself to the etcd server using a client certificate and key.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_etcd_key
Identifiers and References

Identifiers:  CCE-83546-2

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 1.2.29

Rule   Ensure that the --kubelet-https argument is set to true   [ref]

The kube-apiserver ensures https to the kubelet by default. The apiserver flag "--kubelet-https" is deprecated and should be either set to "true" or omitted from the argument list.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
Connections from the kube-apiserver to kubelets could potentially carry sensitive data such as secrets and keys. It is thus important to use in-transit encryption for any communication between the apiserver and kubelets.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_https_for_kubelet_conn
Identifiers and References

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.3, SRG-APP-000516-CTR-001325, 1.2.4

Rule   Disable Use of the Insecure Bind Address   [ref]

OpenShift should not bind to non-loopback insecure addresses. Edit the openshift-kube-apiserver configmap and remove the insecure-bind-address if it exists:
"apiServerArguments":{
  ...
  "insecure-bind-address":[
    "127.0.0.1"
  ],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson | .apiServerArguments{{else}}.data."config.yaml" | fromjson | .apiServerArguments{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#95b5b27bb6ea2b122e810c99c17c2430c4845596942804847dd677557cfed88e file.
Rationale:
If the API Server is bound to an insecure address the installation would be susceptible to unauthenticated and unencrypted access to the master node(s). The API Server does not perform authentication checking for insecure binds and the traffic is generally not encrypted.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_insecure_bind_address
Identifiers and References

Identifiers:  CCE-83955-5

References:  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.18

Rule   Prevent Insecure Port Access   [ref]

By default, traffic for the OpenShift API server is served over HTTPS with authentication and authorization, and the secure API endpoint is bound to 0.0.0.0:8443. To ensure that the insecure port configuration has not been enabled, the insecure-port parameter should be set to 0. Edit the openshift-kube-apiserver configmap and change the insecure-port value to 0:
"apiServerArguments":{
  ...
  "insecure-port":[
    "1234"
  ],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
Configuring the API Server on an insecure port would allow unauthenticated and unencrypted access to your master node(s). It is assumed firewall rules will be configured to ensure this port is not reachable from outside the cluster, however as a defense in depth measure, OpenShift should not be configured to use insecure ports.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_insecure_port
Identifiers and References

Identifiers:  CCE-83813-6

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

Rule   Configure the kubelet Certificate Authority for the API Server   [ref]

To ensure OpenShift verifies kubelet certificates before establishing connections, follow the OpenShift documentation and setup the TLS connection between the API Server and kubelets. Edit the openshift-kube-apiserver configmap and set the below parameter if it is not already configured:
"apiServerArguments":{
  ...
  "kubelet-certificate-authority":"/etc/kubernetes/static-pod-resources/configmaps/kubelet-serving-ca/ca-bundle.crt",
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["kubelet-certificate-authority"]) | .apiServerArguments["kubelet-certificate-authority"][] | select(test("/etc/kubernetes/certs/kubelet-ca/ca.crt"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["kubelet-certificate-authority"]) | .apiServerArguments["kubelet-certificate-authority"][] | select(test("{{.var_apiserver_kubelet_certificate_authority}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#1118b118fc93b557cda9eb3f29584d2f92f5c3976f77dec35848eb54e0d819cc file.
Rationale:
Connections from the API Server to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet port-forwarding functionality. These connections terminate at the kubelet HTTPS endpoint. By default, the API Server does not verify the kubelet serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_kubelet_certificate_authority
Identifiers and References

Identifiers:  CCE-84196-5

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 1.2.6

Rule   Configure the kubelet Certificate File for the API Server   [ref]

To enable certificate based kubelet authentication, edit the config configmap in the openshift-kube-apiserver namespace and set the below parameter in the config.yaml key if it is not already configured:
"apiServerArguments":{
...
  "kubelet-client-certificate":"/etc/kubernetes/static-pod-resources/secrets/kubelet-client/tls.crt",
...
}
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["kubelet-client-certificate"]) | .apiServerArguments["kubelet-client-certificate"][] | select(test("/etc/kubernetes/certs/kubelet/tls.crt"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["kubelet-client-certificate"]) | .apiServerArguments["kubelet-client-certificate"][] | select(test("{{.var_apiserver_kubelet_client_cert}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#e5500055b4aa2fcf00dc09ad0e66e44b6b42d67f8d53d1e72ff81b32f0e09865 file.
Rationale:
By default the API Server does not authenticate itself to the kubelet's HTTPS endpoints. Requests from the API Server are treated anonymously. Configuring certificate-based kubelet authentication ensures that the API Server authenticates itself to kubelets when submitting requests.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_kubelet_client_cert
Identifiers and References

Identifiers:  CCE-84080-1

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, SRG-APP-000516-CTR-001325, 1.2.5

Rule   Configure the kubelet Certificate File for the API Server   [ref]

To enable certificate based kubelet authentication, edit the config configmap in the openshift-kube-apiserver namespace and set the below parameter in the config.yaml key if it is not already configured:
"apiServerArguments":{
...
  "kubelet-client-certificate":"/etc/kubernetes/static-pod-resources/secrets/kubelet-client/tls.crt",
...
}
Note that this particular rule is only valid for OCP releases up to and
including 4.8
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-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file.
Rationale:
By default the API Server does not authenticate itself to the kubelet's HTTPS endpoints. Requests from the API Server are treated anonymously. Configuring certificate-based kubelet authentication ensures that the API Server authenticates itself to kubelets when submitting requests.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_kubelet_client_cert_pre_4_9
Identifiers and References

Identifiers:  CCE-85890-2

References:  CM-6, CM-6(1), SC-8, SC-8(1), 1.2.5

Rule   Configure the kubelet Certificate Key for the API Server   [ref]

To enable certificate based kubelet authentication, edit the config configmap in the openshift-kube-apiserver namespace and set the below parameter in the config.yaml key if it is not already configured:
"apiServerArguments":{
...
  "kubelet-client-key":"/etc/kubernetes/static-pod-resources/secrets/kubelet-client/tls.key",
...
}
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["kubelet-client-key"]) | .apiServerArguments["kubelet-client-key"][] | select(test("/etc/kubernetes/certs/kubelet/tls.key"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["kubelet-client-key"]) | .apiServerArguments["kubelet-client-key"][] | select(test("{{.var_apiserver_kubelet_client_key}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#1e2b7c1158e0b9a602cb20d62c82b4660907bb57b63dac11c6c7c64211c49c69 file.
Rationale:
By default the API Server does not authenticate itself to the kubelet's HTTPS endpoints. Requests from the API Server are treated anonymously. Configuring certificate-based kubelet authentication ensures that the API Server authenticates itself to kubelets when submitting requests.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_kubelet_client_key
Identifiers and References

Identifiers:  CCE-83591-8

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, SRG-APP-000516-CTR-001325, 1.2.5

Rule   Configure the kubelet Certificate Key for the API Server   [ref]

To enable certificate based kubelet authentication, edit the config configmap in the openshift-kube-apiserver namespace and set the below parameter in the config.yaml key if it is not already configured:
"apiServerArguments":{
...
  "kubelet-client-key":"/etc/kubernetes/static-pod-resources/secrets/kubelet-client/tls.key",
...
}
Note that this particular rule is only valid for OCP releases up to and
including 4.8
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-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file.
Rationale:
By default the API Server does not authenticate itself to the kubelet's HTTPS endpoints. Requests from the API Server are treated anonymously. Configuring certificate-based kubelet authentication ensures that the API Server authenticates itself to kubelets when submitting requests.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_kubelet_client_key_pre_4_9
Identifiers and References

Identifiers:  CCE-90794-9

References:  CM-6, CM-6(1), SC-8, SC-8(1), 1.2.5

Rule   Ensure all admission control plugins are enabled   [ref]

To make sure none of them is explicitly disabled except PodSecurity, run the following command:
$ oc -n openshift-kube-apiserver get configmap config -o json | jq -r '[.data."config.yaml" | fromjson | .apiServerArguments | select(has("disable-admission-plugins")) | if ."disable-admission-plugins" != ["PodSecurity"] then ."disable-admission-plugins" else empty end]'
and make sure the output is empty.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | .apiServerArguments | select(has("disable-admission-plugins")) | if ."disable-admission-plugins" != ["PodSecurity"] then ."disable-admission-plugins" else empty end]{{else}}[.data."config.yaml" | fromjson | .apiServerArguments | select(has("disable-admission-plugins")) | if ."disable-admission-plugins" != ["PodSecurity"] then ."disable-admission-plugins" else empty end]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#8c02c853df9307960712da853d79f916a091fe8bce6312720d7c17de03c2017b file.
Rationale:
Several hardening controls depend on certain API server admission plugins being enabled. Checking that no admission control plugins are disabled helps assert that all the critical admission control plugins are indeed enabled and providing the security benefits required.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_no_adm_ctrl_plugins_disabled
Identifiers and References

Identifiers:  CCE-83799-7

References:  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.13, 1.2.14, 1.2.14, 1.2.15, 1.2.16, 1.2.17

Rule   Ensure the openshift-oauth-apiserver service uses TLS   [ref]

By default, the OpenShift OAuth API Server uses TLS. HTTPS should be used for connections between openshift-oauth-apiserver and kube-apiserver. By default, the OpenShift OAuth API Server uses Intermediate profile which requires a minimum TLS version of 1.2.
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:
Connections between the kube-apiserver and the extension openshift-oauth-apiserver could potentially carry sensitive data such as secrets and keys. It is important to use in-transit encryption for any communication between the kube-apiserver and the extension openshift-apiserver.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_oauth_https_serving_cert
Identifiers and References

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 1.2.4

Rule   Ensure the openshift-oauth-apiserver service uses TLS   [ref]

By default, the OpenShift API Server uses TLS. HTTPS should be used for connections between openshift-apiserver and kube-apiserver. By default, the OpenShift OAuth API Server uses Intermediate profile which requires a minimum TLS version of 1.2.
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:
Connections between the kube-apiserver and the extension openshift-apiserver could potentially carry sensitive data such as secrets and keys. It is important to use in-transit encryption for any communication between the kube-apiserver and the extension openshift-apiserver.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_openshift_https_serving_cert
Identifiers and References

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 1.2.4

Rule   Profiling is protected by RBAC   [ref]

Ensure that the cluster-debugger cluster role includes the /metrics resource URL. This demonstrates that profiling is protected by RBAC, with a specific cluster role to allow access.
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/clusterroles/cluster-debugger API endpoint to the local /kubernetes-api-resources/apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-debugger file.
Rationale:
Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. To ensure the collected data is not exploited, profiling endpoints are secured via RBAC (see cluster-debugger role). By default, the profiling endpoints are accessible only by users bound to cluster-admin or cluster-debugger role. Profiling can not be disabled.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_profiling_protected_by_rbac
Identifiers and References

Identifiers:  CCE-84212-0

References:  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.21

Rule   Configure the API Server Minimum Request Timeout   [ref]

The API server minimum request timeout defines the minimum number of seconds a handler must keep a request open before timing it out. To set this, edit the openshift-kube-apiserver configmap and set min-request-timeout under the apiServerArguments field:
"apiServerArguments":{
  ...
  "min-request-timeout":[
    3600
  ],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
Setting global request timeout allows extending the API Server request timeout limit to a duration appropriate to the user's connection speed. By default, it is set to 1800 seconds which might not be suitable for some environments. Setting the limit too low may result in excessive timeouts, and a limit that is too large may exhaust the API Server resources making it prone to Denial-of-Service attack. It is recommended to set this limit as appropriate and change the default limit of 1800 seconds only if needed.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_request_timeout
Identifiers and References

References:  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.26

Rule   Configure the Certificate for the API Server   [ref]

To ensure the API Server utilizes its own TLS certificates, the tls-cert-file must be configured. Verify that the apiServerArguments section has the tls-cert-file configured in the config configmap in the openshift-kube-apiserver namespace similar to:
"apiServerArguments":{
...
"tls-cert-file": [
  "/etc/kubernetes/static-pod-certs/secrets/service-network-serving-certkey/tls.crt"
],
...
}
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["tls-cert-file"]) | .apiServerArguments["tls-cert-file"][] | select(test("/etc/kubernetes/certs/server/tls.crt"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["tls-cert-file"]) | .apiServerArguments["tls-cert-file"][] | select(test("{{.var_apiserver_tls_cert}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#bca394347bab5b9902f1d1568d4f5d6e5498b01ec27ddf8231443e376b18757d file.
Rationale:
API Server communication contains sensitive parameters that should remain encrypted in transit. Configure the API Server to serve only HTTPS traffic.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_tls_cert
Identifiers and References

Identifiers:  CCE-83779-9

References:  CIP-003-8 R4.2, CIP-007-3 R5.1, SC-8, SC-8(1), SC-8(2), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000441-CTR-001090, SRG-APP-000442-CTR-001095, 1.2.30

Rule   Use Strong Cryptographic Ciphers on the API Server   [ref]

To ensure that the API Server is configured to only use strong cryptographic ciphers, verify the openshift-kube-apiserver configmap contains the following set of ciphers, with no additions:
"servingInfo":{
  ...
  "cipherSuites": [
    "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
    "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
    "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
    "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
  ],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Warning:  Once configured, API Server clients that cannot support modern cryptographic ciphers will not be able to make connections to the API server.
Rationale:
TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided. By default, OpenShift supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_tls_cipher_suites
Identifiers and References

References:  CM-6, Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 1.2.35

Rule   Configure the Certificate Key for the API Server   [ref]

To ensure the API Server utilizes its own TLS certificates, the tls-private-key-file must be configured. Verify that the apiServerArguments section has the tls-private-key-file configured in the config configmap in the openshift-kube-apiserver namespace similar to:
"apiServerArguments":{
...
"tls-private-key-file": [
  "/etc/kubernetes/static-pod-certs/secrets/service-network-serving-certkey/tls.key"
],
...
}
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["tls-private-key-file"]) | .apiServerArguments["tls-private-key-file"][] | select(test("/etc/kubernetes/certs/server/tls.key"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["tls-private-key-file"]) | .apiServerArguments["tls-private-key-file"][] | select(test("{{.var_apiserver_tls_private_key}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#8c69c1fe6742f70a3a16c09461f57a19ef2a695143301cede2f2f5d307aa3508 file.
Rationale:
API Server communication contains sensitive parameters that should remain encrypted in transit. Configure the API Server to serve only HTTPS traffic.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_tls_private_key
Identifiers and References

Identifiers:  CCE-84282-3

References:  CIP-003-8 R4.2, CIP-007-3 R5.1, SC-8, SC-8(1), SC-8(2), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000441-CTR-001090, SRG-APP-000442-CTR-001095, 1.2.30

Rule   Disable Token-based Authentication   [ref]

To ensure OpenShift does not accept token-based authentication, follow the OpenShift documentation and configure alternate mechanisms for authentication. Then, edit the API Server pod specification file Edit the openshift-kube-apiserver configmap and remove the token-auth-file parameter:
"apiServerArguments":{
  ...
  "token-auth-file":[
    "/path/to/any/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:
  • {{if ne .hypershift_cluster "None"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson]{{else}}[.data."config.yaml" | fromjson]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#ffe65d9fac11909686e59349c6a0111aaf57caa26bd2db3e7dcb1a0a22899145 file.
Rationale:
The token-based authentication utilizes static tokens to authenticate requests to the API Server. The tokens are stored in clear-text in a file on the API Server, and cannot be revoked or rotated without restarting the API Server.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_token_auth
Identifiers and References

Identifiers:  CCE-83481-2

References:  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.3

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/4.6/logging/cluster-logging-external.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/clusterlogforwarders/instance API endpoint to the local /kubernetes-api-resources/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance file.
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 and References

Identifiers:  CCE-84076-9

References:  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, 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), Req-2.2, Req-10.5.3, Req-10.5.4, SRG-APP-000092-CTR-000165, SRG-APP-000111-CTR-000220, SRG-APP-000358-CTR-000805, 1.2.23

Rule   Ensure that Audit Log Webhook Is Configured   [ref]

Audit is on by default and the best practice is to ship audit logs off an cluster for retention. HyperShift is able to do this with the a audit webhook, which is configured in the HostedCluster custom resource. The forementioned resource can be configured to log to different third party systems. For more information on this, please reference the official documentation: https://hypershift-docs.netlify.app/reference/api/
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/clusters/hostedclusters/{{.hypershift_cluster}} API endpoint, filter with with the jq utility using the following filter .spec and persist it to the local /kubernetes-api-resources/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance#916d614f6293c0b742a5e71ac156259606d6735ca783595a3548858d747aa053 file.
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_webhook
Identifiers and References

Identifiers:  CCE-86103-9

References:  Req-2.2, Req-10.5.3, Req-10.5.4, 1.2.23

Group   Authentication   Group contains 1 rule
[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/clusters/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 and References

Identifiers:  CCE-84088-4

References:  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, 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), Req-2.2, Req-8.1.1, SRG-APP-000023-CTR-000055, 3.1.1

Group   OpenShift Controller Settings   Group contains 6 rules
[ref]   This section contains recommendations for the kube-controller-manager configuration

Rule   Ensure Controller insecure port argument is unset   [ref]

To ensure the Controller Manager service is bound to secure loopback address and a secure port, set the RotateKubeletServerCertificate option to true in the openshift-kube-controller-manager configmap on the master node(s):
"extendedArguments": {
...
  "port": ["0"],
...
It is also acceptable for a system to deprecate the insecure port:
"extendedArguments": {
...
...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Dkube-controller-manager{{else}}/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[[.items[0].spec.containers[0].args[] | select(. | match("--port=[1-9]*[1-9]+") )] | length | if . == 0 then true else false end]{{else}}[.data."config.yaml" | fromjson | if .extendedArguments["port"]!=null then .extendedArguments["port"]==["0"] else true end]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config#9f09cca56dc1e9f9605eb5a94aed74de554fd209513a9222e4fe9c0ed669aeee file.
Rationale:
The Controller Manager API service is used for health and metrics information and is available without authentication or encryption. As such, it should only be bound to a localhost interface to minimize the cluster's attack surface.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_controller_insecure_port_disabled
Identifiers and References

Identifiers:  CCE-83578-5

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, SRG-APP-000516-CTR-001325, 1.3.7

Rule   Ensure that the RotateKubeletServerCertificate argument is set   [ref]

To enforce kubelet server certificate rotation on the Controller Manager, set the RotateKubeletServerCertificate option to true in the openshift-kube-controller-manager configmap on the master node(s):
"extendedArguments": {
...
  "feature-gates": [
  ...
    "RotateKubeletServerCertificate=true",
  ...
...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Dkube-controller-manager{{else}}/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.items[0].spec.containers[0].args{{else}}.data."config.yaml" | fromjson | .extendedArguments["feature-gates"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config#4cbbbf49b93400715e43dc698f6484799805c502ad3aeb8285de579753b54d31 file.
Warning:  This recommendation only applies if you let kubelets get their certificates from the API Server. In case your certificates come from an outside Certificate Authority/tool (e.g. Vault) then you need to take care of rotation yourself
Rationale:
Enabling kubelet certificate rotation causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that there are no downtimes due to expired certificates and thus addressing the availability in the C/I/A security triad.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_controller_rotate_kubelet_server_certs
Identifiers and References

Identifiers:  CCE-83730-2

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, SRG-APP-000516-CTR-001325, 1.3.6

Rule   Ensure Controller secure-port argument is set   [ref]

To ensure the Controller Manager service is bound to secure loopback address using a secure port, set the RotateKubeletServerCertificate option to true in the openshift-kube-controller-manager configmap on the master node(s):
"extendedArguments": {
...
  "secure-port": ["10257"],
...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Dkube-controller-manager{{else}}/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[[.items[0].spec.containers[0].args[] | select(. | match("--secure-port=10257") )] | length | if . ==1 then true else false end]{{else}}[.data."config.yaml" | fromjson | if .extendedArguments["secure-port"][]=="10257" then true else false end]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config#8241ce1009dc5dd166436d0311b60b96aa3a2f591ba43a26e2b9d0bfc9071414 file.
Rationale:
The Controller Manager API service is used for health and metrics information and is available without authentication or encryption. As such, it should only be bound to a localhost interface to minimize the cluster's attack surface.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_controller_secure_port
Identifiers and References

Identifiers:  CCE-83861-5

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, SRG-APP-000516-CTR-001325, 1.3.7

Group   OpenShift etcd Settings   Group contains 8 rules
[ref]   Contains rules that check correct OpenShift etcd settings.

Rule   Disable etcd Self-Signed Certificates   [ref]

To ensure the etcd service is not using self-signed certificates, run the following command:
$ oc get cm/etcd-pod -n openshift-etcd -o yaml
The etcd pod configuration contained in the configmap should not contain the --auto-tls=true flag.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Detcd{{else}}/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].command | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod#72b7530e9fb0f39686f598b00d791485841e98be902ba16431a5629726dd7027 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Using self-signed certificates ensures that the certificates are never validated against a certificate authority and could lead to compromised and invalidated data.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_auto_tls
Identifiers and References

Identifiers:  CCE-84199-9

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, SRG-APP-000516-CTR-001325, 2.3

Rule   Ensure That The etcd Client Certificate Is Correctly Set   [ref]

To ensure the etcd service is serving TLS to clients, make sure the etcd-pod* ConfigMaps in the openshift-etcd namespace contain the following argument for the etcd binary in the etcd pod:
--cert-file=/etc/kubernetes/static-pod-certs/secrets/etcd-all-[a-z]+/etcd-serving-NODE_NAME.crt
. Note that the
[a-z]+
is being used since the directory might change between OpenShift versions.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Detcd{{else}}/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].command | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod#72b7530e9fb0f39686f598b00d791485841e98be902ba16431a5629726dd7027 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_cert_file
Identifiers and References

Identifiers:  CCE-83553-8

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 2.1

Rule   Enable The Client Certificate Authentication   [ref]

To ensure the etcd service is serving TLS to clients, make sure the etcd-pod* ConfigMaps in the openshift-etcd namespace contain the following argument for the etcd binary in the etcd pod:
oc get -nopenshift-etcd cm etcd-pod -oyaml | grep "\-\-client-cert-auth="
the parameter should be set to true.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Detcd{{else}}/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].command | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod#72b7530e9fb0f39686f598b00d791485841e98be902ba16431a5629726dd7027 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_client_cert_auth
Identifiers and References

Identifiers:  CCE-84077-7

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 2.2

Rule   Ensure That The etcd Key File Is Correctly Set   [ref]

To ensure the etcd service is serving TLS to clients, make sure the etcd-pod* ConfigMaps in the openshift-etcd namespace contain the following argument for the etcd binary in the etcd pod:
oc get -nopenshift-etcd cm etcd-pod -oyaml | grep "\-\-key-file=/etc/kubernetes/static-pod-certs/secrets/etcd-all-[a-z]+/etcd-serving-NODE_NAME.key"
. Note that the
[a-z]+
is being used since the directory might change between OpenShift versions.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Detcd{{else}}/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].command | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod#72b7530e9fb0f39686f598b00d791485841e98be902ba16431a5629726dd7027 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_key_file
Identifiers and References

Identifiers:  CCE-83745-0

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 2.1

Rule   Disable etcd Peer Self-Signed Certificates   [ref]

To ensure the etcd service is not using self-signed certificates, run the following command:
$ oc get cm/etcd-pod -n openshift-etcd -o yaml
The etcd pod configuration contained in the configmap should not contain the --peer-auto-tls=true flag.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Detcd{{else}}/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].command | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod#72b7530e9fb0f39686f598b00d791485841e98be902ba16431a5629726dd7027 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Using self-signed certificates ensures that the certificates are never validated against a certificate authority and could lead to compromised and invalidated data.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_peer_auto_tls
Identifiers and References

Identifiers:  CCE-84184-1

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, SRG-APP-000516-CTR-001325, 2.6

Rule   Ensure That The etcd Peer Client Certificate Is Correctly Set   [ref]

To ensure the etcd service is serving TLS to peers, make sure the etcd-pod* ConfigMaps in the openshift-etcd namespace contain the following argument for the etcd binary in the etcd pod:
--peer-cert-file=/etc/kubernetes/static-pod-certs/secrets/etcd-all-[a-z]+/etcd-peer-NODE_NAME.crt
Note that the
[a-z]+
is being used since the directory might change between OpenShift versions.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Detcd{{else}}/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].command | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod#72b7530e9fb0f39686f598b00d791485841e98be902ba16431a5629726dd7027 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_peer_cert_file
Identifiers and References

Identifiers:  CCE-83847-4

References:  CIP-003-8 R4.2, CIP-007-3 R5.1, SC-8, SC-8(1), SC-8(2), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000441-CTR-001090, SRG-APP-000442-CTR-001095, 2.4

Rule   Enable The Peer Client Certificate Authentication   [ref]

To ensure the etcd service is serving TLS to clients, make sure the etcd-pod* ConfigMaps in the openshift-etcd namespace contain the following argument for the etcd binary in the etcd pod:
oc get -nopenshift-etcd cm etcd-pod -oyaml | grep "\-\-peer-client-cert-auth="
the parameter should be set to true.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Detcd{{else}}/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].command | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod#72b7530e9fb0f39686f598b00d791485841e98be902ba16431a5629726dd7027 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_peer_client_cert_auth
Identifiers and References

Identifiers:  CCE-83465-5

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000516-CTR-001325, 2.5

Rule   Ensure That The etcd Peer Key File Is Correctly Set   [ref]

To ensure the etcd service is serving TLS to peers, make sure the etcd-pod* ConfigMaps in the openshift-etcd namespace contain the following argument for the etcd binary in the etcd pod:
oc get -nopenshift-etcd cm etcd-pod -oyaml | grep "\-\-peer-key-file=/etc/kubernetes/static-pod-certs/secrets/etcd-all-[a-z]+/etcd-peer-NODE_NAME.key"
Note that the
[a-z]+
is being used since the directory might change between OpenShift versions.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Detcd{{else}}/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].command | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod#72b7530e9fb0f39686f598b00d791485841e98be902ba16431a5629726dd7027 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_peer_key_file
Identifiers and References

Identifiers:  CCE-83711-2

References:  CIP-003-8 R4.2, CIP-007-3 R5.1, SC-8, SC-8(1), SC-8(2), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000441-CTR-001090, SRG-APP-000442-CTR-001095, 2.4

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

Rule   Apply Security Context to Your Pods and Containers   [ref]

Apply Security Context to your Pods and Containers
Rationale:
A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. When designing your containers and pods, make sure that you configure the security context for your pods, containers, and volumes. A security context is a property defined in the deployment yaml. It controls the security parameters that will be assigned to the pod/container/volume. There are two levels of security context: pod level security context, and container level security context.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_general_apply_scc
Identifiers and References

References:  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.7.3

Rule   Manage Image Provenance Using ImagePolicyWebhook   [ref]

OpenShift administrators can control which images can be imported, tagged, and run in a cluster. There are two facilities for this purpose: (1) Allowed Registries, allowing administrators to restrict image origins to known external registries; and (2) ImagePolicy Admission plug-in which lets administrators specify specific images which are allowed to run on the OpenShift cluster. Configure an Image policy per the Image Policy chapter in the OpenShift documentation: https://docs.openshift.com/container-platform/4.4/openshift_images/image-configuration.html
Rationale:
Image Policy ensures that only approved container images are allowed to be ran on the OpenShift platform.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_general_configure_imagepolicywebhook
Identifiers and References

References:  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.5.1

Rule   The default namespace should not be used   [ref]

Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult.
Rationale:
Resources in a Kubernetes cluster should be segregated by namespace, to allow for security controls to be applied at that level and to make it easier to manage resources.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_general_default_namespace_use
Identifiers and References

References:  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.7.4

Rule   Ensure Seccomp Profile Pod Definitions   [ref]

Enable default seccomp profiles in your pod definitions.
Rationale:
Seccomp (secure computing mode) is used to restrict the set of system calls applications can make, allowing cluster administrators greater control over the security of workloads running in the cluster. Kubernetes disables seccomp profiles by default for historical reasons. You should enable it to ensure that the workloads have restricted actions available within the container.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_general_default_seccomp_profile
Identifiers and References

References:  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.7.2

Rule   Create administrative boundaries between resources using namespaces   [ref]

Use namespaces to isolate your Kubernetes objects.
Rationale:
Limiting the scope of user permissions can reduce the impact of mistakes or malicious activities. A Kubernetes namespace allows you to partition created resources into logically named groups. Resources created in one namespace can be hidden from other namespaces. By default, each resource created by a user in Kubernetes cluster runs in a default namespace, called default. You can create additional namespaces and attach resources and users to them. You can use Kubernetes Authorization plugins to create policies that segregate access to namespace resources between different users.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_general_namespaces_in_use
Identifiers and References

References:  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.7.1

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:  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/clusters/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
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
Rationale:
no rationale
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_version_detect_in_ocp
Identifiers and References
Group   Kubernetes Kubelet Settings   Group contains 19 rules
[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   Disable Anonymous Authentication to the Kubelet   [ref]

By default, anonymous access to the Kubelet server is enabled. This configuration check ensures that anonymous requests to the Kubelet server are disabled. Edit the Kubelet server configuration file /etc/kubernetes/kubelet.conf on the kubelet node(s) and set the below parameter:
authentication:
  ...
  anonymous:
    enabled: false
  ...
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" 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 Kubelet server. OpenShift Operators should rely on authentication to authorize access and disallow anonymous requests.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_anonymous_auth
Identifiers and References

Identifiers:  CCE-83815-1

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.1

Rule   Ensure authorization is set to Webhook   [ref]

Unauthenticated/unauthorized users should have no access to OpenShift nodes. The Kubelet should be set to only allow Webhook authorization. To ensure that the Kubelet requires authorization, validate that authorization is configured to Webhook in /etc/kubernetes/kubelet.conf:
authorization:
  mode: Webhook
  ...
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Ensuring that the authorization is configured correctly helps enforce that unauthenticated/unauthorized users have no access to OpenShift nodes.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_authorization_mode
Identifiers and References

Identifiers:  CCE-83593-4

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.2

Rule   kubelet - Configure the Client CA Certificate   [ref]

By default, the kubelet is not configured with a CA certificate which can subject the kubelet to man-in-the-middle attacks. To configure a client CA certificate, edit the kubelet configuration file /etc/kubernetes/kubelet.conf on the kubelet node(s) and set the below parameter:
authentication:
...
  x509:
    clientCAFile: /etc/kubernetes/kubelet-ca.crt
...
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Not having a CA certificate for the kubelet will subject the kubelet to possible man-in-the-middle attacks especially on unsafe or untrusted networks. Certificate validation for the kubelet allows the API server to validate the kubelet's identity.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_configure_client_ca
Identifiers and References

Identifiers:  CCE-83724-5

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.3

Rule   Kubelet - Ensure Event Creation Is Configured   [ref]

Security relevant information should be captured. The eventRecordQPS Kubelet option can be used to limit the rate at which events are gathered. Setting this too low could result in relevant events not being logged, however the unlimited setting of 0 could result in a denial of service on the kubelet. Processing and storage systems should be scaled to handle the expected event load. To set the eventRecordQPS option for the kubelet, create a KubeletConfig option along these lines:
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
   name: kubelet-config-$pool
spec:
    machineConfigPoolSelector:
        matchLabels:
            pools.operator.machineconfiguration.openshift.io/$pool_name: ""
    kubeletConfig:
        eventRecordQPS: 5
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_configure_event_creation
Identifiers and References

Identifiers:  CCE-83576-9

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.9


---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    eventRecordQPS: {{.var_event_record_qps}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    eventRecordQPS: {{.var_event_record_qps}}

Rule   Ensure That The kubelet Client Certificate Is Correctly Set   [ref]

To ensure the kubelet TLS client certificate is configured, edit the kubelet configuration file /etc/kubernetes/kubelet.conf and configure the kubelet certificate file.
tlsCertFile: /path/to/TLS/cert.key
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["kubelet-client-certificate"]) | .apiServerArguments["kubelet-client-certificate"][] | select(test("/etc/kubernetes/certs/kubelet/tls.crt"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["kubelet-client-certificate"]) | .apiServerArguments["kubelet-client-certificate"][] | select(test("{{.var_apiserver_kubelet_client_cert}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#e5500055b4aa2fcf00dc09ad0e66e44b6b42d67f8d53d1e72ff81b32f0e09865 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_configure_tls_cert
Identifiers and References

Identifiers:  CCE-83396-2

References:  CIP-003-8 R4.2, CIP-007-3 R5.1, SC-8, SC-8(1), SC-8(2), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000441-CTR-001090, SRG-APP-000442-CTR-001095, 4.2.10

Rule   Ensure That The kubelet Client Certificate Is Correctly Set   [ref]

To ensure the kubelet TLS client certificate is configured, edit the kubelet configuration file /etc/kubernetes/kubelet.conf and configure the kubelet certificate file.
tlsCertFile: /path/to/TLS/cert.key
Note that this particular rule is only valid for OCP releases up to and
including 4.8
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-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_configure_tls_cert_pre_4_9
Identifiers and References

Identifiers:  CCE-90615-6

References:  SC-8, SC-8(1), SC-8(2), 4.2.10

Rule   Ensure that the Kubelet only makes use of Strong Cryptographic Ciphers   [ref]

Ensure that the Kubelet is configured to only use strong cryptographic ciphers. To set the cipher suites for the kubelet, create new or modify existing KubeletConfig object along these lines, one for every MachineConfigPool:
  apiVersion: machineconfiguration.openshift.io/v1
  kind: KubeletConfig
  metadata:
     name: kubelet-config-$pool
  spec:
      machineConfigPoolSelector:
          matchLabels:
              pools.operator.machineconfiguration.openshift.io/$pool_name: ""
      kubeletConfig:
        tlsCipherSuites:
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  
In order to configure this rule to check for an alternative cipher, both var_kubelet_tls_cipher_suites_regex and var_kubelet_tls_cipher_suites have to be set
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_configure_tls_cipher_suites
Identifiers and References

Identifiers:  CCE-86030-4

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.13


---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    tlsCipherSuites: [{{.var_kubelet_tls_cipher_suites}}]
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    tlsCipherSuites: [{{.var_kubelet_tls_cipher_suites}}]

Rule   Ensure That The kubelet Server Key Is Correctly Set   [ref]

To ensure the kubelet TLS private server key certificate is configured, edit the kubelet configuration file /etc/kubernetes/kubelet.conf and configure the kubelet private key file.
tlsPrivateKeyFile: /path/to/TLS/private.key
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.data."config.json" | fromjson | select(.apiServerArguments["kubelet-client-key"]) | .apiServerArguments["kubelet-client-key"][] | select(test("/etc/kubernetes/certs/kubelet/tls.key"))]{{else}}[.data."config.yaml" | fromjson | select(.apiServerArguments["kubelet-client-key"]) | .apiServerArguments["kubelet-client-key"][] | select(test("{{.var_apiserver_kubelet_client_key}}"))]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#1e2b7c1158e0b9a602cb20d62c82b4660907bb57b63dac11c6c7c64211c49c69 file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_configure_tls_key
Identifiers and References

Identifiers:  CCE-90614-9

References:  CIP-003-8 R4.2, CIP-007-3 R5.1, SC-8, SC-8(1), SC-8(2), Req-2.2, Req-2.2.3, Req-2.3, SRG-APP-000441-CTR-001090, SRG-APP-000442-CTR-001095, 4.2.10

Rule   Ensure That The kubelet Server Key Is Correctly Set   [ref]

To ensure the kubelet TLS private server key certificate is configured, edit the kubelet configuration file /etc/kubernetes/kubelet.conf and configure the kubelet private key file.
tlsPrivateKeyFile: /path/to/TLS/private.key
Note that this particular rule is only valid for OCP releases up to and
including 4.8
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-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file.
Rationale:
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_configure_tls_key_pre_4_9
Identifiers and References

Identifiers:  CCE-90542-2

References:  SC-8, SC-8(1), SC-8(2), 4.2.10

Rule   kubelet - Disable the Read-Only Port   [ref]

To disable the read-only port, edit the kubelet configuration Edit the openshift-kube-apiserver configmap and set the kubelet-read-only-port parameter to 0:
"apiServerArguments":{
  ...
  "kubelet-read-only-port":[
    "0"
  ],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430 file.
Rationale:
OpenShift disables the read-only port (10255) on all nodes by setting the read-only port kubelet flag to 0. This ensures only authenticated connections are able to receive information about the OpenShift system.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_disable_readonly_port
Identifiers and References

Identifiers:  CCE-83427-5

References:  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, 4.2.4

Rule   kubelet - Enable Certificate Rotation   [ref]

To enable the kubelet to rotate client certificates, edit the kubelet configuration file /etc/kubernetes/kubelet.conf on the kubelet node(s) and set the below parameter:
...
rotateCertificates: true
...
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Allowing the kubelet to auto-update the certificates ensure that there is no downtime in certificate renewal as well as ensures confidentiality and integrity.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_enable_cert_rotation
Identifiers and References

Identifiers:  CCE-83838-3

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.11

Rule   kubelet - Enable Client Certificate Rotation   [ref]

To enable the kubelet to rotate client certificates, edit the kubelet configuration file /etc/kubernetes/kubelet.conf on the kubelet node(s) and set the below parameter:
featureGates:
...
  RotateKubeletClientCertificate: true
...
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Allowing the kubelet to auto-update the certificates ensure that there is no downtime in certificate renewal as well as ensures confidentiality and integrity.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_enable_client_cert_rotation
Identifiers and References

Identifiers:  CCE-83352-5

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.11

Rule   kubelet - Allow Automatic Firewall Configuration   [ref]

The kubelet has the ability to automatically configure the firewall to allow the containers required ports and connections to networking resources and destinations parameters potentially creating a security incident. To allow the kubelet to modify the firewall, edit the kubelet configuration file /etc/kubernetes/kubelet.conf on the kubelet node(s) and set the below parameter:
makeIPTablesUtilChains: true
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
The kubelet should automatically configure the firewall settings to allow access and networking traffic through. This ensures that when a pod or container is running that the correct ports are configured as well as removing the ports when a pod or container is no longer in existence.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_enable_iptables_util_chains
Identifiers and References

Identifiers:  CCE-83775-7

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.7


---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    makeIPTablesUtilChains: true
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    makeIPTablesUtilChains: true

Rule   kubelet - Enable Server Certificate Rotation   [ref]

To enable the kubelet to rotate server certificates, edit the kubelet configuration file /etc/kubernetes/kubelet.conf on the kubelet node(s) and set the below parameter:
featureGates:
...
  RotateKubeletServerCertificate: true
...
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Allowing the kubelet to auto-update the certificates ensure that there is no downtime in certificate renewal as well as ensures confidentiality and integrity.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_enable_server_cert_rotation
Identifiers and References

Identifiers:  CCE-83356-6

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.12

Rule   kubelet - Do Not Disable Streaming Timeouts   [ref]

Timouts for streaming connections should not be disabled as they help to prevent denial-of-service attacks. To configure streaming connection timeouts To set the streamingConnectionIdleTimeout option for the kubelet, create a KubeletConfig option along these lines:
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
   name: kubelet-config-$pool
spec:
    machineConfigPoolSelector:
        matchLabels:
            pools.operator.machineconfiguration.openshift.io/$pool_name: ""
    kubeletConfig:
        streamingConnectionIdleTimeout: 4h0m0s
Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Ensuring connections have timeouts helps to protect against denial-of-service attacks as well as disconnect inactive connections. In addition, setting connections timeouts helps to prevent from running out of ephemeral ports.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_enable_streaming_connections
Identifiers and References

Identifiers:  CCE-84097-5

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 4.2.5


---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    streamingConnectionIdleTimeout: {{.var_streaming_connection_timeouts}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    streamingConnectionIdleTimeout: {{.var_streaming_connection_timeouts}}

Rule   Ensure Eviction threshold Settings Are Set - evictionHard: imagefs.available   [ref]

Two types of garbage collection are performed on an OpenShift Container Platform node:

  • Container garbage collection: Removes terminated containers.
  • Image garbage collection: Removes images not referenced by any running pods.

Container garbage collection can be performed using eviction thresholds. Image garbage collection relies on disk usage as reported by cAdvisor on the node to decide which images to remove from the node.

The OpenShift administrator can configure how OpenShift Container Platform performs garbage collection by creating a kubeletConfig object for each Machine Config Pool using any combination of the following:

  • soft eviction for containers
  • hard eviction for containers
  • eviction for images

To configure, follow the directions in the documentation

This rule pertains to the imagefs.available setting of the evictionHard section.

Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_eviction_thresholds_set_hard_imagefs_available
Identifiers and References

Identifiers:  CCE-84144-5

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 1.3.1


---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    evictionHard:
      imagefs.available: {{.var_kubelet_evictionhard_imagefs_available}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    evictionPressureTransitionPeriod: 0s
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    evictionHard:
      imagefs.available: {{.var_kubelet_evictionhard_imagefs_available}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    evictionPressureTransitionPeriod: 0s

Rule   Ensure Eviction threshold Settings Are Set - evictionHard: memory.available   [ref]

Two types of garbage collection are performed on an OpenShift Container Platform node:

  • Container garbage collection: Removes terminated containers.
  • Image garbage collection: Removes images not referenced by any running pods.

Container garbage collection can be performed using eviction thresholds. Image garbage collection relies on disk usage as reported by cAdvisor on the node to decide which images to remove from the node.

The OpenShift administrator can configure how OpenShift Container Platform performs garbage collection by creating a kubeletConfig object for each Machine Config Pool using any combination of the following:

  • soft eviction for containers
  • hard eviction for containers
  • eviction for images

To configure, follow the directions in the documentation

This rule pertains to the memory.available setting of the evictionHard section.

Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_eviction_thresholds_set_hard_memory_available
Identifiers and References

Identifiers:  CCE-84135-3

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 1.3.1


---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    evictionHard:
      memory.available: {{.var_kubelet_evictionhard_memory_available}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    evictionPressureTransitionPeriod: 0s
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    evictionHard:
      memory.available: {{.var_kubelet_evictionhard_memory_available}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    evictionPressureTransitionPeriod: 0s

Rule   Ensure Eviction threshold Settings Are Set - evictionHard: nodefs.available   [ref]

Two types of garbage collection are performed on an OpenShift Container Platform node:

  • Container garbage collection: Removes terminated containers.
  • Image garbage collection: Removes images not referenced by any running pods.

Container garbage collection can be performed using eviction thresholds. Image garbage collection relies on disk usage as reported by cAdvisor on the node to decide which images to remove from the node.

The OpenShift administrator can configure how OpenShift Container Platform performs garbage collection by creating a kubeletConfig object for each Machine Config Pool using any combination of the following:

  • soft eviction for containers
  • hard eviction for containers
  • eviction for images

To configure, follow the directions in the documentation

This rule pertains to the nodefs.available setting of the evictionHard section.

Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_eviction_thresholds_set_hard_nodefs_available
Identifiers and References

Identifiers:  CCE-84138-7

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 1.3.1


---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    evictionHard:
      nodefs.available: {{.var_kubelet_evictionhard_nodefs_available}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    evictionPressureTransitionPeriod: 0s
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    evictionHard:
      nodefs.available: {{.var_kubelet_evictionhard_nodefs_available}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    evictionPressureTransitionPeriod: 0s

Rule   Ensure Eviction threshold Settings Are Set - evictionHard: nodefs.inodesFree   [ref]

Two types of garbage collection are performed on an OpenShift Container Platform node:

  • Container garbage collection: Removes terminated containers.
  • Image garbage collection: Removes images not referenced by any running pods.

Container garbage collection can be performed using eviction thresholds. Image garbage collection relies on disk usage as reported by cAdvisor on the node to decide which images to remove from the node.

The OpenShift administrator can configure how OpenShift Container Platform performs garbage collection by creating a kubeletConfig object for each Machine Config Pool using any combination of the following:

  • soft eviction for containers
  • hard eviction for containers
  • eviction for images

To configure, follow the directions in the documentation

This rule pertains to the nodefs.inodesFree setting of the evictionHard section.

Warning:  This rule's check operates on the cluster configuration dump. This will be a Platform rule, var_role_worker and var_role_master needed to be set if scan is not expected to run on master, and worker nodes. Therefore, you need to use a tool that can query the OCP API, retrieve KubeletConfig through "/api/v1/nodes/NODE_NAME/proxy/configz" API endpoint to the local /kubernetes-api-resources"/kubeletconfig/role/role" file.
Rationale:
Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_eviction_thresholds_set_hard_nodefs_inodesfree
Identifiers and References

Identifiers:  CCE-84141-1

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), SRG-APP-000516-CTR-001325, 1.3.1


---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    evictionHard:
      nodefs.inodesFree: {{.var_kubelet_evictionhard_nodefs_inodesfree}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_worker}}"
spec:
  kubeletConfig:
    evictionPressureTransitionPeriod: 0s
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    evictionHard:
      nodefs.inodesFree: {{.var_kubelet_evictionhard_nodefs_inodesfree}}
---
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  annotations:
    complianceascode.io/node-role: "{{.var_role_master}}"
spec:
  kubeletConfig:
    evictionPressureTransitionPeriod: 0s
Group   OpenShift - Logging Settings   Group contains 1 rule
[ref]   Contains evaluations for the cluster's logging configuration settings.

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

Identifiers:  CCE-83577-7

References:  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, 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), Req-2.2, Req-12.5.5, 12.1.4, SRG-APP-000089-CTR-000150, SRG-APP-000101-CTR-000205, 3.2.1, 3.2.2


---
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  audit:
    profile: {{.var_openshift_audit_profile}}
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
Identifiers and References

References:  CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-1.1.4, Req-1.2, Req-2.2, SRG-APP-000038-CTR-000105, 5.3.1

Rule   Ensure that HyperShift Hosted 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/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/networkpolicies API endpoint, filter with with the jq utility using the following filter [.items[] | .metadata.name] and persist it to the local /kubernetes-api-resources/apis/networking.k8s.io/v1/namespaces/networkpolicies#08ccf6ea6e29d378349cc36918df58d5e6172cd458ede2bf03fe4266ee1b6d6a 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_hypershift_hosted
Identifiers and References

Identifiers:  CCE-86104-7

References:  Req-1.1.4, Req-1.2, Req-1.2.1, Req-1.3.1, Req-1.3.2, Req-2.2, 5.3.2

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") | .metadata.namespace] | unique and persist it to the local /kubernetes-api-resources/apis/networking.k8s.io/v1/networkpolicies#51742b3e87275db9eb7fc6c0286a9e536178a2a83e3670b615ceaf545e7fd300 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 persist it to the local /kubernetes-api-resources/api/v1/namespaces#34d4beecc95c65d815d9d48fd4fdcb0c521631852ad088ef74e36d012b0e1e0d 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
Identifiers and References

References:  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, 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), Req-1.1.4, Req-1.2, Req-1.2.1, Req-1.3.1, Req-1.3.2, Req-2.2, SRG-APP-000038-CTR-000105, 5.3.2

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

Rule   Configure the OpenShift API Server Maximum Retained Audit Logs   [ref]

To configure how many rotations of audit logs are retained, edit the openshift-apiserver configmap and set the audit-log-maxbackup parameter to 10 or to an organizationally appropriate value:
"apiServerArguments":{
  ...
  "audit-log-maxbackup": [10],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/openshift-apiserver{{else}}/api/v1/namespaces/openshift-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.yaml"{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-apiserver/configmaps/config#45ae2c88fe28d39a42f19e165a1612353224e9663eb369000e03c7efcd10ef59 file.
Rationale:
OpenShift automatically rotates the log files. Retaining old log files ensures OpenShift Operators will have sufficient log data available for carrying out any investigation or correlation. For example, if the audit log size is set to 100 MB and the number of retained log files is set to 10, OpenShift Operators would have approximately 1 GB of log data to use during analysis.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_ocp_api_server_audit_log_maxbackup
Identifiers and References

Identifiers:  CCE-83977-9

References:  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.24

Rule   Configure OpenShift API Server Maximum Audit Log Size   [ref]

To rotate audit logs upon reaching a maximum size, edit the openshift-apiserver configmap and set the audit-log-maxsize parameter to an appropriate size in MB. For example, to set it to 100 MB:
"apiServerArguments":{
  ...
  "audit-log-maxsize": ["100"],
  ...
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/openshift-apiserver{{else}}/api/v1/namespaces/openshift-apiserver/configmaps/config{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}.data."config.yaml"{{else}}.data."config.yaml" | fromjson{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-apiserver/configmaps/config#45ae2c88fe28d39a42f19e165a1612353224e9663eb369000e03c7efcd10ef59 file.
Rationale:
OpenShift automatically rotates log files. Retaining old log files ensures that OpenShift Operators have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, there would be approximately 1 GB of log data available for use in analysis.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_ocp_api_server_audit_log_maxsize
Identifiers and References

Identifiers:  CCE-83687-4

References:  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.25

Rule   Configure the Audit Log Path   [ref]

To enable auditing on the OpenShift API Server, the audit log path must be set. Edit the openshift-apiserver configmap and set the audit-log-path to a suitable path and file where audit logs should be written. For example:
"apiServerArguments":{
  ...
  "audit-log-path":"/var/log/openshift-apiserver/audit.log",
  ...
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-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-apiserver/configmaps/config file.
Rationale:
Auditing of the API Server is not enabled by default. Auditing the API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected the system by users, administrators, or other system components.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_openshift_api_server_audit_log_path
Identifiers and References

Identifiers:  CCE-83547-0

References:  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.22

Group   Role-based Access Control   Group contains 5 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   Profiling is protected by RBAC   [ref]

Ensure that the cluster-debugger cluster role includes the /debug/pprof resource URL. This demonstrates that profiling is protected by RBAC, with a specific cluster role to allow access.
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/clusterroles/cluster-debugger API endpoint to the local /kubernetes-api-resources/apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-debugger file.
Rationale:
Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface. To ensure the collected data is not exploited, profiling endpoints are secured via RBAC (see cluster-debugger role). By default, the profiling endpoints are accessible only by users bound to cluster-admin or cluster-debugger role. Profiling can not be disabled.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_rbac_debug_role_protects_pprof
Identifiers and References

Identifiers:  CCE-84182-5

References:  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.3.2, 1.4.1

Rule   Ensure that the cluster-admin role is only used where required   [ref]

The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.
Rationale:
Kubernetes provides a set of default roles where RBAC is used. Some of these roles such as cluster-admin provide wide-ranging privileges which should only be applied where absolutely necessary. Roles such as cluster-admin allow super-user access to perform any action on any resource. When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. When used in a RoleBinding, it gives full control over every resource in the rolebinding's namespace, including the namespace itself.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_rbac_limit_cluster_admin
Identifiers and References

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

Rule   Limit Access to Kubernetes Secrets   [ref]

The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation. To restrict users from secrets, remove get, list, and watch access to unauthorized users to secret objects in the cluster.
Rationale:
Inappropriate access to secrets stored within the Kubernetes cluster can allow for an attacker to gain additional access to the Kubernetes cluster or external resources whose credentials are stored as secrets.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_rbac_limit_secrets_access
Identifiers and References

References:  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.1.2

Rule   Minimize Access to Pod Creation   [ref]

The ability to create pods in a namespace can provide a number of opportunities for privilege escalation. Where applicable, remove create access to pod objects in the cluster.
Rationale:
The ability to create pods in a cluster opens up the cluster for privilege escalation.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_rbac_pod_creation_access
Identifiers and References

References:  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.1.4

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

References:  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.1.3

Group   Security Context Constraints (SCC)   Group contains 9 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
Identifiers and References

References:  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.9

Rule   Limit Container Capabilities   [ref]

Containers should not enable more capabilities 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.
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:
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_limit_container_allowed_capabilities
Identifiers and References

References:  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.8

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

Identifiers:  CCE-83447-3

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

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

Group   OpenShift - Kubernetes - Scheduler Settings   Group contains 1 rule
[ref]   Contains evaluations for kube-scheduler configuration settings.

Rule   Ensure that the bind-address parameter is not used   [ref]

The Scheduler API service which runs on port 10251/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface.
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"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/pods?labelSelector=app%3Dkube-scheduler{{else}}/api/v1/namespaces/openshift-kube-scheduler/configmaps/kube-scheduler-pod{{end}} API endpoint, filter with with the jq utility using the following filter {{if ne .hypershift_cluster "None"}}[.items[0].spec.containers[0].args | join(" ")]{{else}}[.data."pod.yaml"]{{end}} and persist it to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-scheduler/configmaps/kube-scheduler-pod#569895645b4f9b87d4e21ab3c6fe4cc03627259826715e5043d5d8889c6c12d3 file.
Rationale:
In OpenShift 4, The Kubernetes Scheduler operator manages and updates the Kubernetes Scheduler deployed on top of OpenShift. By default, the operator exposes metrics via metrics service. The metrics are collected from the Kubernetes Scheduler operator. Profiling data is sent to healthzPort, the port of the localhost healthz endpoint. Changing this value may disrupt components that monitor the kubelet health.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_scheduler_no_bind_address
Identifiers and References

Identifiers:  CCE-83674-2

References:  CIP-003-8 R4.2, CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R5.1, CIP-007-3 R6.1, CM-6, CM-6(1), SC-8, SC-8(1), Req-2.2, SRG-APP-000516-CTR-001325, 1.4.2

Group   Kubernetes Secrets Management   Group contains 2 rules
[ref]   Secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Such information might otherwise be put in a Pod specification or in an image.

Rule   Consider external secret storage   [ref]

Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets.
Rationale:
Kubernetes supports secrets as first-class objects, but care needs to be taken to ensure that access to secrets is carefully limited. Using an external secrets provider can ease the management of access to secrets, especially where secrets are used across both Kubernetes and non-Kubernetes environments.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_secrets_consider_external_storage
Identifiers and References

References:  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.4.2

Rule   Do Not Use Environment Variables with Secrets   [ref]

Secrets should be mounted as data volumes instead of environment variables.
Rationale:
Environment variables are subject and very susceptible to malicious hijacking methods by an adversary, as such, environment variables should never be used for secrets.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_secrets_no_environment_variables
Identifiers and References

References:  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.4.1

Group   Kubernetes - Worker Node Settings   Group contains 3 rules
[ref]   Contains evaluations for the worker node configuration settings.

Rule   Verify Group Who Owns The Worker Proxy Kubeconfig File   [ref]

To ensure the Kubernetes ConfigMap is mounted into the sdn daemonset pods with the correct ownership, make sure that the sdn-config ConfigMap is mounted using a ConfigMap at the /config mount point and that the sdn container points to that configuration using the --proxy-config command line option. Run:
 oc get -nopenshift-sdn ds sdn -ojson | jq -r '.spec.template.spec.containers[] | select(.name == "sdn")'
and ensure the --proxy-config parameter points to /config/kube-proxy-config.yaml and that the config mount point is mounted from the sdn-config ConfigMap.
Rationale:
The kubeconfig file for kube-proxy provides permissions to the kube-proxy service. The proxy kubeconfig file contains information about the administrative configuration of the OpenShift cluster that is configured on the system. Protection of this file is critical for OpenShift security. The file is provided via a ConfigMap mount, so the kubelet itself makes sure that the file permissions are appropriate for the container taking it into use.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_proxy_kubeconfig
Identifiers and References

References:  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, 4.1.4

Rule   Verify User Who Owns The Worker Proxy Kubeconfig File   [ref]

To ensure the Kubernetes ConfigMap is mounted into the sdn daemonset pods with the correct ownership, make sure that the sdn-config ConfigMap is mounted using a ConfigMap at the /config mount point and that the sdn container points to that configuration using the --proxy-config command line option. Run:
 oc get -nopenshift-sdn ds sdn -ojson | jq -r '.spec.template.spec.containers[] | select(.name == "sdn")'
and ensure the --proxy-config parameter points to /config/kube-proxy-config.yaml and that the config mount point is mounted from the sdn-config ConfigMap.
Rationale:
The kubeconfig file for kube-proxy provides permissions to the kube-proxy service. The proxy kubeconfig file contains information about the administrative configuration of the OpenShift cluster that is configured on the system. Protection of this file is critical for OpenShift security. The file is provided via a ConfigMap mount, so the kubelet itself makes sure that the file permissions are appropriate for the container taking it into use.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_proxy_kubeconfig
Identifiers and References

References:  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, 4.1.4

Rule   Verify Permissions on the Worker Proxy Kubeconfig File   [ref]

To ensure the Kubernetes ConfigMap is mounted into the sdn daemonset pods with the correct permissions, make sure that the sdn-config ConfigMap is mounted using restrictive permissions. Check that the config VolumeMount mounts the sdn-config configMap with permissions set to 420:
{
"configMap": {
  "defaultMode": 420,
  "name": "sdn-config"
  },
"name": "config"
}
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/apps/v1/namespaces/openshift-sdn/daemonsets/sdn API endpoint to the local /kubernetes-api-resources/apis/apps/v1/namespaces/openshift-sdn/daemonsets/sdn file.
Rationale:
The kube-proxy kubeconfig file controls various parameters of the kube-proxy service in the worker node. If used, you should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system. The kube-proxy runs with the kubeconfig parameters configured as a Kubernetes ConfigMap instead of a file. In this case, there is no proxy kubeconfig file. But appropriate permissions still need to be set in the ConfigMap mount.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_proxy_kubeconfig
Identifiers and References

Identifiers:  CCE-84047-0

References:  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, 4.1.3

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.