Group
Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4
Group contains 5 groups and 7 rules |
Group
Kubernetes Settings
Group contains 4 groups and 7 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 1 rule |
[ref]
This section contains recommendations for kube-apiserver configuration. |
Rule
Ensure that anonymous requests to the API Server are authorized
[ref] | By default, anonymous access to the OpenShift API is enabled, but at
the same time, all requests must be authorized. If no authentication
mechanism is used, the request is assigned the system:anonymous
virtual user and the system:unauthenticated virtual group.
This allows the authorization layer to determine which requests, if any,
is an anonymous user authorized to make.
To verify the authorization rules for anonymous requests run the following:
$ oc describe clusterrolebindings
and inspect the bindings of the system:anonymous
virtual user and the system:unauthenticated virtual group.
To test that an anonymous request is authorized to access the readyz
endpoint, run:
$ oc get --as="system:anonymous" --raw='/readyz?verbose'
In contrast, a request to list all projects should not be authorized:
$ oc get --as="system:anonymous" projects 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/rbac.authorization.k8s.io/v1/clusterrolebindings API endpoint to the local /kubernetes-api-resources/apis/rbac.authorization.k8s.io/v1/clusterrolebindings file. | Rationale: | When enabled, requests that are not rejected by other configured
authentication methods are treated as anonymous requests. These requests
are then served by the API server. If you are using RBAC authorization,
it is generally considered reasonable to allow anonymous access to the
API Server for health checks and discovery purposes, and hence this
recommendation is not scored. However, you should consider whether
anonymous discovery is an acceptable risk for your purposes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_api_server_anonymous_auth | Identifiers and References | References:
CIP-003-8 R6, CIP-004-6 R3, CIP-007-3 R6.1, CM-6, CM-6(1), Req-2.2, SRG-APP-000516-CTR-001325, 1.2.1 | |
|
Group
Kubernetes - General Security Practices
Group contains 3 rules |
[ref]
Contains evaluations for general security practices for operating a Kubernetes environment. |
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 documentationWarning:
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 and References | Identifiers:
CCE-90387-2 References:
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, AC-2(2), AC-2(7), AC-2(9), AC-2(10), AC-12(1), IA-2(5), MA-4, SC-12(1), Req-2.1, SRG-APP-000023-CTR-000055, 3.1.1, 5.1.1 | |
|
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 | Identifiers and References | | |
|
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 | Identifiers and References | | |
|
Group
Role-based Access Control
Group contains 1 rule |
[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 and References | Identifiers:
CCE-90678-4 References:
AC-3, CM-5(6), IA-2, IA-2(5), AC-6(10), CM-11(2), CM-5(1), CM-7(5)(b), 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, 5.2.10 | |
|
Group
Kubernetes - Registry Security Practices
Group contains 2 rules |
[ref]
Contains evaluations for Kubernetes registry security practices, and cluster-wide registry configuration. |
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 and References | Identifiers:
CCE-86235-9 References:
APP.4.4.A12, CM-5(3), SRG-APP-000014-CTR-000035, 5.5.1 | |
|
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 and References | Identifiers:
CCE-86123-7 References:
APP.4.4.A12, CM-5(3), SRG-APP-000014-CTR-000035, 5.5.1 | |
|