| Group
Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4
Group contains 12 groups and 50 rules |
| Group
Kubernetes Settings
Group contains 11 groups and 50 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
System and Software Integrity
Group contains 1 group and 3 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. |
| Group
System Cryptographic Policies
Group contains 1 rule |
[ref]
OpenShift has the capability to centrally configure cryptographic polices. |
Rule
Ensure that FIPS mode is enabled on all cluster nodes
[ref] | OpenShift has an installation-time flag that can enable FIPS mode
for the cluster. The flag fips: true must be enabled
at install time in the install-config.yaml file. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
/apis/machineconfiguration.openshift.io/v1/machineconfigs
API endpoint, filter with with the jq utility using the following filter
[.items[] | select(.metadata.name | test("^rendered-worker-[0-9a-z]+$|^rendered-master-[0-9a-z]+$"))] | map(.spec.fips == true)
and persist it to the local
/kubernetes-api-resources/apis/machineconfiguration.openshift.io/v1/machineconfigs#ab7e02a1c3f44ae48f843ce3dee7b948d624d2f702b9428760efbfd4653847ba
file.
| | Rationale: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance they have been tested
and validated. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_fips_mode_enabled_on_all_nodes | | Identifiers: | CCE-85860-5 | | References: | | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1 | | nist | AC-17(2), CM-3(6), SC-12(2), SC-12(3), SC-13, IA-7 | | pcidss | Req-3.4.1 | | app-srg-ctr | SRG-APP-000126-CTR-000275, SRG-APP-000219-CTR-000550, SRG-APP-000411-CTR-000995, SRG-APP-000412-CTR-001000, SRG-APP-000416-CTR-001015, SRG-APP-000514-CTR-001315, SRG-APP-000610-CTR-001385, SRG-APP-000635-CTR-001405, CNTR-OS-000340, CNTR-OS-000510, CNTR-OS-001080 | | stigref | SV-257536r921551_rule, SV-257546r921581_rule, SV-257587r921704_rule |
| |
|
Rule
Ensure that Cluster Version Operator is deployed
[ref] | Integrity of the OpenShift platform is handled to start by the cluster version operator.
Cluster Version Operator will by default GPG verify the integrity of the release
image before applying it. [1]
This rule checks if Cluster Version Operator is deployed and available in the system.
[1] https://github.com/openshift/machine-config-operator/blob/master/docs/OSUpgrades.md#questions-and-answers 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/config.openshift.io/v1/clusterversions/version
API endpoint, filter with with the jq utility using the following filter
[.status.conditions[] | select(.type=="Available") | .status]
and persist it to the local
/kubernetes-api-resources/apis/config.openshift.io/v1/clusterversions/version#588c29ac9d4c67b1444308c5ba310271832895fee54701f7d0cb6cbced390443
file.
| | Rationale: | Integrity check prevent a malicious actor from using a unauthorized system image, hence it will ensure the
image has not been tampered with, or corrupted. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_cluster_version_operator_exists | | Identifiers: | CCE-90670-1 | | References: | | |
|
Rule
Ensure that Cluster Version Operator verifies integrity
[ref] | Integrity of the OpenShift platform is handled to start by the cluster version operator.
Cluster Version Operator will by default GPG verify the integrity of the release
image before applying it. This rule check if there is an unverified cluster image. 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/config.openshift.io/v1/clusterversions/version
API endpoint, filter with with the jq utility using the following filter
[.status.history[0:-1]|.[]|.verified]
and persist it to the local
/kubernetes-api-resources/apis/config.openshift.io/v1/clusterversions/version#69adcfd65c8b8d723e4a7118c170f634cebbb349e9b554dd15001e6551a586f8
file.
| | Rationale: | Unverified cluster image will compromise the system integrity. Integrity check prevent
a malicious actor from using a unauthorized system image, hence it will ensure the
image has not been tampered with, or corrupted. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_cluster_version_operator_verify_integrity | | Identifiers: | CCE-90671-9 | | References: | | |
|
| Group
OpenShift Kube API Server
Group contains 3 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 to aescbc or
aesgcm 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
and aesgcm are the only types supported by OCP. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_encryption_provider_cipher | | Identifiers: | CCE-83585-0 | | References: | | |
|
Rule
Ensure APIServer is configured with secure tlsSecurityProfile
[ref] |
The configuration tlsSecurityProfile specifies TLS configurations
to be used while establishing connections with the externally exposed
servers. Though secure transport mode is used for establishing connections,
the protocols used may not always be strong enough to avoid interception and
manipulation of the data in transport. TLS Security profile configured should
not make use of any protocols, ciphers, and algorithms with known security
vulnerabilities.
tlsSecurityProfile can be configured to use one of custom, intermediate,
modern, or old profile. Profile Old should be avoided at all times and when using
custom profile one should be extremely careful as invalid configurations can be
catastrophic. It is always advised to use highly secure intermediate or modern
profiles and if unset a default is chosen.
Update tlsSecurityProfile to Intermediate using the following command:
oc patch apiservers.config.openshift.io cluster --type 'json' --patch '[{"op": "add", "path": "/spec/tlsSecurityProfile/intermediate", "value": {}}, {"op": "replace", "path": "/spec/tlsSecurityProfile/type", "value": "Intermediate"}'
For more information, follow
OpenShift documentation:
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 /apis/config.openshift.io/v1/apiservers/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/apiservers/cluster file. | | Rationale: | The authenticity and integrity of the container platform and communication
between nodes and components must be secure. If an insecure protocol,
cipher, or algorithms is used, during transmission of data, the data can be
intercepted and manipulated. To thwart the manipulation of the data during
transmission secure protocol, cipher and algorithms must be used. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_tls_security_profile | | Identifiers: | CCE-86232-6 | | References: | | |
|
Rule
Ensure that Audit Log Forwarding Is Enabled
[ref] | OpenShift audit works at the API server level, logging all requests coming to the server.
Audit is on by default and the best practice is to ship audit logs off the cluster for retention.
The cluster-logging-operator is able to do this with the ClusterLogForwarders resource.
The forementioned resource can be configured to logs to different third party systems.
For more information on this, please reference the official documentation:
https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-clf.html
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders API endpoint to the local /kubernetes-api-resources/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders file true
/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance API endpoint to the local /kubernetes-api-resources/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance file true . | | Rationale: | Retaining logs ensures the ability to go back in time to investigate or correlate any events.
Offloading audit logs from the cluster ensures that an attacker that has access to the cluster will not be able to
tamper with the logs because of the logs being stored off-site. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_log_forwarding_enabled | | Identifiers: | CCE-84076-9 | | References: | | nerc-cip | CIP-003-8 R5.2, CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-004-6 R3.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5 | | nist | AC-2(12), AU-3(2), AU-5(1), AU-6, AU-6(1), AU-6(3), AU-9(2), SI-4(16), AU-4(1), AU-11, AU-7, AU-7(1), SI-4(20) | | pcidss | Req-2.2, Req-10.5.3, Req-10.5.4 | | app-srg-ctr | SRG-APP-000092-CTR-000165, SRG-APP-000111-CTR-000220, SRG-APP-000358-CTR-000805, CNTR-OS-000170, CNTR-OS-000220 | | cis | 1.2.21 | | pcidss4 | 2.2.1, 2.2 | | stigref | SV-257519r921500_rule, SV-257524r921515_rule |
| |
|
| Group
Authentication
Group contains 5 rules |
[ref]
In cloud workloads, there are many ways to create and configure
to multiple authentication services. Some of these authentication
methods by not be secure or common methodologies, or they may not
be secure by default. This section introduces mechanisms for
configuring authentication systems Kubernetes. |
Rule
Configure An Identity Provider
[ref] | 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.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_idp_is_configured | | Identifiers: | CCE-84088-4 | | References: | | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | | nist | AC-2, AC-2(1), AC-2(2), AC-2(3), AC-2(4), AC-2(5), AC-2(6), AC-2(7), AC-2(8), AC-7, AC-12(1), IA-2(8), IA-2(9), SC-12(1) | | pcidss | Req-2.2, Req-8.1.1 | | app-srg-ctr | SRG-APP-000023-CTR-000055, CNTR-OS-000030, CNTR-OS-000040, CNTR-OS-000440 | | cis | 3.1.1 | | pcidss4 | 2.2.1, 2.2, 8.2.1, 8.2, 8.3 | | stigref | SV-257507r921464_rule, SV-257508r921467_rule, SV-257542r921569_rule |
| |
|
Rule
Configure OAuth tokens to expire after a set period of inactivity
[ref] |
You can configure OAuth tokens to expire after a set period of
inactivity. By default, no token inactivity timeout is set.
The inactivity timeout can be either set in the OAuth server
configuration or in any of the OAuth clients. The client settings
override the OAuth server setting.
To set the OAuth server inactivity timeout, edit the OAuth server
object: oc edit oauth cluster
and set the .spec.tokenConfig.accessTokenInactivityTimeout
parameter to the desired value:
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
...
spec:
tokenConfig:
accessTokenInactivityTimeout: 10m0s
Please note that the OAuth server converts the value internally to a human-readable format,
so that e.g. setting accessTokenInactivityTimeout=600s would be converted by the OAuth
server to accessTokenInactivityTimeout=10m0s.
For more information on configuring the OAuth server, consult the
OpenShift documentation:
https://docs.openshift.com/container-platform/4.7/authentication/configuring-oauth-clients.html
To edit the OAuth client inactivity timeout, edit the OAuth client
object: oc edit oauthclient $clientname
and set the top-level accessTokenInactivityTimeoutSeconds
attribute.
apiVersion: oauth.openshift.io/v1
grantMethod: auto
kind: OAuthClient
metadata:
...
accessTokenInactivityTimeoutSeconds: 600
For more information on configuring the OAuth clients, consult the
OpenShift documentation:
https://access.redhat.com/documentation/en-us/openshift_container_platform/4.7/html-single/authentication_and_authorization/index#oauth-token-inactivity-timeout_configuring-internal-oauth
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/oauth.openshift.io/v1/oauthclients API endpoint to the local /kubernetes-api-resources/apis/oauth.openshift.io/v1/oauthclients file /apis/config.openshift.io/v1/oauths/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster file . | | Rationale: | Terminating an idle session within a short time period reduces the window
of opportunity for unauthorized personnel to take control of a session
that has been left unattended. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_oauth_or_oauthclient_inactivity_timeout | | Identifiers: | CCE-83702-1 | | References: | | nerc-cip | CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | | nist | AC-2(5), IA-5(13), SC-10 | | app-srg-ctr | SRG-APP-000190-CTR-000500, CNTR-OS-000400, CNTR-OS-000490 | | pcidss4 | 8.2.8, 8.2 | | stigref | SV-257540r921563_rule, SV-257544r921575_rule |
| |
|
Rule
Configure OAuth tokens to expire after a set period of inactivity
[ref] |
You can configure OAuth tokens to have have a custom duration.
By default, the tokens are valid for 24 hours (86400 seconds).
The maximum age can be either set in the OAuth server
configuration or in any of the OAuth clients. The client settings
override the OAuth server setting.
To set the OAuth server token max age, edit the OAuth server
object: oc edit oauth cluster
and set the .spec.tokenConfig.accessTokenMaxAgeSeconds
parameter to the desired value:
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
...
spec:
tokenConfig:
accessTokenMaxAgeSeconds: 28800
To set the OAuth client token max age, edit the OAuth client
object: oc edit oauthclient $clientname
and set the top-level accessTokenMaxAgeSeconds
attribute.
apiVersion: oauth.openshift.io/v1
grantMethod: auto
kind: OAuthClient
metadata:
...
accessTokenMaxAgeSeconds: 28800
For more information on configuring the OAuth server, consult the
OpenShift documentation:
https://docs.openshift.com/container-platform/4.7/authentication/configuring-internal-oauth.html
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /apis/oauth.openshift.io/v1/oauthclients API endpoint to the local /kubernetes-api-resources/apis/oauth.openshift.io/v1/oauthclients file /apis/config.openshift.io/v1/oauths/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/oauths/cluster file . | | Rationale: | Setting a token maximum age to a shorter time period reduces the window
of opportunity for unauthorized personnel to take control of the session. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_oauth_or_oauthclient_token_maxage | | Identifiers: | CCE-84162-7 | | References: | | |
|
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 | | pcidss4 | 8.3.4, 8.3 | | stigref | SV-257507r921464_rule, SV-257508r921467_rule, SV-257542r921569_rule |
| |
|
Rule
Only Use LDAP-based IdPs with TLS
[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
If the identity provider is LDAP, setting the insecure flag to true
would mean that passwords, such as the one used to authenticate the OAuth
proxy to the LDAP server would be transmitted in the clear, potentially
allowing an attacker to read the password if they captured the network
traffic.
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: | Transmitting authentication tokens as clear-text may leak them to
an attacker. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_ocp_no_ldap_insecure | | Identifiers: | CCE-83699-9 | | References: | | nerc-cip | CIP-003-8 R4.2, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | | nist | IA-2(8), IA-2(9), SC-8 | | pcidss | Req-2.3 | | app-srg-ctr | SRG-APP-000023-CTR-000055, CNTR-OS-000030, CNTR-OS-000040 | | pcidss4 | 2.2.7, 2.2, 8.3.2, 8.3 | | stigref | SV-257507r921464_rule, SV-257508r921467_rule |
| |
|
| Group
Kubernetes - General Security Practices
Group contains 10 rules |
[ref]
Contains evaluations for general security practices for operating a Kubernetes environment. |
Rule
Enable Classification Banner on OpenShift Console
[ref] | A classification banner can be configured by creating a Console Notification CR on OpenShift 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/console.openshift.io/v1/consolenotifications/classification-banner API endpoint to the local /kubernetes-api-resources/apis/console.openshift.io/v1/consolenotifications/classification-banner file. | | Rationale: | Displays to users organization-defined system use notification message or banner before granting
access to the system that provides privacy and security notices consistent with applicable federal laws | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_classification_banner | | Identifiers: | CCE-84197-3 | | References: | | |
|
Rule
Ensure that the kubeadmin secret has been removed
[ref] | The kubeadmin user is meant to be a temporary user used for
bootstrapping purposes. It is preferable to assign system
administrators whose users are backed by an Identity Provider.
Make sure to remove the user as
described in the documentation
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /api/v1/namespaces/kube-system/secrets/kubeadmin API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/kube-system/secrets/kubeadmin file. | | Rationale: | The kubeadmin user has an auto-generated password
and a self-signed certificate, and has effectively cluster-admin
permissions; therefore, it's considered a security liability. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_kubeadmin_removed | | Identifiers: | CCE-90387-2 | | References: | | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R2, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R6.1, CIP-007-3 R6.2, CIP-007-3 R6.3, CIP-007-3 R6.4 | | nist | AC-2(2), AC-2(7), AC-2(9), AC-2(10), AC-12(1), IA-2(5), MA-4, SC-12(1) | | pcidss | Req-2.1 | | app-srg-ctr | SRG-APP-000023-CTR-000055, CNTR-OS-000030, CNTR-OS-000040, CNTR-OS-000440 | | cis | 3.1.1, 5.1.1 | | bsi | APP.4.4.A3 | | pcidss4 | 2.2.1, 2.2.2, 2.2, 8.2.2, 8.2, 8.3 | | stigref | SV-257507r921464_rule, SV-257508r921467_rule, SV-257542r921569_rule |
| |
|
Rule
Ensure that the OpenShift OAuth login template is set
[ref] | A legal notice can be configured via a customized login template.
This is achievable via the OAuth object by creating a custom login page,
storing it in a Kubernetes Secret and referencing it in the appropriate
field as
described in the documentation
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the 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: | Displays to users organization-defined system use notification message or banner before granting
access to the system that provides privacy and security notices consistent with applicable federal laws. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_oauth_login_template_set | | Identifiers: | CCE-84198-1 | | References: | | |
|
Rule
Ensure that the OpenShift OAuth logout URL is set
[ref] | The user can be redirected to a configured URL upon logout
This is achievable via the OAuth object by setting the logoutRedirect
attribute. Refer to
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 /apis/config.openshift.io/v1/consoles/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/consoles/cluster file. | | Rationale: | The web console's default logout will invalidate the user's session token
and redirect back to the console page, which will redirect the user to
the authentication page. There is no explicit logout message. And in
addition, if the IdP provider type is OIDC, the session token from the
SSO provider will remain valid, which would effectively keep the user
logged in. To correct this, the web console needs to be configured
to redirect the user to a logout page. If using an OIDC provider, this
would be the logout page for that provider. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_oauth_logout_url_set | | Identifiers: | CCE-90780-8 | | References: | | |
|
Rule
Ensure that the OpenShift OAuth provider selection is set
[ref] | Custom login pages can be helpful to show users a branded page that they
trust and expect before being redirected to the authentication provider.
This is achievable via the OAuth object by creating a custom login template,
storing it in a Kubernetes Secret and referencing it in the appropriate
field as
described in the documentation
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the 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: | Displays to users organization-defined IdP selection | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_oauth_provider_selection_set | | Identifiers: | CCE-90666-9 | | References: | | |
|
Rule
Ensure that the OpenShift MOTD is set
[ref] | To configure OpenShift's MOTD, create a ConfigMap called motd
in the openshift namespace.
The object should look as follows:
---
apiVersion: v1
kind: ConfigMap
metadata:
name: motd
namespace: openshift
data:
message: "A relevant MOTD"
Where message is a mandatory key.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreement.
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /api/v1/namespaces/openshift/configmaps/motd API endpoint to the local /kubernetes-api-resources/api/v1/namespaces/openshift/configmaps/motd file. | | Rationale: | Display of a standardized and approved use notification before granting
access to the system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_openshift_motd_exists | | Identifiers: | CCE-84200-5 | | References: | | |
|
Rule
Ensure that project templates autocreate Resource Quotas
[ref] |
Configure a template for newly created projects to use default resource
quotas and make sure this template is referenced from the default
project template.
The OpenShift Container Platform API server automatically provisions
new projects based on the project template that is identified by
the projectRequestTemplate parameter in the cluster’s project
configuration resource.
As a cluster administrator, you can modify the default project template
so that new projects created would satisfy the chosen compliance
standards.
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 /apis/config.openshift.io/v1/projects/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/projects/cluster file.
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/template.openshift.io/v1/namespaces/openshift-config/templates
API endpoint, filter with with the jq utility using the following filter
[.items[] | any(.objects[]?; .kind == "ResourceQuota") ]
and persist it to the local
/kubernetes-api-resources/apis/template.openshift.io/v1/namespaces/openshift-config/templates#e60f58ef612a182073e9f6fe0ebe9ea96a706422dc65572af8d6aa9839d94f61
file.
| | Rationale: |
Running different applications on the same Kubernetes cluster creates a risk of
a "noisy neighbor" when one application monopolizes cluster resources.
A resource quota, defined by a ResourceQuota object, provides constraints
that limit aggregate resource consumption per project. It can limit
the quantity of objects that can be created in a project by type, as
well as the total amount of compute resources and storage that might
be consumed by resources in that project.
Editing the default project template to include ResourceQuotas in
all new namespaces ensures that all namespaces include at least some
ResourceQuotas objects.
Ensuring that the project configuration references
a project template that sets up the required objects for new projects ensures
that all new projects will be set in accordance with centralized settings.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_project_config_and_template_resource_quota | | Identifiers: | CCE-90734-5 | | References: | | nist | SC-5, SC-5(1) | | app-srg-ctr | SRG-APP-000246-CTR-000605, SRG-APP-000435-CTR-001070, CNTR-OS-000620, CNTR-OS-000630, CNTR-OS-000800, CNTR-OS-000810 | | bsi | SYS.1.6.A15 | | stigref | SV-257554r921605_rule, SV-257555r921608_rule, SV-257565r921638_rule, SV-257566r921641_rule |
| |
|
Rule
Ensure workloads use resource requests and limits per namespace
[ref] |
There are two ways to enable resource requests and limits. To create either:
A multi-project quota, defined by a ClusterResourceQuota object, allows quotas
to be shared across multiple projects. Resources used in each selected project
are aggregated and that aggregate is used to limit resources across all the
selected projects.
A resource quota, defined by a ResourceQuota object, provides constraints that
limit aggregate resource consumption per project. It can limit the quantity of
objects that can be created in a project by type, as well as the total amount
of compute resources and storage that might be consumed by resources in that project.
We want to make sure either a ClusterResourceQuota is used in a cluster or a ResourceQuota
is used per namespaces.
To configure ClusterResourceQuota, follow the directions in
the documentation
To configure ResourceQuota Per Project, follow the directions in
the documentation
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
/api/v1/resourcequotas
API endpoint, filter with with the jq utility using the following filter
[.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default" and .metadata.namespace != "rhacs-operator" and ({{if ne .var_resource_requests_quota_per_project_exempt_regex "None"}}.metadata.namespace | test("{{.var_resource_requests_quota_per_project_exempt_regex}}") | not{{else}}true{{end}})) | .metadata.namespace] | unique
and persist it to the local
/kubernetes-api-resources/api/v1/resourcequotas#4326a181a1e3e8a8e02ffb58e7d3ca9e62ed0e144a5277b1f7551fdbcfeca0a8
file.
/api/v1/namespaces
API endpoint, filter with with the jq utility using the following filter
[.items[] | select((.metadata.name | startswith("openshift") | not) and (.metadata.name | startswith("kube-") | not) and .metadata.name != "default" and .metadata.name != "rhacs-operator" and ({{if ne .var_resource_requests_quota_per_project_exempt_regex "None"}}.metadata.name | test("{{.var_resource_requests_quota_per_project_exempt_regex}}") | not{{else}}true{{end}}))]
and persist it to the local
/kubernetes-api-resources/api/v1/namespaces#3ae63defe5cbb61225edb84d8e19f601be933d063305c1ea1e0381297c6258d6
file.
| | Rationale: | Resource quotas provide constraints that limit aggregate resource consumption
per project. This helps prevent resource starvation. When deploying your
application, it is important to tune based on memory and CPU consumption,
allocating enough resources for the application to function properly. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_resource_requests_quota_per_project | | Identifiers: | CCE-90582-8 | | References: | | nist | SC-5, SC-5(1), SC-5(2), SI-16 | | app-srg-ctr | SRG-APP-000246-CTR-000605, SRG-APP-000435-CTR-001070, SRG-APP-000450-CTR-001105, CNTR-OS-000620, CNTR-OS-000630, CNTR-OS-000800, CNTR-OS-000810, CNTR-OS-000860, CNTR-OS-000870 | | bsi | SYS.1.6.A15 | | stigref | SV-257554r921605_rule, SV-257555r921608_rule, SV-257565r921638_rule, SV-257566r921641_rule, SV-257568r921647_rule, SV-257569r921650_rule |
| |
|
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
OpenShift - Logging Settings
Group contains 4 rules |
[ref]
Contains evaluations for the cluster's logging configuration settings. |
Rule
Ensure that Audit Log Errors Emit Alerts
[ref] |
OpenShift audit works at the API server level, logging all requests coming to the server.
However, if API server instance is unable to write errors, an alert must be issued
in order for the organization to take a relevant action. e.g. shutting down that instance.
Kubernetes by default has metrics that enable one to write such alerts:
apiserver_audit_event_totalapiserver_audit_error_total
Such an example is shipped in OCP 4.9+
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: audit-errors
namespace: openshift-kube-apiserver
spec:
groups:
- name: apiserver-audit
rules:
- alert: AuditLogError
annotations:
summary: |-
An API Server instance was unable to write audit logs. This could be
triggered by the node running out of space, or a malicious actor
tampering with the audit logs.
description: An API Server had an error writing to an audit log.
expr: |
sum by (apiserver,instance)(rate(apiserver_audit_error_total{apiserver=~".+-apiserver"}[5m])) / sum by (apiserver,instance) (rate(apiserver_audit_event_total{apiserver=~".+-apiserver"}[5m])) > 0
for: 1m
labels:
severity: warning
For more information, consult the
official Kubernetes 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:
/apis/monitoring.coreos.com/v1/prometheusrules
API endpoint, filter with with the jq utility using the following filter
[.items[].spec.groups[].rules[].expr]
and persist it to the local
/kubernetes-api-resources/apis/monitoring.coreos.com/v1/prometheusrules#5fd5244e3dcae63319f7e86b918cb8ea6ce1b4124670ccb43750d7a75ca03cb7
file.
| | Rationale: | When there are errors writing audit logs, security events will not be logged
by that specific API Server instance. Security Incident Response teams use
these audit logs, amongst other artifacts, to determine the impact of
security breaches or events. Without these logs, it becomes very difficult
to assess a situation and do appropriate root cause analysis in such incidents. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_error_alert_exists | | Identifiers: | CCE-90744-4 | | References: | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AU-5 | | app-srg-ctr | SRG-APP-000109-CTR-000215, CNTR-OS-000200, CNTR-OS-000210 | | pcidss4 | 10.7.2, 10.7 | | stigref | SV-257522r921509_rule, SV-257523r921512_rule |
| |
|
Rule
Ensure that Audit Log Forwarding Uses TLS
[ref] |
OpenShift audit works at the API server level, logging all requests coming to the server.
Audit is on by default and the best practice is to ship audit logs off the cluster for retention
using a secure protocol.
The cluster-logging-operator is able to do this with the ClusterLogForwarders resource.
The forementioned resource can be configured to logs to different third party systems.
For more information on this, please reference the official documentation:
https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-clf.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 .
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/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance
API endpoint, filter with with the jq utility using the following filter
try [.spec.outputs[].url] catch []
and persist it to the local
/kubernetes-api-resources/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders/instance#71786452ba18c51ba8ad51472a078619e2e8b52a86cd75087af5aab42400f6c0
file.
true
/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders
API endpoint, filter with with the jq utility using the following filter
try [.items[].spec.outputs[][]|objects|.url] catch []
and persist it to the local
/kubernetes-api-resources/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders#276ca288b4b843cf4e126b67f8b26ab42dabe7c97d51fdb82eb7085a9e5522b1
file.
true
| | Rationale: | It is necessary to ensure that any configured output uses the TLS protocol to receive
logs in order to ensure the confidentiality, integrity and authenticity of the logs. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_log_forwarding_uses_tls | | Identifiers: | CCE-90688-3 | | References: | | nerc-cip | CIP-003-8 R5.2, CIP-004-6 R3.3, CIP-007-3 R6.5 | | nist | AU-9, AU-9(2), AU-9(3), AU-10 | | app-srg-ctr | SRG-APP-000126-CTR-000275, CNTR-OS-000340, CNTR-OS-000510 | | stigref | SV-257536r921551_rule, SV-257546r921581_rule |
| |
|
Rule
Ensure that the cluster's audit profile is properly set
[ref] |
OpenShift can audit the details of requests made to the API server through
the standard Kubernetes audit capabilities.
In OpenShift, auditing of the API Server is on by default. Audit provides a
security-relevant chronological set of records documenting the sequence of
activities that have affected system by individual users, administrators, or
other components of the system. Audit works at the API server level, logging
all requests coming to the server. Each audit log contains two entries:
The request line containing:
- A Unique ID allowing to match the response line (see #2)
- The source IP of the request
- The HTTP method being invoked
- The original user invoking the operation
- The impersonated user for the operation (self meaning himself)
- The impersonated group for the operation (lookup meaning user's group)
- The namespace of the request or none
- The URI as requested
The response line containing:
- The aforementioned unique ID
- The response code
For more information on how to configure the audit profile, please visit
the documentation
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /apis/config.openshift.io/v1/apiservers/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/apiservers/cluster file. | | Rationale: | Logging is an important detective control for all systems, to detect potential
unauthorised access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_profile_set | | Identifiers: | CCE-83577-7 | | References: | | nerc-cip | CIP-003-8 R4, CIP-003-8 R4.1, CIP-003-8 R4.2, CIP-003-8 R5.2, CIP-003-8 R6, CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-004-6 R3.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5 | | nist | AU-2, AU-3, AU-3(1), AU-6, AU-6(1), AU-7, AU-7(1), AU-8, AU-8(1), AU-9, AU-12, AU-12(1), AU-12(3), CM-5(1), SI-11, SI-12, SI-4(20), SI-4(23) | | pcidss | Req-2.2, Req-12.5.5 | | app-srg-ctr | SRG-APP-000089-CTR-000150, SRG-APP-000090-CTR-000155, SRG-APP-000101-CTR-000205, CNTR-OS-000150 | | cis | 3.2.2 | | pcidss4 | 2.2.1, 2.2, 10.2.2, 10.2 | | stigref | SV-257517r921494_rule |
| |
|
Rule
Ensure that OpenShift Logging Operator is scanning the cluster
[ref] | OpenShift Logging Operator provides ability to aggregate all the logs from the
OpenShift Container Platform cluster, such as node system audit logs, application
container logs, and infrastructure logs. OpenShift Logging aggregates these logs
from throughout OpenShift cluster and stores them in a default log store. [1]
[1]https://docs.openshift.com/container-platform/latest/observability/logging/logging-6.0/log6x-about.html Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterloggings/instance API endpoint to the local /kubernetes-api-resources/apis/logging.openshift.io/v1/namespaces/openshift-logging/clusterloggings/instance file /apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders API endpoint to the local /kubernetes-api-resources/apis/observability.openshift.io/v1/namespaces/openshift-logging/clusterlogforwarders file . | | Rationale: | OpenShift Logging Operator is able to collect, aggregate, and manage logs. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_cluster_logging_operator_exist | | Identifiers: | CCE-85918-1 | | References: | | nist | AU-3(2) | | app-srg-ctr | SRG-APP-000092-CTR-000165, SRG-APP-000111-CTR-000220, SRG-APP-000358-CTR-000805, CNTR-OS-000170, CNTR-OS-000220 | | stigref | SV-257519r921500_rule, SV-257524r921515_rule |
| |
|
| Group
Kubernetes - Network Configuration and Firewalls
Group contains 5 rules |
[ref]
Most systems must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
This section also discusses firewalls, network access
controls, and other network security frameworks, which allow
system-level rules to be written that can limit an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks. |
Rule
Ensure that the CNI in use supports Network Policies
[ref] | There are a variety of CNI plugins available for Kubernetes. If the CNI in
use does not support Network Policies it may not be possible to effectively
restrict traffic in the cluster. OpenShift supports Kubernetes NetworkPolicy
using a Kubernetes Container Network Interface (CNI) plug-in. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
/apis/operator.openshift.io/v1/networks/cluster
API endpoint, filter with with the jq utility using the following filter
[.spec.defaultNetwork.type]
and persist it to the local
/kubernetes-api-resources/apis/operator.openshift.io/v1/networks/cluster#35e33d6dc1252a03495b35bd1751cac70041a511fa4d282c300a8b83b83e3498
file.
| | Rationale: | Kubernetes network policies are enforced by the CNI plugin in use. As such
it is important to ensure that the CNI plugin supports both Ingress and
Egress network policies. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_network_policies | | References: | | nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1 | | nist | CM-6, CM-6(1) | | pcidss | Req-1.1.4, Req-1.2, Req-2.2 | | app-srg-ctr | SRG-APP-000038-CTR-000105, CNTR-OS-000100 | | cis | 5.3.1 | | bsi | APP.4.4.A7, APP.4.4.A18, SYS.1.6.A5, SYS.1.6.A21 | | pcidss4 | 1.4.1, 1.4, 2.2.1, 2.2 | | stigref | SV-257514r921485_rule |
| |
|
Rule
Ensure that application Namespaces have Network Policies defined.
[ref] | Use network policies to isolate traffic in your cluster network. Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the following:
/apis/networking.k8s.io/v1/networkpolicies
API endpoint, filter with with the jq utility using the following filter
[.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default" and ({{if ne .var_network_policies_namespaces_exempt_regex "None"}}.metadata.namespace | test("{{.var_network_policies_namespaces_exempt_regex}}") | not{{else}}true{{end}})) | .metadata.namespace] | unique
and persist it to the local
/kubernetes-api-resources/apis/networking.k8s.io/v1/networkpolicies#7400bb301fff2f7fc7b1b0fb7448b8e3f15222a8d23f992204315b19eeefa72f
file.
/api/v1/namespaces
API endpoint, filter with with the jq utility using the following filter
[.items[] | select((.metadata.name | startswith("openshift") | not) and (.metadata.name | startswith("kube-") | not) and .metadata.name != "default" and ({{if ne .var_network_policies_namespaces_exempt_regex "None"}}.metadata.name | test("{{.var_network_policies_namespaces_exempt_regex}}") | not{{else}}true{{end}}))]
and persist it to the local
/kubernetes-api-resources/api/v1/namespaces#f673748db2dd4e4f0ad55d10ce5e86714c06da02b67ddb392582f71ef81efab2
file.
| | Rationale: | Running different applications on the same Kubernetes cluster creates a risk of one
compromised application attacking a neighboring application. Network segmentation is
important to ensure that containers can communicate only with those they are supposed
to. When a network policy is introduced to a given namespace, all traffic not allowed
by the policy is denied. However, if there are no network policies in a namespace all
traffic will be allowed into and out of the pods in that namespace. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_network_policies_namespaces | | References: | | nerc-cip | CIP-003-8 R4, CIP-003-8 R4.2, CIP-003-8 R5, CIP-003-8 R6, CIP-004-6 R2.2.4, CIP-004-6 R3, CIP-007-3 R2, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R6.1 | | nist | AC-4, AC-4(21), CA-3(5), CM-6, CM-6(1), CM-7, CM-7(1), SC-7, SC-7(3), SC-7(5), SC-7(8), SC-7(12), SC-7(13), SC-7(18), SC-7(10), SI-4(22) | | pcidss | Req-1.1.4, Req-1.2, Req-1.2.1, Req-1.3.1, Req-1.3.2, Req-2.2 | | app-srg-ctr | SRG-APP-000038-CTR-000105, CNTR-OS-000100 | | cis | 5.3.2 | | bsi | APP.4.4.A7, APP.4.4.A18, SYS.1.6.A5, SYS.1.6.A21 | | pcidss4 | 1.2.6, 1.2, 1.3.1, 1.3, 1.4.1, 1.4, 2.2.1, 2.2 | | stigref | SV-257514r921485_rule |
| |
|
Rule
Ensure IngressController is configured to use secure tlsSecurityProfile
[ref] |
The configuration tlsSecurityProfile specifies TLS configurations
to be used while establishing connections with the externally exposed
servers. Though secure transport mode is used for establishing connections,
the protocols used may not always be strong enough to avoid interception and
manipulation of the data in transport. TLS Security profile configured should
not make use of any protocols, ciphers, and algorithms with known security
vulnerabilities.
tlsSecurityProfile can be configured to use one of custom, intermediate,
modern, or old profile. Profile Old should be avoided at all times and when using
custom profile one should be extremely careful as invalid configurations can be
catastrophic. It is always advised to use highly secure intermediate or modern
profiles and if unset profile configured in apiservers.config.openshift.io/cluster
resource will be used as default.
To update tlsSecurityProfile to Intermediate use the following command:
oc patch -n openshift-ingress-operator ingresscontrollers.operator.openshift.io default --type 'json' --patch '[{"op": "add", "path": "/spec/tlsSecurityProfile/intermediate", "value": {}}, {"op": "replace", "path": "/spec/tlsSecurityProfile/type", "value": "Intermediate"}'
For more information, follow
OpenShift documentation:
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 /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default API endpoint to the local /kubernetes-api-resources/apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default file. | | Rationale: | The authenticity and integrity of the container platform and communication
between nodes and components must be secure. If an insecure protocol,
cipher, or algorithms is used, during transmission of data, the data can be
intercepted and manipulated. To thwart the manipulation of the data during
transmission secure protocol, cipher and algorithms must be used. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_ingress_controller_tls_security_profile | | Identifiers: | CCE-86234-2 | | References: | | |
|
Rule
Ensure that project templates autocreate Network Policies
[ref] | Configure a template for newly created projects to use default network
policies and make sure this template is referenced from the default
project template.
The OpenShift Container Platform API server automatically provisions
new projects based on the project template that is identified by
the projectRequestTemplate parameter in the cluster’s project
configuration resource.
As a cluster administrator, you can modify the default project template
so that new projects created would satisfy the chosen compliance
standards.
For more information on configuring default network policies, 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 /apis/config.openshift.io/v1/projects/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/projects/cluster file.
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/template.openshift.io/v1/namespaces/openshift-config/templates
API endpoint, filter with with the jq utility using the following filter
[.items[] | any(.objects[]?; .kind == "NetworkPolicy") ]
and persist it to the local
/kubernetes-api-resources/apis/template.openshift.io/v1/namespaces/openshift-config/templates#8044d7f899788c96acdbb06244837a64dfa1e0973c59b2ad26596e080e12482d
file.
| | Rationale: | Running different applications on the same Kubernetes cluster creates a risk of one
compromised application attacking a neighboring application. Network segmentation is
important to ensure that containers can communicate only with those they are supposed
to. When a network policy is introduced to a given namespace, all traffic not allowed
by the policy is denied.
Editing the default project template to include NetworkPolicies in
all new namespaces ensures that all namespaces include at least some
NetworkPolicy objects.
Ensuring that the project configuration references
a project template that sets up the required objects for new projects ensures
that all new projects will be set in accordance with centralized settings. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_project_config_and_template_network_policy | | Identifiers: | CCE-86070-0 | | References: | | app-srg-ctr | SRG-APP-000039-CTR-000110, CNTR-OS-000110 | | bsi | APP.4.4.A7, APP.4.4.A18 | | stigref | SV-257515r921488_rule |
| |
|
Rule
Ensure that all Routes has rate limit enabled
[ref] | OpenShift has an option to set the rate limit for Routes [1] when creating new Routes.
All routes outside the openshift namespaces and the kube namespaces should use the
rate-limiting annotations.
[1] https://docs.openshift.com/container-platform/4.9/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration 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/route.openshift.io/v1/routes?limit=500
API endpoint, filter with with the jq utility using the following filter
[.items[] | select(.metadata.namespace | startswith("kube-") or startswith("openshift-") | not) | select(.metadata.annotations["haproxy.router.openshift.io/rate-limit-connections"] == "true" | not) | .metadata.name]
and persist it to the local
/kubernetes-api-resources/apis/route.openshift.io/v1/routes?limit=500#842fa6716f17342d62e70f2755db709b9d7a161cf0338ea8bfae9b06dab5e6cc
file.
| | Rationale: | The usage of rate limit for Routes provides basic protection against distributed denial-of-service (DDoS) attacks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_routes_rate_limit | | Identifiers: | CCE-90779-0 | | References: | | nist | SC-5, SC-5(1), SC-5(2) | | app-srg-ctr | SRG-APP-000246-CTR-000605, SRG-APP-000435-CTR-001070, CNTR-OS-000620, CNTR-OS-000630, CNTR-OS-000800, CNTR-OS-000810 | | stigref | SV-257554r921605_rule, SV-257555r921608_rule, SV-257565r921638_rule, SV-257566r921641_rule |
| |
|
| Group
Role-based Access Control
Group contains 4 rules |
[ref]
Role-based access control (RBAC) objects determine
whether a user is allowed to perform a given action
within a project.
Cluster administrators can use the cluster roles and
bindings to control who has various access levels to
the OpenShift Container Platform platform itself
and all projects.
Developers can use local roles and bindings to control
who has access to their projects. Note that authorization
is a separate step from authentication, which is more
about determining the identity of who is taking the action. |
Rule
Ensure that the RBAC setup follows the principle of least privilege
[ref] | Role-based access control (RBAC) objects determine whether a user is
allowed to perform a given action within a project.
If users or groups exist that are bound to roles they must not have, modify the user or group permissions using the following cluster and local role binding commands:
Remove a User from a Cluster RBAC role by executing the following:
oc adm policy remove-cluster-role-from-user role username
Remove a Group from a Cluster RBAC role by executing the following:
oc adm policy remove-cluster-role-from-group role groupname
Remove a User from a Local RBAC role by executing the following:
oc adm policy remove-role-from-user role username
Remove a Group from a Local RBAC role by executing the following:
oc adm policy remove-role-from-group role groupname
NOTE: For additional information. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html | | Rationale: | Controlling and limiting users access to system services and resources
is key to securing the platform and limiting the intentional or
unintentional comprimising of the system and its services. OpenShift
provides a robust RBAC policy system that allows for authorization
policies to be as detailed as needed. Additionally there are two layers
of RBAC policies, the first is Cluster RBAC policies which administrators
can control who has what access to cluster level services. The other is
Local RBAC policies, which allow project developers/administrators to
control what level of access users have to a given project or namespace. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_rbac_least_privilege | | Identifiers: | CCE-90678-4 | | References: | | nist | AC-3, CM-5(6), IA-2, IA-2(5), AC-6(10), CM-11(2), CM-5(1), CM-7(5)(b) | | app-srg-ctr | SRG-APP-000033-CTR-000090, SRG-APP-000033-CTR-000095, SRG-APP-000033-CTR-000100, SRG-APP-000133-CTR-000290, SRG-APP-000133-CTR-000295, SRG-APP-000133-CTR-000300, SRG-APP-000133-CTR-000305, SRG-APP-000133-CTR-000310, SRG-APP-000148-CTR-000350, SRG-APP-000153-CTR-000375, SRG-APP-000340-CTR-000770, SRG-APP-000378-CTR-000880, SRG-APP-000378-CTR-000885, SRG-APP-000378-CTR-000890, SRG-APP-000380-CTR-000900, SRG-APP-000386-CTR-000920, CNTR-OS-000090 | | cis | 5.2.10 | | bsi | APP.4.4.A3, APP.4.4.A7, APP.4.4.A9, SYS.1.6.A8, SYS.1.6.A19 | | pcidss4 | 2.2.1, 2.2 | | stigref | SV-257513r921482_rule |
| |
|
Rule
Ensure that the ClusterLogging and ClusterLoggingForwarder resources are protected from unauthorized deletion
[ref] | The ClusterLogging and ClusterLoggingForwarder Custom Resources provide
a way to configure the logging forwarding subsystem and delete access to it
should be restricted to as-needed basis.
Remove delete permissions from any unauthorized user or group by performing one or more of the following commands:
* Remove role from user
> oc adm policy remove-role-from-user ROLE USER -n openshift-logging
* Remove role from group
> oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging
* Remove cluster role from user
> oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging
* Remove cluster role from group
> oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging
Where ROLE/CLUSTER_ROLE is the role granting user delete permission to resources in openshift-logging namespace.} | | Rationale: | Protecting audit data also includes identifying and protecting the tools used to view and
manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized
operation on audit data. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rbac_logging_del | | Identifiers: | CCE-90433-4 | | References: | | |
|
Rule
Ensure that the ClusterLogging and ClusterLoggingForwarder resources are protected from unauthorized modification
[ref] | The ClusterLogging and ClusterLoggingForwarder Custom Resources provide
a way to configure the logging forwarding subsystem and modification access to it
should be restricted to as-needed basis.
Remove edit permissions from any unauthorized user or group by performing one or more of the following commands:
* Remove role from user
> oc adm policy remove-role-from-user ROLE USER -n openshift-logging
* Remove role from group
> oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging
* Remove cluster role from user
> oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging
* Remove cluster role from group
> oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging
Where ROLE/CLUSTER_ROLE is the role granting user edit permission to resources in openshift-logging namespace.} | | Rationale: | Protecting audit data also includes identifying and protecting the tools used to view and
manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized
operation on audit data. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rbac_logging_mod | | Identifiers: | CCE-90717-0 | | References: | | |
|
Rule
Ensure that the ClusterLogging and ClusterLoggingForwarder resources are protected from unauthorized access
[ref] | The ClusterLogging and ClusterLoggingForwarder Custom Resources provide
a way to configure the logging forwarding subsystem and view access to it
should be restricted to as-needed basis.
Remove view permissions from any unauthorized user or group by performing one or more of the following commands:
* Remove role from user
> oc adm policy remove-role-from-user ROLE USER -n openshift-logging
* Remove role from group
> oc adm policy remove-role-from-group ROLE GROUP -n openshift-logging
* Remove cluster role from user
> oc adm policy remove-cluster-role-from-user CLUSTER_ROLE USER -n openshift-logging
* Remove cluster role from group
> oc adm policy remove-cluster-role-from-group CLUSTER_ROLE GROUP -n openshift-logging
Where ROLE/CLUSTER_ROLE is the role granting user view permission to resources in openshift-logging namespace.} | | Rationale: | Protecting audit data also includes identifying and protecting the tools used to view and
manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized
operation on audit data. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rbac_logging_view | | Identifiers: | CCE-90648-7 | | References: | | nist | AU-9 | | app-srg-ctr | SRG-APP-000121-CTR-000255, CNTR-OS-000320, CNTR-OS-000330 | | stigref | SV-257534r921545_rule, SV-257535r921548_rule |
| |
|
| Group
Kubernetes - Registry Security Practices
Group contains 6 rules |
[ref]
Contains evaluations for Kubernetes registry security practices, and cluster-wide registry configuration. |
Rule
Configure ImagePruner so that images that are no longer needed are automatically removed
[ref] | 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/imageregistry.operator.openshift.io/v1/imagepruners/cluster API endpoint to the local /kubernetes-api-resources/apis/imageregistry.operator.openshift.io/v1/imagepruners/cluster file. | | Rationale: |
Obsolete and stale images need to be removed from the registry to ensure
the container platform maintains a secure posture. While the storing of
these images does not directly pose a threat, they do increase the likelihood
of these images being deployed.
Removing stale or obsolete images and only keeping the most recent versions
of those that are still in use removes any possibility of vulnerable images being deployed.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_image_pruner_active | | Identifiers: | CCE-86480-1 | | References: | | nist | SI-2(6) | | app-srg-ctr | SRG-APP-000454-CTR-001110, SRG-APP-000454-CTR-001115, CNTR-OS-000880 | | stigref | SV-257570r921653_rule |
| |
|
Rule
All configured ImageStreams are configured to periodically check for updates
[ref] |
The configuration imagestream.spec.tags.importPolicy.scheduled
determines whether the imagestream is configured to periodically check
for updates. This is useful when working with an external container
image registry, to periodically re-import an image, for example to
get latest security updates.
You can set the scheduled update by calling:
$ oc patch imagestream NAME -n NAMESPACE --type merge -p '{"spec":{"tags":[{"name":"TAG_NAME","importPolicy":{"scheduled":true}}]}}'
For more information, follow the
ImageStreams 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:
/apis/image.openshift.io/v1/imagestreams
API endpoint, filter with with the jq utility using the following filter
[.items[] | .spec.tags[]? | select(.from.kind != "ImageStreamTag") | (.importPolicy.scheduled != null and .importPolicy.scheduled != false)] | all
and persist it to the local
/kubernetes-api-resources/apis/image.openshift.io/v1/imagestreams#fbe2637b570482a77a9b52dc0c9c94eeb918519c0b64368ffbf3acfa02fc166f
file.
| | Rationale: | Periodical refresh of container images helps keep the images up-to-date
and apply any relevant updates in a timely manner. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_imagestream_sets_schedule | | References: | | nist | SI-2(c) | | app-srg-ctr | SRG-APP-000456-CTR-001125, CNTR-OS-000890, CNTR-OS-000900 | | stigref | SV-257571r921656_rule, SV-257572r921659_rule |
| |
|
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 | | bsi | SYS.1.6.A6, SYS.1.6.A12 | | pcidss4 | 2.2.1, 2.2 | | 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 | | bsi | SYS.1.6.A6, SYS.1.6.A12 | | pcidss4 | 2.2.1, 2.2 | | stigref | SV-257571r921656_rule, SV-257572r921659_rule |
| |
|
Rule
Check configured allowed registries for import uses secure protocol
[ref] | The configuration allowedRegistriesForImport limits the container
image registries from which normal users may import images. This is a list
of the registries that can be trusted to contain valid images and the image
location configured is assumed to be secured unless configured otherwise. It
is important to allow only secure registries to avoid man in the middle attacks,
as the insecure image import request can be impersonated and could lead to
fetching malicious content.
List all the allowed repositories for import configured with insecure set to true
using the following command:
oc get image.config.openshift.io/cluster -o json | jq '.spec | (.allowedRegistriesForImport[])? | select(.insecure==true)'
Remove or edit the listed registries having insecure set by using the command:
oc edit image.config.openshift.io/cluster
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 /apis/config.openshift.io/v1/images/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/images/cluster file. | | Rationale: | Configured list of allowed registries for import should be from the secure source. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_ocp_insecure_allowed_registries_for_import | | Identifiers: | CCE-86235-9 | | References: | | |
|
Rule
Check if any insecure registry sources is configured
[ref] | The configuration registrySources.insecureRegistries determines the
insecure registries that the OpenShift container runtime can access for builds
and pods. This configuration setting is for accessing the configured registries
without TLS validation which could lead to security breaches and should be
avoided.
Remove any insecureRegistries configured using the following command:
oc patch image.config.openshift.io cluster --type=json -p "[{'op': 'remove', 'path': '/spec/registrySources/insecureRegistries'}]"
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 /apis/config.openshift.io/v1/images/cluster API endpoint to the local /kubernetes-api-resources/apis/config.openshift.io/v1/images/cluster file. | | Rationale: | Insecure registries should not be configured, which would restrict the possibilities of
OpenShift container runtime accessing registries which cannot be validated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_ocp_insecure_registries | | Identifiers: | CCE-86123-7 | | References: | | |
|
| Group
OpenShift - Risk Assessment Settings
Group contains 3 rules |
[ref]
Contains evaluations for the cluster's risk assessment configuration settings. |
Rule
Make sure the Container Security Operator is installed
[ref] |
Using the Red Hat Quay Container Security Operator, you can access
vulnerability scan results from the OpenShift Container Platform web
console for container images used in active pods on the cluster. The
Red Hat Quay Container Security Operator:
- Watches containers associated with pods on all or specified namespaces
- Queries the container registry where the containers came from
for vulnerability information, provided an image’s registry is
running image scanning (such as Quay.io or a Red Hat Quay registry
with Clair scanning)
- Exposes vulnerabilities via the ImageManifestVuln object in the
Kubernetes API
For more information on the Container Security Operator, follow the
OpenShift documentation:
https://docs.openshift.com/container-platform/latest/security/pod-vulnerability-scan.html
Warning:
This rule's check operates on the cluster configuration dump.
Therefore, you need to use a tool that can query the OCP API, retrieve the /apis/operators.coreos.com/v1alpha1/namespaces/openshift-operators/subscriptions/container-security-operator API endpoint to the local /kubernetes-api-resources/apis/operators.coreos.com/v1alpha1/namespaces/openshift-operators/subscriptions/container-security-operator file. | | Rationale: | Vulnerabilities in software packages can be exploited by hackers or malicious
users to obtain unauthorized access to resources. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_container_security_operator_exists | | Identifiers: | CCE-90613-1 | | References: | | |
|
Rule
Ensure that Compliance Operator is scanning the cluster
[ref] | The Compliance Operator
scans the hosts and the platform (OCP)
configurations for software flaws and improper configurations according
to different compliance benchmarks. It uses OpenSCAP as a backend,
which is a known and certified tool to do such scans. 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/compliance.openshift.io/v1alpha1/scansettingbindings?limit=5 API endpoint to the local /kubernetes-api-resources/apis/compliance.openshift.io/v1alpha1/scansettingbindings?limit=5 file. | | Rationale: | Vulnerability scanning and risk management are important detective controls
for all systems, to detect potential flaws and unauthorised access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scansettingbinding_exists | | Identifiers: | CCE-83697-3 | | References: | | nerc-cip | CIP-003-8 R1.3, CIP-003-8 R4.3, CIP-003-8 R6, CIP-004-6 4.1, CIP-004-6 4.2, CIP-004-6 R3, CIP-004-6 R4, CIP-004-6 R4.2, CIP-005-6 R1, CIP-005-6 R1.1, CIP-005-6 R1.2, CIP-007-3 R3, CIP-007-3 R3.1, CIP-007-3 R6.1, CIP-007-3 R8.4 | | nist | CM-6, CM-6(1), RA-5, RA-5(5), SA-4(8) | | pcidss | Req-2.2.4 | | app-srg-ctr | SRG-APP-000472-CTR-001170, CNTR-OS-000910 | | bsi | APP.4.4.A13 | | pcidss4 | 2.2.1, 2.2.6, 2.2 | | stigref | SV-257573r921662_rule |
| |
|
Rule
Ensure that Compliance Operator scans are running periodically
[ref] | The Compliance Operator
scans the hosts and the platform (OCP)
configurations for software flaws and improper configurations according
to different compliance benchmarks. Compliance Operator allows its
scans to be scheduled periodically using the ScanSetting
Custom Resource. 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/compliance.openshift.io/v1alpha1/scansettings
API endpoint, filter with with the jq utility using the following filter
[.items[]] | map(.schedule != "" and .schedule != null)
and persist it to the local
/kubernetes-api-resources/apis/compliance.openshift.io/v1alpha1/scansettings#c9e8242304a62f077a87b2b045f62b01340e80a8798e58477faa58c06e918211
file.
| | Rationale: | Without periodical scanning and verification, security functions may
not operate correctly and this failure may go unnoticed within the container platform. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scansettings_have_schedule | | Identifiers: | CCE-90762-6 | | References: | | |
|
| Group
Security Context Constraints (SCC)
Group contains 7 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 Containers Ability to use the HostDir volume plugin
[ref] | Containers should be allowed to use the hostPath volume type unless
necessary. To prevent containers from using the host filesystem
the appropriate Security Context Constraints (SCCs) should set
allowHostDirVolumePlugin to false. | | Rationale: | hostPath volumes allow workloads to access the host filesystem
from the workload. Access to the host filesystem can be used to
escalate privileges and access resources such as keys or access
tokens.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_host_dir_volume_plugin | | Identifiers: | CCE-86255-7 | | References: | | nist | AC-6, AC-6(1) | | app-srg-ctr | SRG-APP-000142-CTR-000330, CNTR-OS-000660 | | cis | 5.2.12 | | bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A18, SYS.1.6.A19, SYS.1.6.A21 | | stigref | SV-257557r921614_rule |
| |
|
Rule
Limit Containers Ability to bind to privileged ports
[ref] | Containers should be limited to bind to non-privileged ports directly
on the hosts. To prevent containers from binding to privileged ports
on the host the appropriate Security Context Constraints (SCCs)
should set allowHostPorts to false. | | Rationale: | Privileged ports are those ports below 1024 and that require system
privileges for their use. If containers are able to use these ports,
the container must be run as a privileged user. The container platform
must stop containers that try to map to these ports directly. Allowing
non-privileged ports to be mapped to the container-privileged port
is the allowable method when a certain port is needed. An example is
mapping port 8080 externally to port 80 in the container. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_host_ports | | Identifiers: | CCE-86205-2 | | References: | | |
|
Rule
Limit Access to the Host IPC Namespace
[ref] | Containers should not be allowed access to the host's Interprocess Communication (IPC)
namespace. To prevent containers from getting access to a host's
IPC namespace, the appropriate Security Context Constraints (SCCs)
should set allowHostIPC to false. | | Rationale: | A container running in the host's IPC namespace can use IPC
to interact with processes outside the container potentially
allowing an attacker to exploit a host process thereby enabling an
attacker to exploit other services. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_ipc_namespace | | Identifiers: | CCE-84042-1 | | References: | | nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1 | | nist | CM-6, CM-6(1) | | pcidss | Req-2.2 | | app-srg-ctr | SRG-APP-000516-CTR-001325, CNTR-OS-000660 | | cis | 5.2.3 | | bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A18, SYS.1.6.A21 | | pcidss4 | 2.2.1, 2.2 | | stigref | SV-257557r921614_rule |
| |
|
Rule
Limit Access to the Host Network Namespace
[ref] | Containers should not be allowed access to the host's network
namespace. To prevent containers from getting access to a host's
network namespace, the appropriate Security Context Constraints (SCCs)
should set allowHostNetwork to false. | | Rationale: | A container running in the host's network namespace could
access the host network traffic to and from other pods
potentially allowing an attacker to exploit pods and network
traffic. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_network_namespace | | Identifiers: | CCE-83492-9 | | References: | | nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1 | | nist | CM-6, CM-6(1) | | pcidss | Req-2.2 | | app-srg-ctr | SRG-APP-000142-CTR-000330, CNTR-OS-000660 | | cis | 5.2.4 | | bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A18, SYS.1.6.A21 | | pcidss4 | 2.2.1, 2.2 | | stigref | SV-257557r921614_rule |
| |
|
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: | | nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1 | | nist | CM-6, CM-6(1) | | pcidss | Req-2.2 | | app-srg-ctr | SRG-APP-000342-CTR-000775, SRG-APP-000142-CTR-000330, CNTR-OS-000660 | | cis | 5.2.1 | | bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A18, SYS.1.6.A21 | | pcidss4 | 2.2.1, 2.2 | | stigref | SV-257557r921614_rule |
| |
|
Rule
Limit Access to the Host Process ID Namespace
[ref] | Containers should not be allowed access to the host's process
ID namespace. To prevent containers from getting access to a host's
process ID namespace, the appropriate Security Context Constraints (SCCs)
should set allowHostPID to false. | | Rationale: | A container running in the host's PID namespace can inspect
processes running outside the container which can be used to
escalate privileges outside of the container. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_scc_limit_process_id_namespace | | References: | | nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1 | | nist | CM-6, CM-6(1) | | pcidss | Req-2.2 | | app-srg-ctr | SRG-APP-000516-CTR-001325, CNTR-OS-000660 | | cis | 5.2.2 | | bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A18, SYS.1.6.A21 | | pcidss4 | 2.2.1, 2.2 | | stigref | SV-257557r921614_rule |
| |
|
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: | | nerc-cip | CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1 | | nist | CM-6, CM-6(1) | | pcidss | Req-2.2 | | app-srg-ctr | SRG-APP-000342-CTR-000775, CNTR-OS-000660 | | cis | 5.2.6 | | bsi | APP.4.4.A4, APP.4.4.A9, SYS.1.6.A16, SYS.1.6.A18, SYS.1.6.A21 | | pcidss4 | 2.2.1, 2.2 | | stigref | SV-257557r921614_rule |
| |
|