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.0.0, currently unreleased. This profile includes Center for Internet Security® Red Hat OpenShift Container Platform 4 CIS Benchmarks™ content.
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:4.1

Revision History

Current version: 0.1.51

  • draft (as of 2020-07-20)

Table of Contents

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

Checklist

Group   Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4   Group contains 14 groups and 123 rules
Group   OpenShift Settings   Group contains 13 groups and 123 rules

[ref]   Each section of this configuration guide includes information about the default configuration of an OpenShift 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. Many 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 admininstrator has not made changes that would be less secure than the OpenShift defaults. A small number of items require configuration. Finally, there are some recommendations that require decisions by the system operator, such as audit log size, retention, and related settings.

Group   OpenShift - 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 OpenShift. 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 OpenShift.

Group   OpenShift - Master Node Settings   Group contains 29 rules

[ref]   Contains evaluations for the master node configuration settings.

Rule   Verify Permissions on the Kube Controller Manager Pod Specificiation File   [ref]

To properly set the permissions of /etc/kubernetes/static-pod-resources/kube-controller-manager-pod.yaml, run the command:

$ sudo chmod 0644 /etc/kubernetes/static-pod-resources/kube-controller-manager-pod.yaml

Rationale:

If the Kube specification file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the configuration of an OpenShift Controller Manager server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_kube_controller_manager
Identifiers and References

References:  1.1.3

Rule   Verify User Who Owns The OpenShift Scheduler Kubeconfig File   [ref]

To properly set the owner of /etc/kubernetes/static-pod-resources/configmaps/scheduler-kubeconfig/kubeconfig, run the command:

$ sudo chown root /etc/kubernetes/static-pod-resources/configmaps/scheduler-kubeconfig/kubeconfig 

Rationale:

The Scheduler Kubeconfig file contains information about the configuration of the OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_scheduler_kubeconfig
Identifiers and References

References:  1.1.16

Rule   Verify Group Who Owns The OpenShift Open vSwitch Files   [ref]

To properly set the group owner of /etc/openvswitch/*, run the command:

$ sudo chgrp root /etc/openvswitch/*

Rationale:

CNI (Container Network Interface) files consist of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. Allowing writeable access to the files could allow an attacker to modify the networking configuration potentially adding a rouge network connection.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_openvswitch
Identifiers and References

References:  1.1.10

Rule   Verify User Who Owns The OpenShift Controller Manager Kubeconfig File   [ref]

To properly set the owner of /etc/kubernetes/static-pod-resources/configmaps/controller-manager-kubeconfig/kubeconfig, run the command:

$ sudo chown root /etc/kubernetes/static-pod-resources/configmaps/controller-manager-kubeconfig/kubeconfig 

Rationale:

The Controller Manager Kubeconfig file contains information about the configuration of the OpenShift Controller Manager Server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_controller_manager_kubeconfig
Identifiers and References

References:  1.1.18

Rule   Verify Permissions on the OpenShift Controller Manager Kubeconfig File   [ref]

To properly set the permissions of /etc/kubernetes/static-pod-resources/configmaps/controller-manager-kubeconfig/kubeconfig, run the command:

$ sudo chmod 0600 /etc/kubernetes/static-pod-resources/configmaps/controller-manager-kubeconfig/kubeconfig

Rationale:

If the Controller Manager Kubeconfig file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the configuration of an OpenShift Controller Manager server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_controller_manager_kubeconfig
Identifiers and References

References:  1.1.17

Rule   Verify User Who Owns The Kube Controller Manager Pod Specificiation File   [ref]

To properly set the owner of /etc/kubernetes/static-pod-resources/kube-controller-manager-pod.yaml, run the command:

$ sudo chown root /etc/kubernetes/static-pod-resources/kube-controller-manager-pod.yaml 

Rationale:

The Kube specification file contains information about the configuration of the OpenShift Controller Manager Server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_kube_controller_manager
Identifiers and References

References:  1.1.4

Rule   Verify Group Who Owns The Kube API Server Pod Specification File   [ref]

To properly set the group owner of /etc/kubernetes/static-pod-resources/kube-apiserver-pod.yaml, run the command:

$ sudo chgrp root /etc/kubernetes/static-pod-resources/kube-apiserver-pod.yaml

Rationale:

The Kube specification file contains information about the configuration of the OpenShift API Server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_kube_apiserver
Identifiers and References

References:  1.1.2

Rule   Verify Group Who Owns The OpenShift Controller Manager Kubeconfig File   [ref]

To properly set the group owner of /etc/kubernetes/static-pod-resources/configmaps/controller-manager-kubeconfig/kubeconfig, run the command:

$ sudo chgrp root /etc/kubernetes/static-pod-resources/configmaps/controller-manager-kubeconfig/kubeconfig

Rationale:

The Controller Manager Kubeconfig file contains information about the configuration of the OpenShift Controller Manager Server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_controller_manager_kubeconfig
Identifiers and References

References:  1.1.18

Rule   Verify Permissions on the Kube Scheduler Pod Specification File   [ref]

To properly set the permissions of /etc/kubernetes/static-pod-resources/kube-scheduler-pod.yaml, run the command:

$ sudo chmod 0644 /etc/kubernetes/static-pod-resources/kube-scheduler-pod.yaml

Rationale:

If the Kube specification file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the configuration of an OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_kube_scheduler
Identifiers and References

References:  1.1.5

Rule   Verify Permissions on the OpenShift Scheduler Kubeconfig File   [ref]

To properly set the permissions of /etc/kubernetes/static-pod-resources/configmaps/scheduler-kubeconfig/kubeconfig, run the command:

$ sudo chmod 0600 /etc/kubernetes/static-pod-resources/configmaps/scheduler-kubeconfig/kubeconfig

Rationale:

If the Scheduler Kubeconfig file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the configuration of an OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_scheduler_kubeconfig
Identifiers and References

References:  1.1.15

Rule   Verify User Who Owns The Kube API Server Pod Specification File   [ref]

To properly set the owner of /etc/kubernetes/static-pod-resources/kube-apiserver-pod.yaml, run the command:

$ sudo chown root /etc/kubernetes/static-pod-resources/kube-apiserver-pod.yaml 

Rationale:

The Kube specification file contains information about the configuration of the OpenShift API Server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_kube_apiserver
Identifiers and References

References:  1.1.2

Rule   Verify Permissions on the OpenShift Open vSwitch Files   [ref]

To properly set the permissions of /etc/openvswitch/*, run the command:

$ sudo chmod 0644 /etc/openvswitch/*

Rationale:

CNI (Container Network Interface) files consist of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. Allowing writeable access to the files could allow an attacker to modify the networking configuration potentially adding a rouge network connection.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_openvswitch
Identifiers and References

References:  1.4.9

Rule   Verify User Who Owns The OpenShift Admin Kubeconfig File   [ref]

To properly set the owner of /etc/kubernetes/kubeconfig, run the command:

$ sudo chown root /etc/kubernetes/kubeconfig 

Rationale:

The /etc/kubernetes/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.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_kubeconfig
Identifiers and References

References:  1.1.14

Rule   Verify Permissions on the OpenShift Container Network Interface Files   [ref]

To properly set the permissions of /etc/cni/net.d/*, run the command:

$ sudo chmod 0644 /etc/cni/net.d/*

Rationale:

CNI (Container Network Interface) files consist of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. Allowing writeable access to the files could allow an attacker to modify the networking configuration potentially adding a rouge network connection.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_cni_conf
Identifiers and References

References:  1.4.9

Rule   Verify User Who Owns The ETCD Member Pod Specification File   [ref]

To properly set the owner of /etc/kubernetes/manifests/etcd-member.yaml, run the command:

$ sudo chown root /etc/kubernetes/manifests/etcd-member.yaml 

Rationale:

The ETCD specification file contains information about the configuration of the OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etcd_member
Identifiers and References

References:  1.1.8

Rule   Verify Permissions on the ETCD Member Pod Specification File   [ref]

To properly set the permissions of /etc/kubernetes/manifests/etcd-member.yaml, run the command:

$ sudo chmod 0644 /etc/kubernetes/manifests/etcd-member.yaml

Rationale:

If the ETCD specification file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the configuration of an OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etcd_member
Identifiers and References

References:  1.1.7

Rule   The OpenShift etcd Data Directory Must Have Mode 0700   [ref]

To properly set the permissions of /var/lib/etcd, run the command:

$ sudo chmod 0700 /var/lib/etcd

Rationale:

The /var/lib/etcd directory contains highly-avaliable distributed key/value data storage across an OpenShift cluster. Allowing access to users to this directory could compromise OpenShift data and the cluster.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_var_lib_etcd
Identifiers and References

References:  1.1.11

Rule   Verify User Who Owns The Kube Scheduler Pod Specification File   [ref]

To properly set the owner of /etc/kubernetes/static-pod-resources/kube-scheduler-pod.yaml, run the command:

$ sudo chown root /etc/kubernetes/static-pod-resources/kube-scheduler-pod.yaml 

Rationale:

The Kube specification file contains information about the configuration of the OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_kube_scheduler
Identifiers and References

References:  1.1.6

Rule   Verify User Who Owns The OpenShift Open vSwitch Files   [ref]

To properly set the owner of /etc/openvswitch/*, run the command:

$ sudo chown root /etc/openvswitch/* 

Rationale:

CNI (Container Network Interface) files consist of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. Allowing writeable access to the files could allow an attacker to modify the networking configuration potentially adding a rouge network connection.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_openvswitch
Identifiers and References

References:  1.1.10

Rule   Verify Group Who Owns The ETCD Member Pod Specification File   [ref]

To properly set the group owner of /etc/kubernetes/manifests/etcd-member.yaml, run the command:

$ sudo chgrp root /etc/kubernetes/manifests/etcd-member.yaml

Rationale:

The Kube Specification file contains information about the configuration of the OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etcd_member
Identifiers and References

References:  1.1.8

Rule   Verify User Who Owns The OpenShift etcd Data Directory   [ref]

To properly set the owner of /var/lib/etcd, run the command:

$ sudo chown root /var/lib/etcd 

Rationale:

The /var/lib/etcd directory contains highly-avaliable distributed key/value data storage across an OpenShift cluster. Allowing access to users to this directory could compromise OpenShift data and the cluster.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_var_lib_etcd
Identifiers and References

References:  1.1.12

Rule   Verify Permissions on the OpenShift Admin Kubeconfig File   [ref]

To properly set the permissions of /etc/kubernetes/kubeconfig, run the command:

$ sudo chmod 0600 /etc/kubernetes/kubeconfig

Rationale:

If the /etc/kubernetes/kubeconfig file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the administration configuration of the OpenShift cluster that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_kubeconfig
Identifiers and References

References:  1.1.13

Rule   Verify Group Who Owns The OpenShift Container Network Interface Files   [ref]

To properly set the group owner of /etc/cni/net.d/*, run the command:

$ sudo chgrp root /etc/cni/net.d/*

Rationale:

CNI (Container Network Interface) files consist of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. Allowing writeable access to the files could allow an attacker to modify the networking configuration potentially adding a rouge network connection.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_cni_conf
Identifiers and References

References:  1.4.10

Rule   Verify Group Who Owns The Kube Controller Manager Pod Specificiation File   [ref]

To properly set the group owner of /etc/kubernetes/static-pod-resources/kube-controller-manager-pod.yaml, run the command:

$ sudo chgrp root /etc/kubernetes/static-pod-resources/kube-controller-manager-pod.yaml

Rationale:

The Kube specification file contains information about the configuration of the OpenShift Controller Manager Server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_kube_controller_manager
Identifiers and References

References:  1.1.4

Rule   Verify Permissions on the Kube API Server Pod Specification File   [ref]

To properly set the permissions of /etc/kubernetes/static-pod-resources/kube-apiserver-pod.yaml, run the command:

$ sudo chmod 0644 /etc/kubernetes/static-pod-resources/kube-apiserver-pod.yaml

Rationale:

If the Kube specification file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the configuration of an OpenShift API server that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_kube_apiserver
Identifiers and References

References:  1.1.1

Rule   Verify Group Who Owns The Kube Scheduler Pod Specification File   [ref]

To properly set the group owner of /etc/kubernetes/static-pod-resources/kube-scheduler-pod.yaml, run the command:

$ sudo chgrp root /etc/kubernetes/static-pod-resources/kube-scheduler-pod.yaml

Rationale:

The Kube Specification file contains information about the configuration of the OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_kube_scheduler
Identifiers and References

References:  1.1.6

Rule   Verify Group Who Owns The OpenShift Admin Kubeconfig File   [ref]

To properly set the group owner of /etc/kubernetes/kubeconfig, run the command:

$ sudo chgrp root /etc/kubernetes/kubeconfig

Rationale:

The /etc/kubernetes/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.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_kubeconfig
Identifiers and References

References:  1.1.14

Rule   Verify User Who Owns The OpenShift Container Network Interface Files   [ref]

To properly set the owner of /etc/cni/net.d/*, run the command:

$ sudo chown root /etc/cni/net.d/* 

Rationale:

CNI (Container Network Interface) files consist of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. Allowing writeable access to the files could allow an attacker to modify the networking configuration potentially adding a rouge network connection.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_cni_conf
Identifiers and References

References:  1.4.10

Rule   Verify Group Who Owns The OpenShift Scheduler Kubeconfig File   [ref]

To properly set the group owner of /etc/kubernetes/static-pod-resources/configmaps/scheduler-kubeconfig/kubeconfig, run the command:

$ sudo chgrp root /etc/kubernetes/static-pod-resources/configmaps/scheduler-kubeconfig/kubeconfig

Rationale:

The Scheduler Kubeconfig file contains information about the configuration of the OpenShift scheduler that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_scheduler_kubeconfig
Identifiers and References

References:  1.1.16

Group   OpenShift - General Security Practices   Group contains 1 rule

[ref]   Contains evaluations for general security practices for operating an OpenShift environment.

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

Group   Network Configuration and Firewalls   Group contains 2 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 Network Policies are Configured   [ref]

OpenShift supports Kubernetes NetworkPolicy using a Kubernetes Container Network Interface (CNI) plug-in. The Kubernetes NetworkPolicy plugin is preferred because Kubernetes Network Policies provide more granular control.

Rationale:

Properly configured network policies ensure traffic between OpenShift tenants is isolated.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_configure_network_policies
Identifiers and References

References:  5.3.1

Rule   Ensure Project Namespaces Use Network Policies   [ref]

Network policies should be configured for each project to isolate traffic on the network.

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

Group   OpenShift - Master Node Settings   Group contains 15 rules

[ref]   Contains evaluations for the master node configuration settings.

Rule   Verify Group Who Owns The OpenShift Node Service File   [ref]

To properly set the group owner of /etc/systemd/system/atomic-openshift-node.service, run the command:

$ sudo chgrp root /etc/systemd/system/atomic-openshift-node.service

Rationale:

The /etc/systemd/system/atomic-openshift-node.service file contains information about the configuration of the OpenShift node service that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_worker_service
Identifiers and References

References:  4.1.2

Rule   Verify User Who Owns The OpenShift Node Service File   [ref]

To properly set the owner of /etc/systemd/system/atomic-openshift-node.service, run the command:

$ sudo chown root /etc/systemd/system/atomic-openshift-node.service 

Rationale:

The /etc/systemd/system/atomic-openshift-node.service file contains information about the configuration of the OpenShift node service that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_worker_service
Identifiers and References

References:  4.1.2

Rule   Verify User Who Owns The Kubelet Configuration File   [ref]

To properly set the owner of /etc/kubernetes/kubelet.conf, run the command:

$ sudo chown root /etc/kubernetes/kubelet.conf 

Rationale:

The kubelet configuration file contains information about the configuration of the OpenShift node that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_kubelet_conf
Identifiers and References

References:  4.1.6

Rule   Verify Group Who Owns The Kubelet Configuration File   [ref]

To properly set the group owner of /etc/kubernetes/kubelet.conf, run the command:

$ sudo chgrp root /etc/kubernetes/kubelet.conf

Rationale:

The kubelet configuration file contains information about the configuration of the OpenShift node that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_kubelet_conf
Identifiers and References

References:  4.1.6

Rule   Verify Permissions on the Worker Certificate Authority File   [ref]

To properly set the permissions of /etc/kubernetes/kubelet-ca.crt, run the command:

$ sudo chmod 0644 /etc/kubernetes/kubelet-ca.crt

Rationale:

If the worker certificate authority file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the certificate authority certificate for an OpenShift node that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_worker_ca
Identifiers and References

References:  4.1.7

Rule   Verify Permissions on the OpenShift Node Service File   [ref]

To properly set the permissions of /etc/systemd/system/atomic-openshift-node.service, run the command:

$ sudo chmod 0644 /etc/systemd/system/atomic-openshift-node.service

Rationale:

If the /etc/systemd/system/atomic-openshift-node.service file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the service configuration of the OpenShift node service that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_worker_service
Identifiers and References

References:  4.1.1

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

To properly set the permissions of /config/kube-proxy-config.yaml, run the command:

$ sudo chmod 0600 /config/kube-proxy-config.yaml

Rationale:

If the worker proxy kubeconfig file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the administration configuration of the OpenShift cluster that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_proxy_kubeconfig
Identifiers and References

References:  4.1.3

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

To properly set the owner of /var/lib/kubelet/kubeconfig, run the command:

$ sudo chown root /var/lib/kubelet/kubeconfig 

Rationale:

The worker 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.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_worker_kubeconfig
Identifiers and References

References:  4.1.10

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

To properly set the group owner of /config/kube-proxy-config.yaml, run the command:

$ sudo chgrp root /config/kube-proxy-config.yaml

Rationale:

The worker 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.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_proxy_kubeconfig
Identifiers and References

References:  4.1.4

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

To properly set the owner of /config/kube-proxy-config.yaml, run the command:

$ sudo chown root /config/kube-proxy-config.yaml 

Rationale:

The worker 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.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_proxy_kubeconfig
Identifiers and References

References:  4.1.4

Rule   Verify Group Who Owns the Worker Certificate Authority File   [ref]

To properly set the group owner of /etc/kubernetes/kubelet-ca.crt, run the command:

$ sudo chgrp root /etc/kubernetes/kubelet-ca.crt

Rationale:

The worker certificate authority file contains the certificate authority certificate for an OpenShift node that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_worker_ca
Identifiers and References

References:  4.1.8

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

To properly set the group owner of /var/lib/kubelet/kubeconfig, run the command:

$ sudo chgrp root /var/lib/kubelet/kubeconfig

Rationale:

The worker 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.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_worker_kubeconfig
Identifiers and References

References:  4.1.10

Rule   Verify Permissions on the Worker Kubeconfig File   [ref]

To properly set the permissions of /var/lib/kubelet/kubeconfig, run the command:

$ sudo chmod 0600 /var/lib/kubelet/kubeconfig

Rationale:

If the worker kubeconfig file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the administration configuration of the OpenShift cluster that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_worker_kubeconfig
Identifiers and References

References:  4.1.9

Rule   Verify Permissions on The Kubelet Configuration File   [ref]

To properly set the permissions of /etc/kubernetes/kubelet.conf, run the command:

$ sudo chmod 0600 /etc/kubernetes/kubelet.conf

Rationale:

If the kubelet configuration file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the configuration of an OpenShift node that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_kubelet_conf
Identifiers and References

References:  4.1.5

Rule   Verify User Who Owns the Worker Certificate Authority File   [ref]

To properly set the owner of /etc/kubernetes/kubelet-ca.crt, run the command:

$ sudo chown root /etc/kubernetes/kubelet-ca.crt 

Rationale:

The worker certificate authority file contains the certificate authority certificate for an OpenShift node that is configured on the system. Protection of this file is critical for OpenShift security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_worker_ca
Identifiers and References

References:  4.1.8

Group   OpenShift Secrets Management   Group contains 1 rule

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

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

Rule   Drop Container Capabilities   [ref]

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

References:  5.2.9

Rule   Limit Container Running As Root User   [ref]

Containers should be limited to only the privileges required to run and should very rarely be run as root user. To prevent containers from running as root user, 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_root_containers
Identifiers and References

References:  5.2.6

Rule   Limit Use of the CAP_NET_RAW   [ref]

Containers should not enable more capabilites 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:  5.2.7

Rule   Limit Access to the Host IPC Namespace   [ref]

Containers should not be allowed access to the host's Interprocess Commication (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

References:  5.2.3

Rule   Limit Container Capabilities   [ref]

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

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

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

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

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

References:  5.2.5

Group   Role-based Acess Control   Group contains 4 rules

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

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

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

Rule   Limit Access to Cluser Admin   [ref]

The cluster-admin role provides superuser or privilaged access to an OpenShift cluster. As such, it should be limited to a small subset of trusted users. To remove users from the cluster-admin role, run the following command where username is the name of the user to remove:

$ oc adm policy remove-cluster-role-from-user cluster-admin username

Rationale:

The RBAC role cluster-admin provides superuser or privilaged access to an OpenShift cluster. As such, it should be limited to a small subset of trusted users.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_rbac_limit_cluster_admin
Identifiers and References

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

Group   OpenShift etcd Settings   Group contains 9 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, edit the etcd configuration file /etc/etcd/etcd.conf from the master node and set ETCD_AUTO_TLS to false:

ETCD_AUTO_TLS=false

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

References:  2.3

Rule   Enable The Peer Client Certificate Authentication   [ref]

To ensure the etcd service is serving TLS to clients, edit the etcd configuration file /etc/etcd/etcd.conf on the master node and set ETCD_PEER_CLIENT_CERT_AUTH to true.

ETCD_PEER_CLIENT_CERT_AUTH=true

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

References:  2.5

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

To ensure the etcd service is serving TLS to clients, edit the etcd configuration file /etc/etcd/etcd.conf on the master and adding a certificate to ETCD_PEER_CERT_FILE:

ETCD_PEER_CERT_FILE=/etc/ssl/etcd/system:etcd-peer:etcd_dns_name.crt

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

References:  2.4

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

To ensure the etcd service is serving TLS to clients, edit the etcd configuration file /etc/etcd/etcd.conf on the master on the master and adding a key file to ETCD_PEER_KEY_FILE:

ETCD_PEER_KEY_FILE=/etc/ssl/etcd/system:etcd-peer:etcd_dns_name.key

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

References:  2.4

Rule   Disable etcd Peer Self-Signed Certificates   [ref]

To ensure the etcd service is not using self-signed certificates, edit the etcd configuration file /etc/etcd/etcd.conf from the master node and set ETCD_PEER_AUTO_TLS to false:

ETCD_PEER_AUTO_TLS=false

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

References:  2.6

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

To ensure the etcd service is serving TLS to clients, edit the etcd configuration file /etc/etcd/etcd.conf on the master and adding a key file to ETCD_KEY_FILE:

ETCD_CERT_FILE=/etc/ssl/etcd/system:etcd-server:etcd_dns_name.key

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

References:  2.1

Rule   Enable The Client Certificate Authentication   [ref]

To ensure the etcd service is serving TLS to clients, edit the etcd configuration file /etc/etcd/etcd.conf on the master node and set ETCD_CLIENT_CERT_AUTH to true.

ETCD_CLIENT_CERT_AUTH=true

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

References:  2.2

Rule   Configure A Unique CA Certificate for etcd   [ref]

A unique and different CA certificate should be created for etcd. To ensure the etcd service is using a unique certificate, , set ETCD_TRUSTED_CA_FILE to /etc/etcd/ca.crt in /etc/etcd/etcd.conf on the master node that does NOT match the OpenShift CA certificate:

ETCD_TRUSTED_CA_FILE=/etc/ssl/etcd/ca.crt

Rationale:

A unique CA certificate that is utilized by etcd and is different from OpenShift ensures that the etcd data is still protected in the event that the OpenShift certificate is compromised.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_etcd_unique_ca
Identifiers and References

References:  2.7

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

To ensure the etcd service is serving TLS to clients, edit the etcd configuration file /etc/etcd/etcd.conf on the master and adding a certificate to ETCD_CERT_FILE:

ETCD_CERT_FILE=/etc/ssl/etcd/system:etcd-server:etcd_dns_name.crt

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

References:  2.1

Group   Kubernetes Kubelet Settings   Group contains 10 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   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/kubernetes.conf and configure the kubelet private key file.

tlsPrivateKeyFile: /path/to/TLS/private.key

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

References:  4.2.10

Rule   kubelet - Do Not Limit Event Creation   [ref]

All events should be captured and not restricted as this helps in reconstucting the chain-of-events. To prevent log creation limiting, edit the kubelet configuration file /etc/kubernetes/kubernetes.conf on the kubelet node(s) and set the below parameter:

eventRecordQPS: 0

Rationale:

All events should be captured and not restricted as this helps in reconstucting the chain-of-events.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kubelet_configure_event_creation
Identifiers and References

References:  4.2.9

Rule   kubelet - Enable Server Certificate Rotation   [ref]

To enable the kubelet to rotate server certificates, edit the kubelet configuration file /etc/kubernetes/kubernetes.conf on the kubelet node(s) and set the below parameter:

featureGates:
...
  RotateKubeletServerCertificate: true
...

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

References:  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, edit the kubelet configuration file /etc/kubernetes/kubernetes.conf on the kubelet node(s) and set the below parameter:

streamingConnectionIdleTimeout: 5m

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

References:  4.2.4

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/kubernetes.conf on the kubelet node(s) and set the below parameter:

authentication:
...
  x509:
    clientCAFile: /etc/kubernetes/kubelet-ca.crt
...

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

References:  4.2.3

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

To disable the read-only port, edit the kubelet configuration file /etc/kubernetes/kubernetes.conf on the kubelet node(s) and set the below parameter:

readOnlyPort: 0

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

References:  4.2.3

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/kubernetes.conf:

authorization:
  mode: Webhook
  ...

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

References:  4.2.2

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 worker node(s) and set the below parameter:

authentication:
  ...
  anonymous:
    enabled: false
  ...

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

References:  4.2.1

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/kubernetes.conf and configure the kubelet certificate file.

tlsCertFile: /path/to/TLS/cert.key

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

References:  4.2.10

Rule   kubelet - Enable Client Certificate Rotation   [ref]

To enable the kubelet to rotate client certificates, edit the kubelet configuration file /etc/kubernetes/kubernetes.conf on the kubelet node(s) and set the below parameter:

featureGates:
...
  RotateKubeletClientCertificate: true
...

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

References:  4.2.11

Group   OpenShift API Server   Group contains 35 rules

[ref]   This section contains recommendations for kube-apiserver configuration.

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 storageConfig has the ca configured in the openshift-kube-apiserver configmap on the master node(s) to something similar to:

"storageConfig":{
  ...
  "ca":"/etc/kubernetes/static-pod-resources/configmaps/etcd-serving-ca/ca-bundle.crt",
  ...

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

References:  1.2.32

Rule   Enable the ServiceAccount Admission Control Plugin   [ref]

To ensure ServiceAccount objects must be created and granted before pod creation is allowed, follow the documentation and create ServiceAccount objects as per your environment. Then, edit the API Server pod specification file /etc/origin/master/master-config.yaml on the master node(s) set the admissionConfig to include ServiceAccount:

admissionConfig:
  pluginConfig:
    ServiceAccount:
      configuration:
      kind: DefaultAdmissionConfig
      apiVersion: v1
      disable: false

Rationale:

When a pod is created, if a service account is not specified, the pod is automatically assigned the default service account in the same namespace. OpenShift operators should create unique service accounts and let the API Server manage its security tokens.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_ServiceAccount
Identifiers and References

References:  1.2.14

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

To enable certificate based kubelet authentication, follow the OpenShift documentation and setup the TLS connection between the API Server and kubelets. Edit the openshift-kube-apiserver configmap on the master node(s) and set the below parameter if it is not already configured:

"kubeletClientInfo":{
  ...
  "certFile":"/etc/kubernetes/static-pod-resources/secrets/kubelet-client/tls.crt",
  ...

Rationale:

By default the API Server does not authenticate itself to the kublet'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

References:  1.2.5

Rule   Configure the Encryption Provider   [ref]

To encrypt the etcd key-value store, follow the OpenShift documentation and configure a EncryptionConfig file. Then, verify that the openshift-kube-apiserver configmap on the master node(s) and set encryption-provider-config to the path of the EncryptionConfig file.

apiServerArguments:
  encryption-provider-config:
  - /etc/kubernetes/static-pod-resources/secrets/encryption-config/encryption-config

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.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_encryption_provider_config
Identifiers and References

References:  1.2.33

Rule   Enable the NodeRestriction Admission Control Plugin   [ref]

To limit the Node and Pod objects that a kubelet could modify, follow the OpenShift documentation and configure NodeRestriction plugin on kubelets. Then, edit the API Server pod specification file /etc/origin/master/master-config.yaml on the master node(s) and set the admissionConfig to include NodeRestriction:

admissionConfig:
  pluginConfig:
    NodeRestriction:
      configuration:
      kind: DefaultAdmissionConfig
      apiVersion: v1
      disable: false

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

References:  1.2.17

Rule   Enable kubelet HTTPS connections to the API Server   [ref]

By default, the OpenShift API Server runs in HTTPS mode. HTTPS should be used for connections between the API Server and Kubelets. Edit the openshift-kube-apiserver configmap on the master node(s) and remove the kubelet-https parameter if it is set to false:

"apiServerArguments":{
  ...
  "kubelet-https":[
    "false"
  ],
  ...

Rationale:

Connections from the API Server to Kubelets could potentially carry sensitive data such as secrets and keys. It is important to use in-transit encryption for any communication between the API Server and the Kubelets.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_kubelet_https
Identifiers and References

References:  1.2.4

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 on the master node(s) and remove the token-auth-file parameter:

"apiServerArguments":{
  ...
  "token-auth-file":[
    "/path/to/any/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

References:  1.2.3

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 storageConfig has the certFile configured in the openshift-kube-apiserver configmap on the master node(s) to something similar to:

"storageConfig":{
  ...
  "certFile":"/etc/kubernetes/static-pod-resources/secrets/etcd-client/tls.crt",
  ...

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

References:  1.2.29

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 on the master node(s) to something similar to:

"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",
    "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305"
  ],
  ...

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

Rule   Configure the Audit Log Maximum Retention Days (maximumFileRetentionDays)   [ref]

To configure audit log retention, edit the openshift-kube-apiserver configmap on the master node(s) and set the maximumFileRetentionDays parameter to 30 or as appropriate for the number of days:

"auditConfig":{
  ...
  "maximumFileRetentionDays": 30,
  ...

Rationale:

Retaining audit logs for a specified period of time allows OpenShift Operators to retroactively review and correlate events, such as for investigative purposes.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_audit_log_maxage
Identifiers and References

References:  1.2.23

Rule   Disable Anonymous Authentication to the API Server   [ref]

By default, anonymous access to the OpenShift API is enabled. This configuration check ensures that anonymous requests to the OpenShift API server are disabled. Verify the openshift-kube-apiserver configmap on the master node(s) has set the below parameter:

"apiServerArguments":{
  ...
  "anonymous-auth":[
    "false"
  ],
  ...

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. OpenShift Operators should rely on authentication to authorize access and disallow anonymous requests as it allows an attacker to discover information about the system and/or network in use.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_anonymous_auth
Identifiers and References

References:  1.2.1

Rule   Configure the API Server Request Timeout   [ref]

All components that use the API should connect via the secured port, authenticate themselves, and be authorized to use the API. To ensure such a configuration, Edit the openshift-kube-apiserver configmap on the master node(s) and set the request-timeout to 300:

"apiServerArguments":{
  ...
  "request-timeout":[
    "300"
  ],
  ...

Rationale:

Setting global request timout allows extending the API Server request timeout limit to a duration appropriate to the user's connection speed. By default, it is set to 60 seconds which might be problematic on slower connections making cluster resources inaccessible once the data volume for requests exceeds what can be transmitted in 60 seconds. But, setting this timeout limit to be too large can 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 60 seconds only if needed.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_request_timeout
Identifiers and References

References:  1.2.26

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 setting should not exist Edit the openshift-kube-apiserver configmap on the master node(s) and remove the insecure-bind-address if it exists:

"apiServerArguments":{
  ...
  "insecure-port":[
    "1234"
  ],
  ...

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

References:  1.2.19

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

To ensure the API Server utilizes its own TLS certificates, the keyFile must be configured. Verify that servingInfo has the keyFile configured in the openshift-kube-apiserver configmap on the master node(s) to something similar to:

"servingInfo":{
  ...
  "keyFile":"/etc/kubernetes/static-pod-certs/secrets/service-network-serving-certkey/tls.key",
  ...

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

References:  1.2.30

Rule   Configure the Maximum Retained Audit Logs   [ref]

To configure how many rotations of audit logs are retained, edit the openshift-kube-apiserver configmap on the master node(s) and set the maximumRetainedFiles parameter to 10 or to an organizationally appropriate value:

"auditConfig":{
  ...
  "maximumRetainedFiles": 10,
  ...

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

References:  1.2.24

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

To enable certificate based kubelet authentication, follow the OpenShift documentation and setup the TLS connection between the API Server and kubelets. Edit the openshift-kube-apiserver configmap on the master node(s) and set the below parameter if it is not already configured:

"kubeletClientInfo":{
  ...
  "keyFile":"/etc/kubernetes/static-pod-resources/secrets/kubelet-client/tls.key",
  ...

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

References:  1.2.5

Rule   Configure Maximum Audit Log Size   [ref]

To rotate audit logs upon reaching a maximum size, edit the openshift-kube-apiserver configmap on the master node(s) and set the maximumFileSizeMegabytes parameter to an appropriate size in MB. For example, to set it to 100 MB:

"auditConfig":{
  ...
  "maximumFileSizeMegabytes": 100,
  ...

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

References:  1.2.25

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

Basic Authentication should not be used. Follow the OpenShift documentation and configure alternate mechanisms for authentication. If needed, edit API Edit the openshift-kube-apiserver configmap on the master node(s) 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.

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

References:  1.2.2

Rule   Disable the AlwaysAdmit Admission Control Plugin   [ref]

To ensure OpenShift only responses to requests explicitly allowed by the admissions control plugin, edit the API Server pod specification file /etc/kubernetes/static-pod-resources/configmaps/config/config.yaml on the master node(s) and ensure the admissionConfig is not configured to include AlwaysAdmit.

Rationale:

Enabling the admission control plugin AlwaysAdmin 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

References:  1.2.11

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 on the master node(s) and set the below parameter if it is not already configured:

"kubeletClientInfo":{
  ...
  "ca":"/etc/kubernetes/static-pod-resources/configmaps/kubelet-serving-ca/ca-bundle.crt",
  ...

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

References:  1.2.6

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 storageConfig has the keyFile configured in the openshift-kube-apiserver configmap on the master node(s) to something similar to:

"storageConfig":{
  ...
  "keyFile":"/etc/kubernetes/static-pod-resources/secrets/etcd-client/tls.key",
  ...

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

References:  1.2.29

Rule   Ensure API Server authorization-mode is set to Webhook   [ref]

By default, unauthenticated/unauthorized users have no access to OpenShift nodes and the API Server authorization-mode is set to Webhook. To ensure that the API server requires authorization for API requests, validate that authorization-mode is configured to Webhook. Edit the openshift-kube-apiserver configmap on the master node(s) and set the below parameter:

"apiServerArguments":{
  ...
  "authorization-mode":[
    "Webhook"
  ],
  ...

Warning:  If authorization-mode is not configured to Webhook, the node systemd service (atomic-openshift-node) will not start.
Rationale:

Ensuring authorization-mode is set to Webhook helps enforce that unauthenticated/unauthorized users have no access to OpenShift nodes.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_authorization_mode
Identifiers and References

References:  1.2.7, 1.2.8, 1.2.9

Rule   Configure the Encryption Provider Cipher   [ref]

To configure OpenShift to use the aescbc encryption provider, follow the OpenShift documentation to create or modify an EncryptionConfig file. In this file, choose aescbc as the encryption provider:

kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
    - secrets
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: 32-byte base64-encoded secret

Rationale:

aescbc is currently the strongest encryption provider, it should be preferred over other providers.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_encryption_provider_cipher
Identifiers and References

References:  1.2.34

Rule   Enable the PodSecurityPolicy Admission Control Plugin   [ref]

To reject pods that do not match Pod Security Policies, follow the OpenShift documentation and create Pod Security Policy objects as per your environment. Then, edit the API Server pod specification file /etc/origin/master/master-config.yaml on the master node(s) and set the admissionConfig to include PodSecurityPolicy:

admissionConfig:
  pluginConfig:
    PodSecurityPolicy:
      configuration:
      kind: DefaultAdmissionConfig
      apiVersion: v1
      disable: false
Once configured, the API Server service will need to be restarted.

Warning:  When the PodSecurityPolicy admission plugin is in use, there needs to be at least one PodSecurityPolicy in place for ANY pods to be admitted.
Rationale:

A Pod Security Policy is a cluster-level resource that controls the actions which a pod can perform and what the pod may access. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies 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_PodSecurityPolicy
Identifiers and References

References:  1.2.16

Rule   Enable the EventRateLimit Admission Control Plugin   [ref]

To limit the rate at which the API Server accepts requests, follow the OpenShift documentation and set the desired limits in a configuration file. Then, edit the API Server pod specification file /etc/origin/master/master-config.yaml and set the admissionConfig to include DenyEscalatingExec:

admissionConfig:
  pluginConfig:
    EventRateLimit:
      configuration:
      kind: DefaultAdmissionConfig
      apiVersion: v1
      disable: false

Rationale:

Using EventRateLimit admission control enforces 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_admission_control_plugin_EventRateLimit
Identifiers and References

References:  1.2.10

Rule   Configure the Audit Log Path   [ref]

To enable auditing on the OpenShift API Server, the audit log path must be set. Edit the API Server pod specification file Edit the openshift-kube-apiserver configmap on the master node(s) and set the audit-log-path to a suitable path and file where audit logs should be written. For example:

"auditConfig":{
  ...
  "auditFilePath":"/var/log/kube-apiserver/audit.log",
  ...

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

References:  1.2.22

Rule   Enable the SecurityContextDeny Admission Control Plugin   [ref]

Instead of using a customized SecurityContext for pods, a Pod Security Policy (PSP) should be used. PSP is a cluster-level resource that controls the actions that a pod can perform and what resource the pod may access. The SecurityContextDeny admission control policy enables PSP. To configure OpenShift to use PSP, edit the API Server pod specification file /etc/origin/master/master-config.yaml on the master node(s) and set the admissionConfig to include SecurityContextDeny:

admissionConfig:
  pluginConfig:
    SecurityContextDeny:
      configuration:
      kind: DefaultAdmissionConfig
      apiVersion: v1
      disable: false

Rationale:

Setting admission control policy to SecurityContextDeny denies the pod level SecurityContext customization. Any attempts to customize the SecurityContext that are not explicitly defined in the Pod Security Policy (PSP) are blocked. This ensures that all pods adhere to the PSP defined by your organization and you have a uniform pod level security posture.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_SecurityContextDeny
Identifiers and References

References:  1.2.13

Rule   Disable Profiling on the API server   [ref]

To disable profiling, edit the openshift-kube-apiserver configmap on the master node(s) and set profiling to false:

"schedulerArguments":{
  ...
  "profiling":[
    "false"
  ],
  ...

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 the profiler is not needed for troubleshooting purposes, it is recommended to turn off for reduction of potential attack surface.

Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_api_server_profiling
Identifiers and References

References:  1.2.21

Rule   Enable the NamespaceLifecyle Admission Control Plugin   [ref]

To enable NamespaceLifecycle, edit the API Server pod specification file /etc/origin/master/master-config.yaml on the master node(s) and set the admissionConfig to include NamespaceLifecyle:

admissionConfig:
  pluginConfig:
    NamespaceLifecyle:
      configuration:
      kind: DefaultAdmissionConfig
      apiVersion: v1
      disable: false

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

References:  1.2.15

Rule   Disable Use of the Insecure Bind Address   [ref]

OpenShift should not bind to non-loopback insecure addresses. Edit the openshift-kube-apiserver configmap on the master node(s) and remove the insecure-bind-address if it exists:

"apiServerArguments":{
  ...
  "insecure-bind-address":[
    "127.0.0.1"
  ],
  ...

Rationale:

If the API Server is bound to an insecure address the installation would be susceptible to unauthented 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

References:  1.2.18

Rule   Enable the AlwaysPullImages Admission Control Plugin   [ref]

To ensure credentials are required to pull images, edit the API Server pod specification file /etc/origin/master/master-config.yaml on the master node(s) and set the admissionConfig to include AlwaysPullImages:

admissionConfig:
  pluginConfig:
    AlwaysPullImages:
      configuration:
      kind: DefaultAdmissionConfig
      apiVersion: v1
      disable: false

Rationale:

Setting admission control policy to include AlwaysPullImages forces every new pod to pull the required images during every build. In a multi-tenant cluster users can be assured that 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 access control lists). When this plugin is enabled, images are always pulled prior to starting containers and forces authorization.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_AlwaysPullImages
Identifiers and References

References:  1.2.12

Rule   Enable the Secure Port for the API Server   [ref]

To ensure traffic is served over HTTPS, edit the openshift-kube-apiserver configmap on the master node(s) and either remove the secure-port or set it to a different (non-zero) desired port.

"apiServerArguments":{
  ...
  "secure-port":[
    "8443"
  ],
  ...

Rationale:

The secure port is used to serve HTTPS with authentication and authorization. If secure-port is disabled, as indicated with a value of 0, HTTPS traffic will not be served and all traffic will be unencrypted.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_api_server_secure_port
Identifiers and References

References:  1.2.20

Rule   Configure the Certificate for the API Server   [ref]

To ensure the API Server utilizes its own TLS certificates, the certFile must be configured. Verify that servingInfo has the certFile configured in the openshift-kube-apiserver configmap on the master node(s) to something similar to:

"servingInfo":{
  ...
  "certFile":"/etc/kubernetes/static-pod-certs/secrets/service-network-serving-certkey/tls.crt",
  ...

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

References:  1.2.30

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 configmap on the master node(s) to something similar to:

"servingInfo":{
  ...
  "clientCA":"/etc/kubernetes/static-pod-certs/configmaps/client-ca/ca-bundle.crt",
  ...

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

References:  1.2.31

Group   OpenShift - Kubernetes - Scheduler Settings   Group contains 1 rule

[ref]   Contains evaluations for kube-scheduler configuration settings.

Rule   Disable Scheduler Profiling   [ref]

Profiling should be disabled if not needed. To disable profiling, edit the Scheduler pod specification file /etc/origin/master/master-config.yaml file on the master node and set the below parameter:

kubernetesMasterConfig:
  schedulerArguments:
    profiling:
    - false

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.

Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_scheduler_profiling_argument
Identifiers and References

References:  1.4.1

Group   OpenShift Controller Settings   Group contains 5 rules

[ref]   This section contains recommendations for the kube-controller-manager configuration

Rule   Ensure that the RotateKubeletServerCertificate argument is set   [ref]

To enforce kublet 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 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

References:  1.3.6

Rule   Ensure Controller bind-address argument is set   [ref]

To ensure the Controller Manager service is bound to secure loopback address, set the RotateKubeletServerCertificate option to true in the openshift-kube-controller-manager configmap on the master node(s):

"extendedArguments": {
...
  "bind-address": [
    "127.0.0.1",
  ],
...

Warning:  The associated value must be reachable by the rest of the cluster, and by CLI/web clients. If blank all interfaces will be used (0.0.0.0 for IPv4 and ``::`` for IPv6).
Rationale:

The Controller Manager API service (which runs on a port specified by the secure-port argument) 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_bind_address
Identifiers and References

References:  1.3.7

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.