Group
Guide to the Secure Configuration of Red Hat OpenShift Container Platform 3
Group contains 8 groups and 109 rules |
Group
OpenShift Settings
Group contains 7 groups and 109 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 Controller Settings
Group contains 5 rules |
[ref]
This section contains recommendations for the kube-controller-manager configuration |
Rule
Ensure that the --use-service-account-credentials argument is set
[ref] | To ensure individual service account credentials are used,
edit the Controller Manager pod specification file
/etc/origin/master/master-config.yaml on the
master node(s) and set the use-service-account-credentials option,
under the controllerArguments stanza, to true . For example:
kubernetesMasterConfig:
controllerArguments:
use-service-account-credentials:
- true | Rationale: | The controller manager creates a service account per controller in
kube-system namespace, generates an API token and credentials for it,
then builds a dedicated API client with that service account credential
for each controller loop to use. Setting the
use-service-account-credentials to true runs each
control loop within the contoller manager using a separate service
account credential. When used in combination with RBAC, this ensures
that the control loops run with the minimum permissions required to
perform their intended tasks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_controller_use_service_account | Identifiers and References | Identifiers:
CCE-80593-7 References:
1.3.3 | |
|
Rule
Ensure Controller bind-address argument is set
[ref] | To ensure the Controller Manager service is bound to secure loopback
address,
edit the Controller Manager pod specification file
/etc/origin/master/master-config.yaml on the
master node(s) and ensure the correct value for the bind-address
parameter. For example:
kubernetesMasterConfig:
controllerArguments:
bind-address:
- '192.168.1.101' 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 | Identifiers:
CCE-80587-9 References:
1.3.7 | |
|
Rule
Disable Profiling for the Controller Manager
[ref] | Profiling endpoints are exposed at each master port and secured via Role-Based
Access Control (RBAC). By default profiling is accessible only to users bound to
cluster-admin or cluster-debugger roles, limiting access to authorized
users only.
Should OPENSHIFT_PROFILE be set to web , reflecting a change from
the secure defaults, this profiling data will be exposed via a web interface on the
systems localhost interface.
To ensure profiling data is not exposed over a web interface, ensure
To ensure profiling data is not exposed over a web interface, ensure
OPENSHIFT_PROFILE is not set to web in /etc/origin/master/master.env . | Rationale: | Profiling data may include sensitive system information which could be exploited. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_controller_disable_profiling | Identifiers and References | Identifiers:
CCE-83000-0 References:
1.3.2 | |
|
Rule
Ensure that the RotateKubeletServerCertificate argument is set
[ref] | To enforce kublet server certificate rotation on the Controller Manager,
edit the Controller Manager pod specification file
/etc/origin/master/master-config.yaml on the
master node(s) and set the controllerArguments parameter to include
RotateKubeletServerCertificate=true . For example:
kubernetesMasterConfig:
controllerArguments:
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 | Identifiers:
CCE-80590-3 References:
1.3.6 | |
|
Rule
Enable terminated-pod-gc-threshold for the Controller Manager
[ref] | To ensure the garbage collector is activated upon pod termination,
edit the Controller Manager pod specification file
/etc/origin/master/master-config.yaml on the
master node(s) and set the terminated-pod-gc-threshold to
true . For example:
kubernetesMasterConfig:
controllerArguments:
terminated-pod-gc-threshold:
- true | Rationale: | Garbage collection is important to ensure sufficient resource availability
and avoiding degraded performance and availability. In the worst case,
the system might crash or just be unusable for a long period of time. The
default setting for garbage collection is 12,500 terminated pods which
might be to high for your system to sustain. Based on your system resources
and tests, choose an appropriate threshold value to activate garbage
collection. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_controller_terminated_pod_gc_threshhold | Identifiers and References | Identifiers:
CCE-80592-9 References:
1.3.1 | |
|
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 | Identifiers:
CCE-80609-1 References:
1.4.1 | |
|
Group
Kubernetes Kubelet Settings
Group contains 11 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
kubelet - Enable Server Certificate Rotation
[ref] | To enable the kubelet to rotate server certificates, edit the kubelet configuration
file /etc/origin/node/node-config.yaml
on the kubelet node(s) and ensure RotateKubeletServerCertificate is included
in the feature-gates arguments:
kubeletArguments:
feature-gates:
- RotateKubeletClientCertificate=true,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 | Identifiers:
CCE-80606-7 References:
1.3.7 | |
|
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/origin/node/node-config.yaml
and configure the cert-dir path for the kubelet certificates.
For example:
cert-dir:
- /etc/origin/node/certificates
A corresponding certificate should exist in the cert-dir . For
example:
/etc/origin/node/certificates/kubelet-client-current.pem | Rationale: | Without cryptographic integrity protections, information can be
altered by unauthorized users without detection. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kubelet_configure_tls_cert | Identifiers and References | Identifiers:
CCE-80596-0 References:
2.1.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/origin/node/node-config.yaml
on the kubelet node(s) and set the below parameter:
kubeletArguments:
streaming-connection-idle-timeout:
- '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 | Identifiers:
CCE-80607-5 References:
2.1.6 | |
|
Rule
kubelet - Allow Automatic Firewall Configuration
[ref] | The kubelet has the ability to automatically configure the firewall to allow
the containers required ports and connections to networking resources and destinations
parameters potentially creating a security incident.
To allow the kubelet to modify the firewall, edit the kubelet configuration
file /etc/origin/node/node-config.yaml
on the kubelet node(s) and set the below parameter:
kubeletArguments:
make-iptables-util-chains:
- 'true' Warning:
IT IS NOT RECOMMENDED FOR ANY REASON to manually configure firewall ports for running
pods and containers as this not only can create conflicts with firewall rules but can
also introduce inconsistences into the allowed/disabled ports on the firewall. | Rationale: | The kubelet should automatically configure the firewall settings to allow access and
networking traffic through. This ensures that when a pod or container is running that
the correct ports are configured as well as removing the ports when a pod or
container is no longer in existence. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kubelet_enable_iptables_util_chains | Identifiers and References | Identifiers:
CCE-80604-2 References:
2.1.8 | |
|
Rule
kubelet - Disable cAdvisor Port
[ref] | The cAdvisor port should be disabled as it does not require
any authentication to connect to the port.
To disable the cAdvisor port, edit the kubelet configuration
file /etc/origin/node/node-config.yaml
on the kubelet node(s) and set the below parameter:
kubeletArguments:
cadvisor-port:
- '0' | Rationale: | Any form of authentication to ports anonymously should be disabled. An attacker
could connect to the port and gain cluster information anonymously. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_kubelet_disable_cadvisor_port | Identifiers and References | Identifiers:
CCE-80599-4 References:
2.1.13 | |
|
Rule
kubelet - Enable Client Certificate Rotation
[ref] | To enable the kubelet to rotate client certificates, edit the kubelet configuration
file /etc/origin/node/node-config.yaml
on the kubelet node(s) and set the below parameter:
kubeletArguments:
feature-gates:
- 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 | Identifiers:
CCE-80603-4 References:
2.1.14 | |
|
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/origin/node/node-config.yaml
on the kubelet node(s) and set the below parameter:
kubeletArguments:
event-qps:
- '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 | Identifiers:
CCE-80595-2 References:
2.1.11 | |
|
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/origin/node/node-config.yaml
on the kubelet node(s) and set the below parameter:
servingInfo:
clientCA: client-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 | Identifiers:
CCE-80594-5 References:
2.1.4 | |
|
Rule
kubelet - Disable Hostname Override
[ref] | To prevent the hostname from being overrided, edit the kubelet configuration file
/etc/origin/node/node-config.yaml on the kubelet node(s) and
remove the hostname-override option if it exists. | Rationale: | Allowing hostnames to be overrided creates issues around resolving nodes
in addition to TLS configuration, certificate validation, and log correlation
and validation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kubelet_disable_hostname_override | Identifiers and References | Identifiers:
CCE-80600-0 References:
2.1.10 | |
|
Rule
kubelet - Disable the Read-Only Port
[ref] | To disable the read-only port, edit the kubelet configuration
file /etc/origin/node/node-config.yaml
on the kubelet node(s) and set the below parameter:
kubeletArguments:
read-only-port:
- '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 | Identifiers:
CCE-80601-8 References:
2.1.5 | |
|
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/origin/node/node-config.yaml
and configure the cert-dir path for the kubelet certificates.
For example:
cert-dir:
- /etc/origin/node/certificates
A corresponding certificate should exist in the cert-dir . For
example:
/etc/origin/node/certificates/kubelet-server-current.pem | Rationale: | Without cryptographic integrity protections, information can be
altered by unauthorized users without detection. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kubelet_configure_tls_key | Identifiers and References | Identifiers:
CCE-80597-8 References:
2.1.12 | |
|
Group
Permissions
Group contains 1 group and 42 rules |
[ref]
Traditional security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access. |
Group
Verify Permissions on Important Files and
Directories
Group contains 42 rules |
[ref]
Permissions for many files on a system must be set
restrictively to ensure sensitive information is properly protected.
This section discusses important
permission restrictions which can be verified
to ensure that no harmful discrepancies have
arisen. |
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_master_cni_conf | Identifiers and References | Identifiers:
CCE-80611-7 References:
1.4.10 | |
|
Rule
Verify Permissions on the OpenShift Admin Kubeconfig File
[ref] |
To properly set the permissions of /etc/origin/master/admin.kubeconfig , run the command:
$ sudo chmod 0600 /etc/origin/master/admin.kubeconfig | Rationale: | If the /etc/origin/master/admin.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_master_admin_conf | Identifiers and References | Identifiers:
CCE-80633-1 References:
1.4.13 | |
|
Rule
Verify User Who Owns The OpenShift Scheduler Configuration File
[ref] | To properly set the owner of /etc/origin/master/scheduler.json , run the command: $ sudo chown root /etc/origin/master/scheduler.json | Rationale: | The /etc/origin/master/scheduler.json 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_master_scheduler_conf | Identifiers and References | Identifiers:
CCE-80628-1 References:
1.4.16 | |
|
Rule
Verify User Who Owns The OpenShift API Specification File
[ref] | To properly set the owner of /etc/origin/node/pods/apiserver.yaml , run the command: $ sudo chown root /etc/origin/node/pods/apiserver.yaml | Rationale: | The /etc/origin/node/pods/apiserver.yaml 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_master_api_server | Identifiers and References | Identifiers:
CCE-82058-9 References:
1.4.2 | |
|
Rule
Verify Group Who Owns The OpenShift Controller Manager Specification File
[ref] | To properly set the group owner of /etc/origin/node/pods/controller.yaml , run the command: $ sudo chgrp root /etc/origin/node/pods/controller.yaml | Rationale: | The /etc/origin/node/pods/controller.yaml 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_master_controller_manager | Identifiers and References | Identifiers:
CCE-80612-5 References:
1.4.4, 1.4.6 | |
|
Rule
Verify Group Who Owns The OpenShift Node Configuration File
[ref] | To properly set the group owner of /etc/origin/node/node-config.yaml , run the command: $ sudo chgrp root /etc/origin/node/node-config.yaml | Rationale: | The /etc/origin/node/node-config.yaml 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_node_config | Identifiers and References | Identifiers:
CCE-80617-4 References:
2.2.2 | |
|
Rule
Verify User Who Owns OpenShift Node Certificate File
[ref] | To properly set the owner of /etc/origin/node/client-ca.crt , run the command: $ sudo chown root /etc/origin/node/client-ca.crt | Rationale: | The /etc/origin/node/client-ca.crt 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_openshift_node_client_crt | Identifiers and References | Identifiers:
CCE-80631-5 References:
2.2.8 | |
|
Rule
Verify User Who Owns The OpenShift Node Configuration File
[ref] | To properly set the owner of /etc/origin/node/node-config.yaml , run the command: $ sudo chown root /etc/origin/node/node-config.yaml | Rationale: | The /etc/origin/node/node-config.yaml 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_node_config | Identifiers and References | Identifiers:
CCE-80629-9 References:
2.2.2 | |
|
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.4.12 | |
|
Rule
Verify Group Who Owns The OpenShift etcd Data Directory
[ref] | To properly set the group owner of /var/lib/etcd , run the command: $ sudo chgrp 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_groupowner_var_lib_etcd | Identifiers and References | Identifiers:
CCE-80621-6 References:
1.4.12 | |
|
Rule
Verify User Who Owns The OpenShift Configuration Directory
[ref] | To properly set the owner of /etc/origin/ , run the command: $ sudo chown root /etc/origin/ | Rationale: | If users can modify the OpenShift configurations, the OpenShift cluster can become inoperable or compromised | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_origin | Identifiers and References | | |
|
Rule
Verify User Who Owns The OpenShift etcd Specification File
[ref] | To properly set the owner of /etc/origin/node/pods/etcd.yaml , run the command: $ sudo chown root /etc/origin/node/pods/etcd.yaml | Rationale: | The /etc/origin/node/pods/etcd.yaml file contains information about the configuration of the
OpenShift etcd 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_master_etcd | Identifiers and References | Identifiers:
CCE-80625-7 References:
1.4.8 | |
|
Rule
Verify User Who Owns The OpenShift Admin Kubeconfig File
[ref] | To properly set the owner of /etc/origin/master/admin.kubeconfig , run the command: $ sudo chown root /etc/origin/master/admin.kubeconfig | Rationale: | The /etc/origin/master/admin.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_master_admin_conf | Identifiers and References | Identifiers:
CCE-80622-4 References:
1.4.14 | |
|
Rule
Verify Group Who Owns The OpenShift Open vSwitch Files
[ref] | To properly set the group owner of /etc/origin/openvswitch/* , run the command: $ sudo chgrp root /etc/origin/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_master_openvswitch | Identifiers and References | Identifiers:
CCE-82172-8 References:
1.4.10 | |
|
Rule
Verify User Who Owns The OpenShift Controller Manager Specification File
[ref] | To properly set the owner of /etc/origin/node/pods/controller.yaml , run the command: $ sudo chown root /etc/origin/node/pods/controller.yaml | Rationale: | The /etc/origin/node/pods/controller.yaml 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_master_controller_manager | Identifiers and References | Identifiers:
CCE-80624-0 References:
1.4.4, 1.4.6 | |
|
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_openshift_node_service | Identifiers and References | Identifiers:
CCE-80632-3 References:
2.2.4 | |
|
Rule
Verify User Who Owns The OpenShift Master Kubeconfig File
[ref] | To properly set the owner of /etc/origin/master/openshift-master.kubeconfig , run the command: $ sudo chown root /etc/origin/master/openshift-master.kubeconfig | Rationale: | The /etc/origin/master/openshift-master.kubeconfig file contains information about the master 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_master_openshift_kubeconfig | Identifiers and References | Identifiers:
CCE-80627-3 References:
1.4.18 | |
|
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_openshift_node_service | Identifiers and References | Identifiers:
CCE-80620-8 References:
2.2.4 | |
|
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_master_cni_conf | Identifiers and References | Identifiers:
CCE-80623-2 References:
1.4.10 | |
|
Rule
Verify User Who Owns The OpenShift Open vSwitch Files
[ref] | To properly set the owner of /etc/origin/openvswitch/* , run the command: $ sudo chown root /etc/origin/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_master_openvswitch | Identifiers and References | Identifiers:
CCE-82171-0 References:
1.4.10 | |
|
Rule
Verify Group Who Owns The OpenShift Master Kubeconfig File
[ref] | To properly set the group owner of /etc/origin/master/openshift-master.kubeconfig , run the command: $ sudo chgrp root /etc/origin/master/openshift-master.kubeconfig | Rationale: | The /etc/origin/master/openshift-master.kubeconfig file contains information about the master 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_master_openshift_kubeconfig | Identifiers and References | Identifiers:
CCE-80615-8 References:
1.4.18 | |
|
Rule
Verify Permissions on the OpenShift Master Configuration File
[ref] |
To properly set the permissions of /etc/origin/master/master-config.yaml , run the command:
$ sudo chmod 0600 /etc/origin/master/master-config.yaml | Rationale: | If the /etc/origin/master/master-config.yaml file is writable by a group-owner or the
world the risk of its compromise is increased. The file contains the master configuration of
an 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_master_openshift_conf | Identifiers and References | Identifiers:
CCE-80637-2 References:
1.4.17 | |
|
Rule
Verify Permissions on the OpenShift Master Kubeconfig File
[ref] |
To properly set the permissions of /etc/origin/master/openshift-master.kubeconfig , run the command:
$ sudo chmod 0600 /etc/origin/master/openshift-master.kubeconfig | Rationale: | If the /etc/origin/master/openshift-master.kubeconfig file is writable by a group-owner or the
world the risk of its compromise is increased. The file contains the master configuration of
an 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_master_openshift_kubeconfig | Identifiers and References | Identifiers:
CCE-80638-0 References:
1.4.17 | |
|
Rule
Verify Permissions on the OpenShift etcd Specification File
[ref] |
To properly set the permissions of /etc/origin/node/pods/etcd.yaml , run the command:
$ sudo chmod 0600 /etc/origin/node/pods/etcd.yaml | Rationale: | If the /etc/origin/node/pods/etcd.yaml 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 etcd 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_master_etcd | Identifiers and References | Identifiers:
CCE-80636-4 References:
1.4.7 | |
|
Rule
Verify Group Who Owns The OpenShift Configuration Directory
[ref] | To properly set the group owner of /etc/origin/ , run the command: $ sudo chgrp root /etc/origin/ | Rationale: | If users can modify the OpenShift configurations, the OpenShift cluster can become inoperable or compromised | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_origin | Identifiers and References | | |
|
Rule
The OpenShift Configuration Directory Must Have Mode 0700
[ref] |
To properly set the permissions of /etc/origin/ , run the command:
$ sudo chmod 0700 /etc/origin/ | Rationale: | If users can modify the OpenShift configurations, the OpenShift cluster can become inoperable or compromised | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_origin | Identifiers and References | | |
|
Rule
Verify Group Who Owns The OpenShift Scheduler Configuration File
[ref] | To properly set the group owner of /etc/origin/master/scheduler.json , run the command: $ sudo chgrp root /etc/origin/master/scheduler.json | Rationale: | The /etc/origin/master/scheduler.json 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_master_scheduler_conf | Identifiers and References | Identifiers:
CCE-80616-6 References:
1.4.16 | |
|
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_master_cni_conf | Identifiers and References | Identifiers:
CCE-80634-9 References:
1.4.9 | |
|
Rule
Verify User Who Owns The OpenShift Master Configuration File
[ref] | To properly set the owner of /etc/origin/master/master-config.yaml , run the command: $ sudo chown root /etc/origin/master/master-config.yaml | Rationale: | The /etc/origin/master/master-config.yaml file contains information about the master 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_master_openshift_conf | Identifiers and References | Identifiers:
CCE-80626-5 References:
1.4.18 | |
|
Rule
Verify Permissions on OpenShift Node Certificate File
[ref] |
To properly set the permissions of /etc/origin/node/client-ca.crt , run the command:
$ sudo chmod 0644 /etc/origin/node/client-ca.crt | Rationale: | If the /etc/origin/node/client-ca.crt 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_openshift_node_client_crt | Identifiers and References | Identifiers:
CCE-80642-2 References:
2.2. | |
|
Rule
Verify Group Who Owns The OpenShift API Specification File
[ref] | To properly set the group owner of /etc/origin/node/pods/apiserver.yaml , run the command: $ sudo chgrp root /etc/origin/node/pods/apiserver.yaml | Rationale: | The /etc/origin/node/pods/apiserver.yaml 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_master_api_server | Identifiers and References | Identifiers:
CCE-80576-2 References:
1.4.2 | |
|
Rule
Verify Group Who Owns The OpenShift etcd Specification File
[ref] | To properly set the group owner of /etc/origin/node/pods/etcd.yaml , run the command: $ sudo chgrp root /etc/origin/node/pods/etcd.yaml | Rationale: | The /etc/origin/node/pods/apiserver.yaml file contains information about the configuration of the
OpenShift etcd 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_master_etcd | Identifiers and References | Identifiers:
CCE-80613-3 References:
1.4.2 | |
|
Rule
Verify Permissions on the OpenShift Controller Manager Specification File
[ref] |
To properly set the permissions of /etc/origin/node/pods/controller.yaml , run the command:
$ sudo chmod 0600 /etc/origin/node/pods/controller.yaml | Rationale: | If the /etc/origin/node/pods/controller.yaml 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_master_controller_manager | Identifiers and References | Identifiers:
CCE-80635-6 References:
1.4.3, 1.4.5 | |
|
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_openshift_node_service | Identifiers and References | Identifiers:
CCE-80643-0 References:
2.2.3 | |
|
Rule
Verify Group Who Owns The OpenShift Admin Kubeconfig File
[ref] | To properly set the group owner of /etc/origin/master/admin.kubeconfig , run the command: $ sudo chgrp root /etc/origin/master/admin.kubeconfig | Rationale: | The /etc/origin/master/admin.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_master_admin_conf | Identifiers and References | Identifiers:
CCE-80610-9 References:
1.4.14 | |
|
Rule
Verify Permissions on the OpenShift API Specification File
[ref] |
To properly set the permissions of /etc/origin/node/pods/apiserver.yaml , run the command:
$ sudo chmod 0600 /etc/origin/node/pods/apiserver.yaml | Rationale: | If the /etc/origin/node/pods/apiserver.yaml 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_master_api_server | Identifiers and References | Identifiers:
CCE-80574-7 References:
1.4.1 | |
|
Rule
Verify Group Who Owns OpenShift Node Certificate File
[ref] | To properly set the group owner of /etc/origin/node/client-ca.crt , run the command: $ sudo chgrp root /etc/origin/node/client-ca.crt | Rationale: | The /etc/origin/node/client-ca.crt 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_openshift_node_client_crt | Identifiers and References | Identifiers:
CCE-80619-0 References:
2.2.8 | |
|
Rule
Verify Permissions on the OpenShift Node Configuration File
[ref] |
To properly set the permissions of /etc/origin/node/node-config.yaml , run the command:
$ sudo chmod 0600 /etc/origin/node/node-config.yaml | Rationale: | If the /etc/origin/node/node-config.yaml 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_node_config | Identifiers and References | Identifiers:
CCE-80640-6 References:
2.2.1 | |
|
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.4.11 | |
|
Rule
Verify Permissions on the OpenShift Scheduler Configuration File
[ref] |
To properly set the permissions of /etc/origin/master/scheduler.json , run the command:
$ sudo chmod 0600 /etc/origin/master/scheduler.json | Rationale: | If the /etc/origin/master/scheduler.json 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_master_scheduler_conf | Identifiers and References | Identifiers:
CCE-80639-8 References:
1.4.15 | |
|
Rule
Verify Group Who Owns The OpenShift Master Configuration File
[ref] | To properly set the group owner of /etc/origin/master/master-config.yaml , run the command: $ sudo chgrp root /etc/origin/master/master-config.yaml | Rationale: | The /etc/origin/master/master-config.yaml file contains information about the master 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_master_openshift_conf | Identifiers and References | Identifiers:
CCE-80614-1 References:
1.4.18 | |
|
Rule
Verify Permissions on the OpenShift Open vSwitch Files
[ref] |
To properly set the permissions of /etc/origin/openvswitch/* , run the command:
$ sudo chmod 0644 /etc/origin/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_master_openvswitch | Identifiers and References | Identifiers:
CCE-82173-6 References:
1.4.9 | |
|
Group
OpenShift etcd Settings
Group contains 11 rules |
[ref]
Contains rules that check correct OpenShift etcd settings. |
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 | Identifiers:
CCE-80579-6 References:
2.2 | |
|
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 | Identifiers:
CCE-80573-9 References:
2.3 | |
|
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/etcd/peer.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 | Identifiers:
CCE-80580-4 References:
2.4 | |
|
Rule
Disable etcd Auto Log Rotation
[ref] | To ensure the etcd service is not auto-rotating logs,
edit the etcd configuration file
/etc/etcd/etcd.conf on the master node and set
ETCD_MAX_WALS to 0 :
ETCD_MAX_WALS=0 | Rationale: | Ensure data integrity by preventing logs from being overwritten which
allows reconstructing events should the data be compromised. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_etcd_max_wals | Identifiers and References | Identifiers:
CCE-80584-6 References:
1.5.8 | |
|
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 | Identifiers:
CCE-80583-8 References:
2.6 | |
|
Rule
Configure etcd Log Storage
[ref] | To ensure the etcd service is storing logs separate
from data, set
ETCD_WAL_DIR to /var/lib/etcd/member/wal
in /etc/etcd/etcd.conf on the master node:
ETCD_WAL_DIR=/var/lib/etcd/member/wal | Rationale: | etcd log files should be stored in a separate location from the etcd data.
This not only ensures data integrity but also helps to prevent IO degradation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_etcd_wal_dir | Identifiers and References | Identifiers:
CCE-80586-1 | |
|
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 | Identifiers:
CCE-80582-0 References:
2.5 | |
|
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/etcd/server.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 | Identifiers:
CCE-80578-8 References:
2.1 | |
|
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/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 | Identifiers:
CCE-80585-3 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/etcd/server.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 | Identifiers:
CCE-80577-0 References:
2.1 | |
|
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/etcd/peer.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 | Identifiers:
CCE-80581-2 References:
2.4 | |
|
Group
OpenShift API Server
Group contains 39 rules |
[ref]
This section contains recommendations for kube-apiserver configuration. |
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
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 API Server pod specification file /etc/origin/master/master-config.yaml
on the master node(s) and remove the kubelet-https parameter. This will ensure communications
are encrypted using TLS (the default setting).
kubernetesMasterConfig:
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
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 at /etc/origin/master/encryption-config.yaml .
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_experimental_encryption_provider_cipher | Identifiers and References | References:
1.1.34 | |
|
Rule
Enable the DenyEscalatingExec Admission Control Plugin
[ref] | By default, DenyEscalatingExec is not enabled, which allows
privileged pods to execute exec and attach commands.
To disable this capability, edit the API Server pod specification file
/etc/origin/master/master-config.yaml on the master node(s) and
set the admissionConfig to include DenyEscalatingExec :
admissionConfig:
pluginConfig:
DenyEscalatingExec:
configuration:
kind: DefaultAdmissionConfig
apiVersion: v1
disable: false | Rationale: | Setting admission control policy to include DenyEscalatingExec
denies exec and attach commands to pods that run with
escalated privileges that allow host access. This includes pods that run as
privileged, have access to the host IPC namespace, and have access to the host
PID namespace. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_admission_control_plugin_DenyEscalatingExec | Identifiers and References | References:
1.1.2 | |
|
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 API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) and set the request-timeout to 300 :
kubernetesMasterConfig:
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
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
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 API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
servingInfo:
clientCA: ca.crt
certFile: master.server.crt
keyFile: master.server.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_cert | Identifiers and References | References:
1.2.30 | |
|
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 /etc/origin/master/master-config.yaml file on the master node(s)
and set the below parameter:
kubernetesMasterConfig:
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 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.
Ensure that kubeletClientInfo has the keyFile configured in
the API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
kubeletClientInfo:
ca: ca-bundle.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.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 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 API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
servingInfo:
clientCA: ca.crt
certFile: master.server.crt
keyFile: master.server.key | Rationale: | API Server communication contains sensitive parameters that should remain
encrypted in transit. Configure the API Server to serve only HTTPS traffic.
If -clientCA is set, any request presenting a client
certificate signed by one of the authorities in the client-ca-file
is authenticated with an identity corresponding to the CommonName of
the client certificate. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_client_ca | Identifiers and References | Identifiers:
CCE-81152-1 References:
1.2.31 | |
|
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
server pod specification file /etc/origin/master/master-config.yaml
on the master node and remove the basic-auth-file parameter.
kubernetesMasterConfig:
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
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 etcdClientInfo has the ca configured in
the API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
etcdClientInfo:
ca: master.etcd-ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.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
Configure the Encryption Provider
[ref] | To encrypt the etcd key-value store, follow the OpenShift documentation
and configure a EncryptionConfig file. Then, edit the API Server
pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) and set experimental-encryption-provider-config
to the path of that file:
kubernetesMasterConfig:
apiServerArguments:
experimental-encryption-provider-config:
- /etc/origin/master/encryption-config.yaml | 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_experimental_encryption_provider_config | Identifiers and References | References:
1.1.33 | |
|
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
Then, edit the API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) and remove the token-auth-file setting.
kubernetesMasterConfig:
apiServerArguments:
token-auth-file:
- /path/to/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
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.
Edit the API server pod specification file
/etc/origin/master/master-config.yaml on the master node(s)
and 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 Maximum Audit Log Size
[ref] | To rotate audit logs upon reaching a maximum size,
edit the API Server pod
specification file /etc/origin/master/master-config.yaml 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:
auditFilePath: "/etc/origin/master/audit-ocp.log"
enabled: true
maximumFileRetentionDays: 30
maximumFileSizeMegabytes: 100
maximumRetainedFiles: 10 | 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
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
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.
Ensure that kubeletClientInfo has the certFile configured in
the API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
kubeletClientInfo:
ca: ca-bundle.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.key | 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
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 API server pod specification file
/etc/origin/master/master-config.yaml 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: "/etc/origin/master/audit-ocp.log"
enabled: true
maximumFileRetentionDays: 30
maximumFileSizeMegabytes: 10
maximumRetainedFiles: 10 | 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
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.
Ensure that kubeletClientInfo has the ca configured in
the API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
kubeletClientInfo:
ca: ca-bundle.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.key | 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
Disable Use of the Insecure Bind Address
[ref] | OpenShift should not bind to non-loopback insecure addresses.
Edit the API Server pod specification file /etc/origin/master/master-config.yaml
on the master node(s) and remove the insecure-bind-address
parameter.
kubernetesMasterConfig:
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
Disable Insecure Tokens
[ref] | This check is only applicable on OpenShift 3.10 and earlier deployments.
Insecure tokens should be forbidden. Edit the API server pod specification file
/etc/origin/master/master-config.yaml on the master node(s) and
remove any instance of the insecure-allow-any-token parameter. | Rationale: | Accepting insecure tokens would allow any token without performing
actual authentication. User information is parsed from the token and
connections are allowed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_insecure_allow_any_token | Identifiers and References | References:
1.1.3 | |
|
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 Advanced Auditing for the API Server
[ref] | To ensure advanced auditing is not disabled, edit the API
server pod specification file
/etc/origin/master/master-config.yaml and set the
parameters below:
kubernetesMasterConfig:
apiServerArguments:
feature-gates:
- AdvancedAuditing=true | Rationale: | AdvancedAuditing enables a much more general API auditing
pipeline, which includes support for pluggable output backends and an
audit policy specifying how different requests should be audited.
Additionally, this enables auditing of failed authentication,
authorization, and login attempts which could prove crucial for
protecting your production clusters. It is recommended not to disable
advanced auditing.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_advanced_auditing | Identifiers and References | References:
1.1.36 | |
|
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 API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
servingInfo:
clientCA: ca.crt
certFile: master.server.crt
keyFile: master.server.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
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
Use Strong Cryptographic Ciphers on the API Server
[ref] | To ensure that the API Server is configured to only use strong
cryptographic ciphers,edit the API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node and set the parameter below:
servingInfo:
cipherSuites:
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_GCM_SHA256 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 Service Account Private Key for the API Server
[ref] | To ensure the API Server utilizes its own key pair, edit the
API Server pod specification file
/etc/origin/master/master-config.yaml on the master node(s)
and set the privateKeyFile parameter to the public
key file for service accounts:
serviceAccountConfig:
...
privateKeyFile: serviceaccounts.private.key
... | Rationale: | By default, if no privateKeyFile is specified to the
API Server, the API Server uses the private key from the TLS serving
certificate to verify service account tokens. To ensure that the keys
for service account tokens could be rotated as needed, a separate
public/private key pair should be used for signing service account
tokens. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_service_account_private_key | Identifiers and References | References:
1.3.4 | |
|
Rule
Configure the Maximum Retained Audit Logs
[ref] | To configure how many rotations of audit logs are retained,
edit the API Server pod specification file /etc/origin/master/master-config.yaml
on the master node(s) and set the maximumRetainedFiles parameter to
10 or to an organizationally appropriate value:
auditConfig:
auditFilePath: "/etc/origin/master/audit-ocp.log"
enabled: true
maximumFileRetentionDays: 30
maximumFileSizeMegabytes: 10
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 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 etcdClientInfo has the ca configured in
the API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
etcdClientInfo:
ca: master.etcd-ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.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 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
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/origin/master/master-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
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
in /etc/origin/master/master-config.yaml on the master node(s). | 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
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.
edit the API Server pod specification
file /etc/origin/master/master-config.yaml on the master node(s)
and either remove the secure-port or set it to a different
(non-zero) desired port.
kubernetesMasterConfig:
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 Audit Log Maximum Retention Days (maximumFileRetentionDays)
[ref] | To configure audit log retention,
edit the API Server pod specification file
/etc/origin/master/master-config.yaml on the master node(s) and set
the maximumFileRetentionDays parameter to 30 or as appropriate for the number of days:
auditConfig:
auditFilePath: "/etc/origin/master/audit-ocp.log"
enabled: true
maximumFileRetentionDays: 30
maximumFileSizeMegabytes: 10
maximumRetainedFiles: 10 | 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
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 etcdClientInfo has the ca configured in
the API Server pod specification file
/etc/origin/master/master-config.yaml on the master
node(s) to something similar to:
etcdClientInfo:
ca: master.etcd-ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.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_cert | Identifiers and References | References:
1.2.29 | |
|
Rule
Configure the Service Account Public Key for the API Server
[ref] | To ensure the API Server utilizes its own key pair,
edit the API server pod specification file
/etc/origin/master/master-config.yaml on the master node(s)
and set the publicKeyFiles parameter to the public
key file for service accounts:
serviceAccountConfig:
...
publicKeyFiles:
- serviceaccounts.public.key
... | Rationale: | By default, if no privateKeyFile is specified to the
API Server, the API Server uses the private key from the TLS serving
certificate to verify service account tokens. To ensure that the keys
for service account tokens could be rotated as needed, a separate
public/private key pair should be used for signing service account
tokens. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_service_account_public_key | Identifiers and References | References:
1.2.28 | |
|
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
Configure the Service Account Certificate Authority Key for the API Server
[ref] | To ensure the API Server utilizes a certificate authority, edit the
API Server pod specification file
/etc/origin/master/master-config.yaml on the master node(s)
and set the masterCA parameter to the certificate authority
key file for service accounts:
serviceAccountConfig:
...
masterCA: ca-bundle.crt
... | Rationale: | Service accounts authenticate to the API using tokens signed by a private RSA
key. The authentication layer verifies the signature using a matching public RSA key.
Configuring the certificate authority file ensures that the API server's signing
certificates are validated. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_service_account_ca | Identifiers and References | References:
1.3.5 | |
|