Group
Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4
Group contains 13 groups and 79 rules |
Group
OpenShift Settings
Group contains 12 groups and 79 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. |
Rule
Restrict Automounting of Service Account Tokens
[ref] | Service accounts tokens should not be mounted in pods except where the workload
running in the pod explicitly needs to communicate with the API server.
To ensure pods do not automatically mount tokens, set
automountServiceAccountToken to false . | Rationale: | Mounting service account tokens inside pods can provide an avenue
for privilege escalation attacks where an attacker is able to
compromise a single pod in the cluster. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_restrict_service_account_tokens | Identifiers and References | References:
5.1.6 | |
|
Rule
Ensure Usage of Unique Service Accounts
[ref] | Using the default service account prevents accurate application
rights review and audit tracing. For each namespace, create
a new and unique service account with the following command:
$ oc create sa service_account_name>
where service_account_name> is the name of a service account
that is needed in the project namespace. | Rationale: | Kubernetes provides a default service account which is used by
cluster workloads where no specific service account is assigned to the pod.
Where access to the Kubernetes API from a pod is required, a specific service account
should be created for that pod, and rights granted to that service account.
This increases auditability of service account rights and access making it
easier and more accurate to trace potential malicious behaviors to a specific
service account and project. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_unique_service_account | Identifiers and References | References:
5.1.5 | |
|
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 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 . Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/security.openshift.io/v1/securitycontextconstraints API endpoint to the local /kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints file. | Rationale: | A container running in the host's IPC namespace can use IPC
to interact with processes outside the container potentially
allowing an attacker to exploit a host process thereby enabling an
attacker to exploit other services. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_ipc_namespace | Identifiers and References | Identifiers:
CCE-84042-1 References:
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_limit_container_allowed_capabilities | Identifiers and References | References:
5.2.8 | |
|
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 . Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/security.openshift.io/v1/securitycontextconstraints API endpoint to the local /kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints file. | 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
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 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 . Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/security.openshift.io/v1/securitycontextconstraints API endpoint to the local /kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints file. | Rationale: | A container running in the host's network namespace could
access the host network traffic to and from other pods
potentially allowing an attacker to exploit pods and network
traffic. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_network_namespace | Identifiers and References | Identifiers:
CCE-83492-9 References:
5.2.4 | |
|
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 . Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/security.openshift.io/v1/securitycontextconstraints API endpoint to the local /kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints file. | Rationale: | By default, containers run with a default set of capabilities as assigned
by the Container Runtime which can include dangerous or highly privileged
capabilities. 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
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 . Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/security.openshift.io/v1/securitycontextconstraints API endpoint to the local /kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints file. | Rationale: | By default, containers run with a default set of capabilities as assigned
by the Container Runtime which can include dangerous or highly privileged
capabilities. Capabilities should be dropped unless absolutely critical for
the container to run software as added capabilities that are not required
allow for malicious containers or attackers. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_scc_drop_container_capabilities | Identifiers and References | References:
5.2.9 | |
|
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 . Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/security.openshift.io/v1/securitycontextconstraints API endpoint to the local /kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints file. | Rationale: | Privileged containers have access to more of the Linux Kernel
capabilities and devices. If a privileged container were
compromised, an attacker would have full access to the container
and host. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_privilege_escalation | Identifiers and References | Identifiers:
CCE-83447-3 References:
5.2.5 | |
|
Rule
Limit Privileged Container Use
[ref] | Containers should be limited to only the privileges required
to run. To prevent containers from running as privileged containers,
the appropriate Security Context Constraints (SCCs) should set
allowPrivilegedContainer to false . Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/security.openshift.io/v1/securitycontextconstraints API endpoint to the local /kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints file. | 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 | |
|
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
OpenShift etcd Settings
Group contains 9 rules |
[ref]
Contains rules that check correct OpenShift etcd settings. |
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 Client Certificate Is Correctly Set
[ref] | To ensure the etcd service is serving TLS to clients,
make sure the etcd-pod* ConfigMaps in the
openshift-etcd namespace contain the following argument
for the etcd binary in the etcd pod:
--cert-file=/etc/kubernetes/static-pod-certs/secrets/etcd-all-serving/etcd-serving-NODE_NAME.crt Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-etcd/configmaps/etcd-pod API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod file. | Rationale: | Without cryptographic integrity protections, information can be
altered by unauthorized users without detection. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_etcd_cert_file | Identifiers and References | Identifiers:
CCE-83553-8 References:
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
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
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
Disable etcd Self-Signed Certificates
[ref] | To ensure the etcd service is not using self-signed
certificates, run the following command:
$ oc get cm/etcd-pod -n openshift-etcd -o yaml
The etcd pod configuration contained in the configmap should not
contain the --auto-tls=true flag. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-etcd/configmaps/etcd-pod API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-etcd/configmaps/etcd-pod file. | Rationale: | Without cryptographic integrity protections, information can be
altered by unauthorized users without detection. Using self-signed
certificates ensures that the certificates are never validated
against a certificate authority and could lead to compromised
and invalidated data. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_etcd_auto_tls | Identifiers and References | Identifiers:
CCE-84199-9 References:
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/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 | |
|
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
Kubernetes Kubelet Settings
Group contains 3 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 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 Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | Without cryptographic integrity protections, information can be
altered by unauthorized users without detection. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kubelet_configure_tls_cert | Identifiers and References | Identifiers:
CCE-83396-2 References:
4.2.10 | |
|
Rule
Ensure That The kubelet Server Key Is Correctly Set
[ref] | To ensure the kubelet TLS private server key certificate is configured, edit the
kubelet configuration file /etc/kubernetes/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 - Disable the Read-Only Port
[ref] | To disable the read-only port, edit the kubelet configuration
Edit the openshift-kube-apiserver configmap on the master node(s)
and set the kubelet-read-only-port parameter to 0:
"apiServerArguments":{
...
"kubelet-read-only-port":[
"0"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | OpenShift disables the read-only port (10255 ) on all nodes by setting the
read-only port kubelet flag to 0 . This ensures only
authenticated connections are able to receive information about the OpenShift
system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kubelet_disable_readonly_port | Identifiers and References | Identifiers:
CCE-83427-5 References:
4.2.4 | |
|
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
OpenShift Kube API Server
Group contains 39 rules |
[ref]
This section contains recommendations for kube-apiserver configuration. |
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
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:
"apiServerArguments":{
...
"kubelet-certificate-authority":"/etc/kubernetes/static-pod-resources/configmaps/kubelet-serving-ca/ca-bundle.crt",
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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 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"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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
Configure the Client Certificate Authority for the API Server
[ref] | Certificates must be provided to fully setup TLS client certificate
authentication. To ensure the API Server utilizes its own TLS certificates, the
clientCA must be configured. Verify
that servingInfo has the clientCA configured in
the openshift-kube-apiserver config configmap on the master
node(s) to something similar to:
"apiServerArguments": {
...
"client-ca-file": [
"/etc/kubernetes/static-pod-certs/configmaps/client-ca/ca-bundle.crt"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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 | |
|
Rule
Enable the NodeRestriction Admission Control Plugin
[ref] | To limit the Node and Pod objects that a kubelet could modify,
ensure that the NodeRestriction plugin on kubelets is enabled in
the api-server configuration by running the following command:
$ oc -n openshift-kube-apiserver get configmap config -o json | jq -r '.data."config.yaml"' | jq '.apiServerArguments."enable-admission-plugins"' Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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
Must have authorization-mode Node set
[ref] | Restrict kubelet nodes to reading only objects associated with them. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | The Node authorization mode only allows kubelets to read Secret,
ConfigMap, PersistentVolume, and PersistentVolumeClaim objects
associated with their nodes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_auth_mode_node | Identifiers and References | References:
1.2.8 | |
|
Rule
The authorization-mode cannot be AlwaysAllow
[ref] | Do not always authorize all requests. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | The API Server, can be configured to allow all requests. This mode should not be used on any production cluster. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_auth_mode_no_aa | Identifiers and References | References:
1.2.7 | |
|
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"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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.
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
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
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-port if it exists:
"apiServerArguments":{
...
"insecure-port":[
"1234"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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 etcd Certificate Authority for the API Server
[ref] | To ensure etcd is configured to make use of TLS encryption for client
connections, follow the OpenShift documentation and setup the TLS
connection between the API Server and etcd. Then, verify
that apiServerArguments has the etcd-cafile configured in
the openshift-kube-apiserver config configmap on the master
node(s) to something similar to:
"apiServerArguments": {
...
"etcd-cafile": [
"/etc/kubernetes/static-pod-resources/configmaps/etcd-serving-ca/ca-bundle.crt"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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
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:
...
"tls-private-key-file": [
"/etc/kubernetes/static-pod-certs/secrets/service-network-serving-certkey/tls.key"
]
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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 etcd Certificate for the API Server
[ref] | To ensure etcd is configured to make use of TLS encryption for client
communications, follow the OpenShift documentation and setup the TLS
connection between the API Server and etcd. Then, verify
that apiServerArguments has the etcd-certfile configured in
the openshift-kube-apiserver configmap on the master
node(s) to something similar to:
...
"etcd-certfile": [
"/etc/kubernetes/static-pod-resources/secrets/etcd-client/tls.crt"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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
Disable basic-auth-file for the API Server
[ref] | Basic Authentication should not be used for any reason. If needed, edit API
Edit the openshift-kube-apiserver configmap 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. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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 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
Configure the Service Account Public Key for the API Server
[ref] | To ensure the API Server utilizes its own key pair,
edit the openshift-kube-apiserver configmap on the master node(s)
and set the serviceAccountPublicKeyFiles parameter to the public
key file for service accounts:
...
"serviceAccountPublicKeyFiles":[
"/etc/kubernetes/static-pod-resources/configmaps/sa-token-signing-certs"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | By default if no service-account-key-file is specified
to the apiserver, it uses the private key from the TLS serving
certificate to verify service account tokens. To ensure that the
keys for service account tokens are 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
Ensure that the service-account-lookup argument is set to true
[ref] | Validate service account before validating token. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file.
| Rationale: | If service-account-lookup is not enabled, the apiserver
only verifies that the authentication token is valid, and
does not validate that the service account token mentioned
in the request is actually present in etcd. This allows
using a service account token even after the corresponding
service account is deleted. This is an example of time of
check to time of use security issue. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_service_account_lookup | Identifiers and References | References:
1.2.27 | |
|
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:
...
"tls-cert-file": [
"/etc/kubernetes/static-pod-certs/secrets/service-network-serving-certkey/tls.crt"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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 kubelet Certificate Key for the API Server
[ref] | To enable certificate based kubelet authentication,
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",
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | By default the API Server does not authenticate itself to the kubelet's
HTTPS endpoints. Requests from the API Server are treated anonymously.
Configuring certificate-based kubelet authentication ensures that the
API Server authenticates itself to kubelets when submitting requests. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_kubelet_client_key | Identifiers and References | References:
1.2.5 | |
|
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
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 Encryption Provider
[ref] | To encrypt the etcd key-value store, set the encryption type aescbc in the
apiserver object which configures the API server itself.
spec:
encryption:
type: aescbc
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/config.openshift.io/v1/apiservers/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/apiservers/cluster file. | Rationale: | 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 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
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_serving_cert | Identifiers and References | References:
1.2.4 | |
|
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
Ensure that the bindAddress is set to a relevant secure port
[ref] | The bindAddress is set by default to 0.0.0.0:6443 , and listening with TLS enabled. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | The OpenShift API server is served over HTTPS with authentication and authorization;
the secure API endpoint is bound to 0.0.0.0:6443 by default. In OpenShift, the only
supported way to access the API server pod is through the load balancer and then through
the internal service. The value is set by the bindAddress argument under the servingInfo
parameter. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_bind_address | Identifiers and References | References:
1.2.20 | |
|
Rule
Configure the etcd Certificate Key for the API Server
[ref] | To ensure etcd is configured to make use of TLS encryption for client
communications, follow the OpenShift documentation and setup the TLS
connection between the API Server and etcd. Then, verify
that apiServerArguments has the etcd-keyfile configured in
the openshift-kube-apiserver configmap on the master
node(s) to something similar to:
...
"etcd-keyfile": [
"/etc/kubernetes/static-pod-resources/secrets/etcd-client/tls.key"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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
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"
],
...
This rule checks the kubelet-client-key value in the apiserver
configuration config map to make sure it is set. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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_key | Identifiers and References | References:
1.2.4 | |
|
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
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.
Ensure that the plugin is enabled in the api-server configuration:
$ oc -n openshift-kube-apiserver get configmap config -o json | jq -r '.data."config.yaml"' | jq '.apiServerArguments."enable-admission-plugins"' Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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
Disable the AlwaysAdmit Admission Control Plugin
[ref] | To ensure OpenShift only responses to requests explicitly allowed by the
admission control plugin. Check that the config ConfigMap object does not
contain the AlwaysAdmit plugin.
and ensure the admissionConfig is not configured to include AlwaysAdmit . Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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
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"
],
...
This rule checks the kubelet-client-certificate value in the apiserver
configuration config map to make sure it is set. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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_cert | 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.
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
Configure the Audit Log Path
[ref] | To enable auditing on the OpenShift API Server, the audit log path must be set.
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:
"apiServerArguments":{
...
"audit-log-path":"/var/log/kube-apiserver/audit.log",
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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 File for the API Server
[ref] | To enable certificate based kubelet authentication,
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",
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | By default the API Server does not authenticate itself to the 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 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
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] | OpenShift enables the NamespaceLifecycle plugin by default. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config file. | Rationale: | 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 | |
|
Group
Role-based Acess Control
Group contains 5 rules |
[ref]
Role-based access control (RBAC) objects determine
whether a user is allowed to perform a given action
within a project.
Cluster administrators can use the cluster roles and
bindings to control who has various access levels to
the OpenShift Container Platform platform itself
and all projects.
Developers can use local roles and bindings to control
who has access to their projects. Note that authorization
is a separate step from authentication, which is more
about determining the identity of who is taking the action. |
Rule
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 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 | |
|
Rule
Limit Access to Cluster 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
Profiling is protected by RBAC
[ref] | Ensure that the cluster-debugger cluster role includes the /debug/pprof
resource URL. This demonstrates that profiling is protected by RBAC, with a
specific cluster role to allow access. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-debugger API endpoint to the local /kubernetes-api-resources/apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-debugger file. | Rationale: | Profiling allows for the identification of specific performance bottlenecks.
It generates a significant amount of program data that could potentially be
exploited to uncover system and program details. If you are not experiencing
any bottlenecks and do not need the profiler for troubleshooting purposes, it
is recommended to turn it off to reduce the potential attack surface. To
ensure the collected data is not exploited, profiling endpoints are secured
via RBAC (see cluster-debugger role). By default, the profiling endpoints are
accessible only by users bound to cluster-admin or cluster-debugger role.
Profiling can not be disabled. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rbac_debug_role_protects_pprof | Identifiers and References | Identifiers:
CCE-84182-5 References:
1.3.2 | |
|
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 | |
|
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 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 | |
|
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 | |
|
Group
OpenShift API Server
Group contains 1 rule |
[ref]
This section contains recommendations for openshift-apiserver configuration. |
Rule
Configure the Audit Log Path
[ref] | To enable auditing on the OpenShift API Server, the audit log path must be set.
Edit the openshift-apiserver configmap 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:
"apiServerArguments":{
...
"audit-log-path":"/var/log/openshift-apiserver/audit.log",
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-apiserver/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-apiserver/configmaps/config file. | Rationale: | Auditing of the API Server is not enabled by default. Auditing the API Server
provides a security-relevant chronological set of records documenting the sequence
of activities that have affected the system by users, administrators, or other
system components. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_openshift_api_server_audit_log_path | Identifiers and References | References:
1.2.22 | |
|
Group
OpenShift Controller Settings
Group contains 6 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 rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-controller-manager/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config file. Warning:
This recommendation only applies if you let kubelets get their
certificates from the API Server. In case your certificates come from an
outside Certificate Authority/tool (e.g. Vault) then you need to take care
of rotation yourself | Rationale: | Enabling kubelet certificate rotation causes the kubelet to both request
a serving certificate after bootstrapping its client credentials and rotate the
certificate as its existing credentials expire. This automated periodic rotation
ensures that there are no downtimes due to expired certificates and thus
addressing the availability in the C/I/A security triad. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_controller_rotate_kubelet_server_certs | Identifiers and References | References:
1.3.6 | |
|
Rule
Configure the Service Account Certificate Authority Key for the Controller Manager
[ref] | To ensure the API Server utilizes its own key pair, set the masterCA
parameter to the public key file for service accounts in the openshift-kube-controller-manager configmap on the master
node(s):
"extendedArguments": {
...
"root-ca-file": [
"/etc/kubernetes/static-pod-resources/configmaps/serviceaccount-ca/ca-bundle.crt"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-controller-manager/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config file. | 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_controller_service_account_ca | Identifiers and References | References:
1.3.5 | |
|
Rule
Ensure Controller insecure port argument is unset
[ref] | To ensure the Controller Manager service is bound to secure loopback
address and a secure port,
set the RotateKubeletServerCertificate option to true
in the openshift-kube-controller-manager configmap on the master
node(s):
"extendedArguments": {
...
"port": ["0"],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-controller-manager/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config file. | Rationale: | The Controller Manager API service is used for health and metrics
information and is available without authentication or encryption. As such, it
should only be bound to a localhost interface to minimize the cluster's
attack surface. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_controller_insecure_port_disabled | Identifiers and References | References:
1.3.7 | |
|
Rule
Configure the Service Account Private Key for the Controller Manager
[ref] | To ensure the API Server utilizes its own key pair, set the privateKeyFile
parameter to the public key file for service accounts in the openshift-kube-controller-manager configmap on the master
node(s):
"extendedArguments": {
...
"service-account-private-key-file": [
"/etc/kubernetes/static-pod-resources/secrets/service-account-private-key/service-account.key"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-controller-manager/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config file. | Rationale: | By default if no private key file 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_controller_service_account_private_key | Identifiers and References | References:
1.3.4 | |
|
Rule
Ensure Controller secure-port argument is set
[ref] | To ensure the Controller Manager service is bound to secure loopback
address using a secure port,
set the RotateKubeletServerCertificate option to true
in the openshift-kube-controller-manager configmap on the master
node(s):
"extendedArguments": {
...
"secure-port": ["10257"],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-controller-manager/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config file. | Rationale: | The Controller Manager API service is used for health and metrics
information and is available without authentication or encryption. As such, it
should only be bound to a localhost interface to minimize the cluster's
attack surface. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_controller_secure_port | Identifiers and References | References:
1.3.7 | |
|
Rule
Ensure that use-service-account-credentials is enabled
[ref] | To ensure individual service account credentials are used,
set the use-service-account-credentials option to true
in the openshift-kube-controller-manager configmap on the master
node(s):
"extendedArguments": {
...
"use-service-account-credentials": [
"true"
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retreive the /api/v1/namespaces/openshift-kube-controller-manager/configmaps/config API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift-kube-controller-manager/configmaps/config file. | 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-84208-8 References:
1.3.3 | |
|