| Group
Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4
Group contains 7 groups and 14 rules |
| Group
Kubernetes Settings
Group contains 6 groups and 14 rules |
[ref]
Each section of this configuration guide includes information about the
configuration of a Kubernetes cluster and a set of recommendations for
hardening the configuration. For each hardening recommendation, information
on how to implement the control and/or how to verify or audit the control
is provided. In some cases, remediation information is also provided.
Some of the settings in the hardening guide are in place by default. The
audit information for these settings is provided in order to verify that
the cluster administrator has not made changes that would be less secure.
A small number of items require configuration.
Finally, there are some recommendations that require decisions by the
system operator, such as audit log size, retention, and related settings. |
| Group
OpenShift Kube API Server
Group contains 2 rules |
[ref]
This section contains recommendations for kube-apiserver configuration. |
Rule
Configure the Encryption Provider Cipher
[ref] |
When you enable etcd encryption, the following OpenShift API server
and Kubernetes API server resources are encrypted:
- Secrets
- ConfigMaps
- Routes
- OAuth access tokens
- OAuth authorize tokens
When you enable etcd encryption, encryption keys are created. These
keys are rotated on a weekly basis. You must have these keys in order
to restore from an etcd backup.
To ensure the correct cipher, set the encryption type aescbc in the
apiserver object which configures the API server itself.
spec:
encryption:
type: aescbc
For more information, follow
the relevant documentation.
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
{{if ne .hypershift_cluster "None"}}/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}{{else}}/apis/config.openshift.io/v1/apiservers/cluster{{end}}
API endpoint, filter with with the jq utility using the following filter
{{if ne .hypershift_cluster "None"}}[.spec.secretEncryption.type]{{else}}[.spec.encryption.type]{{end}}
and persist it to the local
/kubernetes-api-resources/apis/config.openshift.io/v1/apiservers/cluster#a1d4b20a86b76e7e2d634dbeff420b1a80df6800836dad1b552314d1b24a18cb
file.
| | Rationale: | etcd is a highly available key-value store used by OpenShift deployments
for persistent storage of all REST API objects. These objects are
sensitive in nature and should be encrypted at rest to avoid any
disclosures. Where etcd encryption is used, it is important to ensure that the
appropriate set of encryption providers is used. Currently, aescbc
is the only type supported by OCP. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_encryption_provider_cipher | | Identifiers: | CCE-83585-0 | | References: | | |
|
Rule
Use Strong Cryptographic Ciphers on the API Server
[ref] | To ensure that the API Server is configured to only use strong
cryptographic ciphers, verify the openshift-kube-apiserver
configmap contains the following set of ciphers, with no additions:
"servingInfo":{
...
"cipherSuites": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
],
...
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
{{if ne .hypershift_cluster "None"}}/api/v1/namespaces/{{.hypershift_namespace_prefix}}-{{.hypershift_cluster}}/configmaps/kas-config{{else}}/api/v1/namespaces/openshift-kube-apiserver/configmaps/config{{end}}
API endpoint, filter with with the jq utility using the following filter
{{if ne .hypershift_cluster "None"}}.data."config.json" | fromjson{{else}}.data."config.yaml" | fromjson{{end}}
and persist it to the local
/kubernetes-api-resources/api/v1/namespaces/openshift-kube-apiserver/configmaps/config#54842ba5cf821644f2727625c1518eba2de6e6b7ae318043d0bf7ccc9570e430
file.
Warning:
Once configured, API Server clients that cannot support modern
cryptographic ciphers will not be able to make connections to the API
server. | | Rationale: | TLS ciphers have had a number of known vulnerabilities and weaknesses,
which can reduce the protection provided. By default, OpenShift supports
a number of TLS ciphersuites including some that have security concerns,
weakening the protection provided. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_tls_cipher_suites | | References: | | |
|
| Group
Authentication
Group contains 1 rule |
[ref]
In cloud workloads, there are many ways to create and configure
to multiple authentication services. Some of these authentication
methods by not be secure or common methodologies, or they may not
be secure by default. This section introduces mechanisms for
configuring authentication systems Kubernetes. |
Rule
Do Not Use htpasswd-based IdP
[ref] |
For users to interact with OpenShift Container Platform, they must first
authenticate to the cluster. The authentication layer identifies the user
associated with requests to the OpenShift Container Platform API. The
authorization layer then uses information about the requesting user to
determine if the request is allowed.
Understanding authentication | Authentication | OpenShift Container Platform
The OpenShift Container Platform includes a built-in OAuth server for
token-based authentication. Developers and administrators obtain OAuth
access tokens to authenticate themselves to the API. It is recommended for
an administrator to configure OAuth to specify an identity provider after
the cluster is installed. User access to the cluster is managed through the
identity provider.
Understanding identity provider configuration | Authentication | OpenShift Container Platform
However, not all Identity Providers supported by OpenShift provide the same
level of capabilities. As an example, the htpasswd Identity Provider only
checks the username and password match and provides no means of 2FA, account
lockout or notification mechanism. This rule therefore only allows a subset
of identity providers.
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
{{if ne .hypershift_cluster "None"}}/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}{{else}}/apis/config.openshift.io/v1/oauths/cluster{{end}}
API endpoint, filter with with the jq utility using the following filter
{{if ne .hypershift_cluster "None"}}.spec.configuration.oauth{{else}}.spec{{end}}
and persist it to the local
/kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster#489c53adb0325a207f2120d4dee0ef775dad56dceaa74bafc10bf32c1da46e9e
file.
| | Rationale: |
With any authentication mechanism the ability to revoke credentials if they
are compromised or no longer required, is a key control. Kubernetes client
certificate authentication does not allow for this due to a lack of support
for certificate revocation.
OpenShift's built-in OAuth server allows credential revocation by relying on
the Identity provider, as well as giving the administrators the ability to
revoke any tokens given to a specific user.
In addition, using an external Identity provider allows for setting up notifications
on account creation or deletion, multi-factor authentication, disabling inactive
accounts or other features required by different compliance standards.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_ocp_idp_no_htpasswd | | Identifiers: | CCE-84209-6 | | References: | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | | nist | AC-2(1), AC-2(2), AC-2(3), AC-2(4), AC-2(7), AC-2(8), AC-7, IA-2, IA-2(1), IA-2(2), IA-2(3), IA-2(5), IA-2(8), IA-2(9), IA-2(12), IA-5(4), SC-12(1) | | app-srg-ctr | SRG-APP-000023-CTR-000055, CNTR-OS-000030, CNTR-OS-000040, CNTR-OS-000440 | | stigref | SV-257507r921464_rule, SV-257508r921467_rule, SV-257542r921569_rule |
| |
|
| Group
Kubernetes - General Security Practices
Group contains 2 rules |
[ref]
Contains evaluations for general security practices for operating a Kubernetes environment. |
Rule
This is a helper rule to fetch the required api resource for detecting HyperShift OCP version
[ref] | no description Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
/apis/hypershift.openshift.io/v1beta1/namespaces/{{.hypershift_namespace_prefix}}/hostedclusters/{{.hypershift_cluster}}
API endpoint, filter with with the jq utility using the following filter
[.status.version.history[].version]
and persist it to the local
/kubernetes-api-resources/hypershift/version
file.
This rule will be a hidden rule
true
true
| | Rationale: | no rationale | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_version_detect_in_hypershift | |
|
Rule
This is a helper rule to fetch the required api resource for detecting OCP version
[ref] | no description Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
{{.ocp_version_api_path}}
API endpoint, filter with with the jq utility using the following filter
{{.ocp_version_yaml_path}}
and persist it to the local
/kubernetes-api-resources/ocp/version
file.
This rule will be a hidden rule
true
true
| | Rationale: | no rationale | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_version_detect_in_ocp | |
|
| Group
Role-based Access Control
Group contains 3 rules |
[ref]
Role-based access control (RBAC) objects determine
whether a user is allowed to perform a given action
within a project.
Cluster administrators can use the cluster roles and
bindings to control who has various access levels to
the OpenShift Container Platform platform itself
and all projects.
Developers can use local roles and bindings to control
who has access to their projects. Note that authorization
is a separate step from authentication, which is more
about determining the identity of who is taking the action. |
Rule
Ensure that the cluster-admin role is only used where required
[ref] | The RBAC role cluster-admin provides wide-ranging powers over the
environment and should be used only where and when needed. | | Rationale: | Kubernetes provides a set of default roles where RBAC is used. Some of these
roles such as cluster-admin provide wide-ranging privileges which should
only be applied where absolutely necessary. Roles such as cluster-admin
allow super-user access to perform any action on any resource. When used in
a ClusterRoleBinding, it gives full control over every resource in the
cluster and in all namespaces. When used in a RoleBinding, it gives full
control over every resource in the rolebinding's namespace, including the
namespace itself. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rbac_limit_cluster_admin | | References: | | |
|
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 | | References: | | |
|
Rule
Minimize Wildcard Usage in Cluster and Local Roles
[ref] | Kubernetes Cluster and Local Roles provide access to resources
based on sets of objects and actions that can be taken on
those objects. It is possible to set either of these using a
wildcard * which matches all items. This violates the
principle of least privilege and leaves a cluster in a more
vulnerable state to privilege abuse. | | Rationale: | The principle of least privilege recommends that users are
provided only the access required for their role and nothing
more. The use of wildcard rights grants is likely to provide
excessive rights to the Kubernetes API. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rbac_wildcard_use | | References: | | |
|
| Group
Kubernetes - Registry Security Practices
Group contains 2 rules |
[ref]
Contains evaluations for Kubernetes registry security practices, and cluster-wide registry configuration. |
Rule
Allowed registries are configured
[ref] | The configuration registrySources.allowedRegistries determines the
permitted registries that the OpenShift container runtime can access for builds
and pods. This configuration setting ensures that all registries other than
those specified are blocked.
You can set the allowed repositories by applying the following manifest using
oc patch , e.g. if you save the following snippet to
/tmp/allowed-registries-patch.yaml
spec:
registrySources:
allowedRegistries:
- my-trusted-registry.internal.example.com
you would call
oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-registries-patch.yaml)" --type=merge
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /apis/config.openshift.io/v1/images/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/images/cluster file. | | Rationale: | Allowed registries should be configured to restrict the registries that the
OpenShift container runtime can access, and all other registries should be
blocked. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_ocp_allowed_registries | | References: | | nist | CM-5(3), CM-7(2), CM-7(5), CM-11 | | app-srg-ctr | SRG-APP-000456-CTR-001125, CNTR-OS-000890, CNTR-OS-000900 | | cis | 5.5.1 | | stigref | SV-257571r921656_rule, SV-257572r921659_rule |
| |
|
Rule
Allowed registries for import are configured
[ref] | The configuration allowedRegistriesForImport limits the container
image registries from which normal users may import images. This is important
to control, as a user who can stand up a malicious registry can then import
content which claims to include the SHAs of legitimate content layers.
You can set the allowed repositories for import by applying the following
manifest using oc patch , e.g. if you save the following snippet to
/tmp/allowed-import-registries-patch.yaml
spec:
allowedRegistriesForImport:
- domainName: my-trusted-registry.internal.example.com
insecure: false
you would call
oc patch image.config.openshift.io cluster --patch="$(cat /tmp/allowed-import-registries-patch.yaml)" --type=merge
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /apis/config.openshift.io/v1/images/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/images/cluster file. | | Rationale: | Allowed registries for import should be specified to limit the registries
from which users may import images. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_ocp_allowed_registries_for_import | | References: | | nist | CM-5(3), CM-7(2), CM-7(5), CM-11 | | app-srg-ctr | SRG-APP-000456-CTR-001125, CNTR-OS-000890, CNTR-OS-000900 | | cis | 5.5.1 | | stigref | SV-257571r921656_rule, SV-257572r921659_rule |
| |
|
| Group
Security Context Constraints (SCC)
Group contains 4 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 Container Capabilities
[ref] |
Containers should not enable more capabilites than needed as this
opens the door for malicious use. To enable only the
required capabilities, the appropriate Security Context Constraints (SCCs)
should set capabilities as a list in allowedCapabilities.
In case an SCC outside the default allow list in the variable
var-sccs-with-allowed-capabilities-regex is being flagged,
create a TailoredProfile and add the additional SCC to the
regular expression in the variable var-sccs-with-allowed-capabilities-regex.
An example allowing an SCC named additional follows:
apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
name: cis-additional-scc
spec:
description: Allows an additional scc
setValues:
- name: upstream-ocp4-var-sccs-with-allowed-capabilities-regex
rationale: Allow our own custom SCC
value: ^privileged$|^hostnetwork-v2$|^restricted-v2$|^nonroot-v2$|^additional$
extends: upstream-ocp4-cis
title: Modified CIS allowing one more SCC
Finally, reference this TailoredProfile in a ScanSettingBinding
For more information on Tailoring the Compliance Operator, please consult the
OpenShift documentation:
https://docs.openshift.com/container-platform/4.12/security/compliance_operator/compliance-operator-tailor.html
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
/apis/security.openshift.io/v1/securitycontextconstraints
API endpoint, filter with with the jq utility using the following filter
[.items[] | select(.metadata.name | test("{{.var_sccs_with_allowed_capabilities_regex}}"; "") | not) | select(.allowedCapabilities != null) | .metadata.name]
and persist it to the local
/kubernetes-api-resources/apis/security.openshift.io/v1/securitycontextconstraints#821f2c3e5c4100d5609ac6070d8a51075295651614a05c65a5f744ba751c15b0
file.
| | Rationale: | 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 | | References: | | |
|
Rule
Limit Containers Ability to Escalate Privileges
[ref] | Containers should be limited to only the privileges required
to run and should not be allowed to escalate their privileges.
To prevent containers from escalating privileges,
the appropriate Security Context Constraints (SCCs)
should set allowPrivilegeEscalation to false. | | Rationale: | Privileged containers have access to more of the Linux Kernel
capabilities and devices. If a privileged container were
compromised, an attacker would have full access to the container
and host. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_privilege_escalation | | Identifiers: | CCE-83447-3 | | References: | | |
|
Rule
Limit Privileged Container Use
[ref] | Containers should be limited to only the privileges required
to run. To prevent containers from running as privileged containers,
the appropriate Security Context Constraints (SCCs) should set
allowPrivilegedContainer to false. | | Rationale: | Privileged containers have access to all Linux Kernel
capabilities and devices. If a privileged container were
compromised, an attacker would have full access to the container
and host. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_privileged_containers | | References: | | |
|
Rule
Limit Container Running As Root User
[ref] | Containers should run as a random non-privileged user.
To prevent containers from running as root user,
the appropriate Security Context Constraints (SCCs) should set
.runAsUser.type to MustRunAsRange. | | Rationale: | It is strongly recommended that containers running on OpenShift
should support running as any arbitrary UID. OpenShift will then assign
a random, non-privileged UID to the running container instance. This
avoids the risk from containers running with specific uids that could
map to host service accounts, or an even greater risk of running as root
level service. OpenShift uses the default security context constraints
(SCC), restricted, to prevent containers from running as root or other
privileged user ids. Pods may be configured to use an scc policy
that allows the container to run as a specific uid, including root(0)
when approved. Only a cluster administrator may grant the change of
an scc policy. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_root_containers | | References: | | |
|