diff --git a/controls/stig_ocp4.yml b/controls/stig_ocp4.yml index 24c278e48ff4..bbf42091031b 100644 --- a/controls/stig_ocp4.yml +++ b/controls/stig_ocp4.yml @@ -2,7 +2,7 @@ policy: Red Hat OpenShift Container Platform 4.12 Security Technical Implementation Guide title: Red Hat OpenShift Container Platform 4.12 Security Technical Implementation Guide id: stig_ocp4 -version: V2R2 +version: V2R6 source: https://www.cyber.mil/stigs/downloads/ reference_type: stigid @@ -117,7 +117,7 @@ controls: - id: CNTR-OS-000090 levels: - high - title: OpenShift RBAC access controls must be enforced. + title: OpenShift role-based access controls (RBAC) must be enforced. rules: - rbac_least_privilege status: automated @@ -644,7 +644,7 @@ controls: - id: CNTR-OS-000630 levels: - medium - title: OpenShift must restrict individuals the ability to launch organizational-defined Denial-of-Service + title: OpenShift must restrict individuals' ability to launch organization-defined denial-of-service (DOS) attacks against other information systems by rate-limiting. rules: - project_config_and_template_resource_quota @@ -693,10 +693,9 @@ controls: - medium title: OpenShift must configure Alert Manger Receivers to notify SA and ISSO of all audit failure events requiring real-time alerts. - rules: [] - notes: |- - This needs further investigation: CMP-2437 - status: pending + rules: + - alert_receiver_configured + status: manual - id: CNTR-OS-000720 levels: @@ -772,11 +771,12 @@ controls: levels: - medium title: OpenShift must protect the confidentiality and integrity of transmitted information. - rules: [] + rules: + - routes_protected_by_tls notes: |- - This item is manual and kindof vague by design as e.g. with passthrough TLS, the TLS settings - must be checked in the app anyway. - status: manual + The rule covers edge-terminated routes. Passthrough TLS must still be checked at the + application level. + status: partial - id: CNTR-OS-000860 levels: diff --git a/products/ocp4/profiles/stig-node-v2r3.profile b/products/ocp4/profiles/stig-node-v2r3.profile index 65e8c778cd9e..69536eef9d35 100644 --- a/products/ocp4/profiles/stig-node-v2r3.profile +++ b/products/ocp4/profiles/stig-node-v2r3.profile @@ -2,6 +2,7 @@ documentation_complete: true platform: ocp4-node +status: deprecated metadata: version: V2R3 @@ -18,8 +19,9 @@ description: |- This profile contains configuration checks that align to the DISA STIG for Red Hat OpenShift Container Platform 4. -filter_rules: '"ocp4-node" in platform or "ocp4-master-node" in platform or "ocp4-node-on-sdn" in platform - or "ocp4-node-on-ovn" in platform' +# Kubevirt rules were added to STIG control in V2R6 and are scanned by the stig-vm-extension CEL profile +filter_rules: '("ocp4-node" in platform or "ocp4-master-node" in platform or "ocp4-node-on-sdn" in platform + or "ocp4-node-on-ovn" in platform) and "kubevirt" not in id_' selections: - stig_ocp4:all diff --git a/products/ocp4/profiles/stig-node-v2r2.profile b/products/ocp4/profiles/stig-node-v2r6.profile similarity index 86% rename from products/ocp4/profiles/stig-node-v2r2.profile rename to products/ocp4/profiles/stig-node-v2r6.profile index 10e3151ab0a1..5ff57ec94284 100644 --- a/products/ocp4/profiles/stig-node-v2r2.profile +++ b/products/ocp4/profiles/stig-node-v2r6.profile @@ -2,16 +2,15 @@ documentation_complete: true platform: ocp4-node -status: deprecated metadata: - version: V2R2 + version: V2R6 SMEs: - Vincent056 - rhmdnd - yuumasato -reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-12_V2R2_STIG.zip +reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R6_STIG.zip title: 'DISA STIG for Red Hat OpenShift Container Platform 4 - Node level' diff --git a/products/ocp4/profiles/stig-node.profile b/products/ocp4/profiles/stig-node.profile index 67d120635833..f0a106800da3 100644 --- a/products/ocp4/profiles/stig-node.profile +++ b/products/ocp4/profiles/stig-node.profile @@ -4,13 +4,13 @@ documentation_complete: true platform: ocp4-node metadata: - version: V2R3 + version: V2R6 SMEs: - Vincent056 - rhmdnd - yuumasato -reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R3_STIG.zip +reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R6_STIG.zip title: 'DISA STIG for Red Hat OpenShift Container Platform 4 - Node level' @@ -18,4 +18,4 @@ description: |- This profile contains configuration checks that align to the DISA STIG for Red Hat OpenShift Container Platform 4. -extends: stig-node-v2r3 +extends: stig-node-v2r6 diff --git a/products/ocp4/profiles/stig-v2r3.profile b/products/ocp4/profiles/stig-v2r3.profile index e8e807b06390..bdcad36eb88c 100644 --- a/products/ocp4/profiles/stig-v2r3.profile +++ b/products/ocp4/profiles/stig-v2r3.profile @@ -2,6 +2,7 @@ documentation_complete: true platform: ocp4 +status: deprecated metadata: version: V2R3 @@ -18,8 +19,9 @@ description: |- This profile contains configuration checks that align to the DISA STIG for Red Hat OpenShift Container Platform 4. +# Kubevirt rules were added to STIG control in V2R6 and are scanned by the stig-vm-extension CEL profile filter_rules: '"ocp4-node" not in platform and "ocp4-master-node" not in platform and "ocp4-node-on-sdn" - not in platform and "ocp4-node-on-ovn" not in platform' + not in platform and "ocp4-node-on-ovn" not in platform and "kubevirt" not in id_' selections: - stig_ocp4:all diff --git a/products/ocp4/profiles/stig-v2r2.profile b/products/ocp4/profiles/stig-v2r6.profile similarity index 78% rename from products/ocp4/profiles/stig-v2r2.profile rename to products/ocp4/profiles/stig-v2r6.profile index 3a788ea3e4c4..20e08b0feec5 100644 --- a/products/ocp4/profiles/stig-v2r2.profile +++ b/products/ocp4/profiles/stig-v2r6.profile @@ -2,16 +2,15 @@ documentation_complete: true platform: ocp4 -status: deprecated metadata: - version: V2R2 + version: V2R6 SMEs: - Vincent056 - rhmdnd - yuumasato -reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-12_V2R2_STIG.zip +reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R6_STIG.zip title: 'DISA STIG for Red Hat OpenShift Container Platform 4 - Platform level' @@ -19,8 +18,9 @@ description: |- This profile contains configuration checks that align to the DISA STIG for Red Hat OpenShift Container Platform 4. +# Kubevirt rules are scanned by the stig-vm-extension CEL profile filter_rules: '"ocp4-node" not in platform and "ocp4-master-node" not in platform and "ocp4-node-on-sdn" - not in platform and "ocp4-node-on-ovn" not in platform' + not in platform and "ocp4-node-on-ovn" not in platform and "kubevirt" not in id_' selections: - stig_ocp4:all diff --git a/products/ocp4/profiles/stig.profile b/products/ocp4/profiles/stig.profile index 297f2a3f6f1a..3bd06253c8e8 100644 --- a/products/ocp4/profiles/stig.profile +++ b/products/ocp4/profiles/stig.profile @@ -4,13 +4,13 @@ documentation_complete: true platform: ocp4 metadata: - version: V2R3 + version: V2R6 SMEs: - Vincent056 - rhmdnd - yuumasato -reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R3_STIG.zip +reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R6_STIG.zip title: 'DISA STIG for Red Hat OpenShift Container Platform 4 - Platform level' @@ -18,4 +18,4 @@ description: |- This profile contains configuration checks that align to the DISA STIG for Red Hat OpenShift Container Platform 4. -extends: stig-v2r3 +extends: stig-v2r6 diff --git a/products/rhcos4/profiles/stig-v2r3.profile b/products/rhcos4/profiles/stig-v2r3.profile index 6fabd01566b9..0fe0e55476b7 100644 --- a/products/rhcos4/profiles/stig-v2r3.profile +++ b/products/rhcos4/profiles/stig-v2r3.profile @@ -7,6 +7,8 @@ metadata: - rhmdnd - yuumasato +status: deprecated + reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R3_STIG.zip title: 'DISA STIG for Red Hat Enterprise Linux CoreOS' @@ -15,6 +17,9 @@ description: |- This profile contains configuration checks that align to the DISA STIG for Red Hat Enterprise Linux CoreOS 4. +# Kubevirt rules are not applicable to RHCOS +filter_rules: '"kubevirt" not in id_' + selections: - stig_ocp4:all - var_sshd_set_keepalive=0 diff --git a/products/rhcos4/profiles/stig-v2r2.profile b/products/rhcos4/profiles/stig-v2r6.profile similarity index 78% rename from products/rhcos4/profiles/stig-v2r2.profile rename to products/rhcos4/profiles/stig-v2r6.profile index a918c985a6f3..a7fbccf979e0 100644 --- a/products/rhcos4/profiles/stig-v2r2.profile +++ b/products/rhcos4/profiles/stig-v2r6.profile @@ -1,15 +1,13 @@ documentation_complete: true metadata: - version: V2R2 + version: V2R6 SMEs: - Vincent056 - rhmdnd - yuumasato -status: deprecated - -reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-12_V2R2_STIG.zip +reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R6_STIG.zip title: 'DISA STIG for Red Hat Enterprise Linux CoreOS' @@ -17,6 +15,9 @@ description: |- This profile contains configuration checks that align to the DISA STIG for Red Hat Enterprise Linux CoreOS 4. +# Kubevirt rules are not applicable to RHCOS +filter_rules: '"kubevirt" not in id_' + selections: - stig_ocp4:all - var_sshd_set_keepalive=0 diff --git a/products/rhcos4/profiles/stig.profile b/products/rhcos4/profiles/stig.profile index 4c0b528d1102..c3eb4ebc8ab4 100644 --- a/products/rhcos4/profiles/stig.profile +++ b/products/rhcos4/profiles/stig.profile @@ -1,13 +1,13 @@ documentation_complete: true metadata: - version: V2R3 + version: V2R6 SMEs: - Vincent056 - rhmdnd - yuumasato -reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R3_STIG.zip +reference: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_RH_OpenShift_Container_Platform_4-x_V2R6_STIG.zip title: 'DISA STIG for Red Hat Enterprise Linux CoreOS' @@ -15,4 +15,4 @@ description: |- This profile contains configuration checks that align to the DISA STIG for Red Hat Enterprise Linux CoreOS 4. -extends: stig-v2r3 +extends: stig-v2r6 diff --git a/shared/references/disa-stig-ocp4-v2r3-xccdf-manual.xml b/shared/references/disa-stig-ocp4-v2r6-xccdf-manual.xml similarity index 88% rename from shared/references/disa-stig-ocp4-v2r3-xccdf-manual.xml rename to shared/references/disa-stig-ocp4-v2r6-xccdf-manual.xml index 4ccce0600cc7..0200caecfe1d 100644 --- a/shared/references/disa-stig-ocp4-v2r3-xccdf-manual.xml +++ b/shared/references/disa-stig-ocp4-v2r6-xccdf-manual.xml @@ -1,4 +1,4 @@ -acceptedRed Hat OpenShift Container Platform 4.x Security Technical Implementation GuideThis Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.DISASTIG.DOD.MILRelease: 3 Benchmark Date: 02 Jul 20253.51.10.02I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>SRG-APP-000014-CTR-000035<GroupDescription></GroupDescription>CNTR-OS-000010OpenShift must use TLS 1.2 or greater for secure container image transport from trusted sources.<VulnDiscussion>The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000068Remove insecure registries from the cluster's image registry configuration by executing the following: @@ -525,7 +525,7 @@ To find all setuid binaries on the system, execute the following: for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; find / -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null'; done -If any setuid binary does not have a corresponding audit rule, this is a finding.SRG-APP-000033-CTR-000090<GroupDescription></GroupDescription>CNTR-OS-000090OpenShift RBAC access controls must be enforced.<VulnDiscussion>Controlling and limiting users access to system services and resources is key to securing the platform and limiting the intentional or unintentional compromising 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. +If any setuid binary does not have a corresponding audit rule, this is a finding.SRG-APP-000033-CTR-000090<GroupDescription></GroupDescription>CNTR-OS-000090OpenShift role-based access controls (RBAC) must be enforced.<VulnDiscussion>Controlling and limiting users access to system services and resources is key to securing the platform and limiting the intentional or unintentional compromising 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. OpenShift provides a set of default roles out of the box, and additional roles may be added as needed. Each role has a set of rules controlling what access that role may have, and users and/or groups may be bound to one or more roles. The cluster-admin cluster level RBAC role has complete super admin privileges and it is a required role for select cluster administrators to have. @@ -533,120 +533,254 @@ The OpenShift Container Platform includes a built-in image registry. The primary Restricting access permissions and providing access only to the necessary components and resources within the OpenShift environment reduces the potential impact of security breaches and unauthorized activities. -Satisfies: 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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000213CCI-000764CCI-004045CCI-001499CCI-001774CCI-003980CCI-001813CCI-002235CCI-000770CCI-001812If 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: - +Satisfies: 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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000213CCI-000764CCI-004045CCI-001499CCI-001774CCI-003980CCI-001813CCI-002235CCI-000770CCI-001812If 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> - +oc adm policy remove-cluster-role-from-user &lt;role&gt; &lt;username&gt; + Remove a group from a Cluster RBAC role by executing the following: - -oc adm policy remove-cluster-role-from-group <role> <groupname> - +oc adm policy remove-cluster-role-from-group &lt;role&gt; &lt;groupname&gt; + Remove a user from a Local RBAC role by executing the following: +oc adm policy remove-role-from-user &lt;role&gt; &lt;username&gt; + +Remove a group from a Local RBAC role by executing the following: +oc adm policy remove-role-from-group &lt;role&gt; &lt;groupname&gt; + +Note: For additional information, refer to https://docs.openshift.com/container-platform/4.8/authentication/using-rbac.html. + +Where OpenShift Virtualization is enabled: + +1. Ensure kubevirt seccomp profile file permission is set to "700" or more restrictive: +$ oc exec <virt-handler-pod> -ti -n openshift-cnv -- chmod 700 +/proc/1/root/var/lib/kubelet/seccomp/kubevirt/kubevirt.json + +Ensure kubevirt cache directory permission is set to "755" or more restrictive: +$ oc exec <virt-handler-pod> -ti -n openshift-cnv -- chmod 755 +/var/run/kubevirt-private + +2. Remove create access to virtualmachineinstancemigration and migrationpolicy objects in the cluster. + +Example: Remove create access given by the clusterRoleBinding for the migrationpolicy for the test user. + +# Get all the users and service accounts who can create +migrationpolicies +$ oc adm policy who-can create migrationpolicy +Users: system:admin +.. + +Test + +# Verify that the test user can create the migrationpolicy +$ oc auth can-i create migrationpolicies --as test +Warning: resource 'migrationpolicies' is not namespace scoped in group +'migrations.kubevirt.io' +yes +# Find out which rolebinding or clusterrolbinding associated to the +test user +$ oc get rolebindings,clusterrolebindings --all-namespaces -o +custom-columns='KIND:kind,NAMESPACE:metadata.namespace,NAME:metadata.n +ame,SERVICE_ACCOUNTS:subjects[?(@.kind=="User")].name' |grep test +ClusterRoleBinding <none> +migration-creator +test +# Inspect the cluster role binding +$ oc get clusterrolebindings migration-creator -oyaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: +annotations: +kubectl.kubernetes.io/last-applied-configuration: | +{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBindin +g","metadata":{"annotations":{},"name":"migration-creator"},"roleRef": +{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"m +igration-creator"},"subjects":[{"apiGroup":"rbac.authorization.k8s.io" +,"kind":"User","name":"test"},{"kind":"ServiceAccount","name":"test"," +namespace":"default"}]} +creationTimestamp: "2025-03-06T14:05:04Z" +name: migration-creator +resourceVersion: "1093678" +uid: 96be5dc2-2b30-4734-b5ef-16d9342bbdbf +roleRef: +apiGroup: rbac.authorization.k8s.io +kind: ClusterRole +name: migration-creator +subjects: +- apiGroup: rbac.authorization.k8s.io +kind: User +name: test +- kind: ServiceAccount +name: test +namespace: default +# Remove the cluster role binding +$ oc delete clusterrolebindings migration-creator +clusterrolebinding.rbac.authorization.k8s.io "migration-creator" +deleted +# Re-verify that the test user cannot create the migrationpolicy +$ oc auth can-i create migrationpolicies --as test +Warning: resource 'migrationpolicies' is not namespace scoped in group +'migrations.kubevirt.io' +no + +3. Add the appropriate kernel arguments to the MachineConfigPools of the workers nodes and reboot them. + +Refer to https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/installation_configuration/installing-customizing#installation-special-config-kargs_installing-customizing + +Default Value: OpenShift does not enable nested virtualization by default.The administrator must verify OpenShift is configured with the necessary RBAC access controls. + +Review the RBAC configuration. +As the cluster-admin, view the cluster roles and their associated rule sets by executing the following: +oc describe clusterrole.rbac + +View the current set of cluster role bindings, which shows the users and groups that are bound to various roles, by executing the following: +oc describe clusterrolebinding.rbac + +Determine local roles and bindings by executing the following: +oc describe rolebinding.rbac -oc adm policy remove-role-from-user <role> <username> +If these results show users with privileged access that do not require that access, this is a finding. -Remove a group from a Local RBAC role by executing the following: +Where OpenShift Virtualization is enabled: -oc adm policy remove-role-from-group <role> <groupname> - -Note: For additional information, refer to https://docs.openshift.com/container-platform/4.8/authentication/using-rbac.html.The administrator must verify that OpenShift is configured with the necessary RBAC access controls. +1. Execute the following: +$ for pod in $(oc get pod -n openshift-cnv -l +kubevirt.io=virt-handler --no-headers -o +custom-columns="":metadata.name""); do +oc exec -ti -n openshift-cnv $pod -c virt-handler -- stat -c %a +/proc/1/root/var/lib/kubelet/seccomp/kubevirt/kubevirt.json +done -Review the RBAC configuration. +If the permissions are set to anything less restrictive than "700", this is a finding. -As the cluster-admin, view the cluster roles and their associated rule sets by executing the following: +2. Execute the following: +$ for pod in $(oc get po -n openshift-cnv -l kubevirt.io=virt-handler +--no-headers -o custom-columns="":metadata.name""); do oc exec $pod +-ti -n openshift-cnv -- stat -c %a /var/run/kubevirt-private ;done -oc describe clusterrole.rbac +If the permissions are set to anything less restrictive than "755", this is a finding. -Now, view the current set of cluster role bindings, which shows the users and groups that are bound to various roles by executing the following: +3. Execute the following: +$oc adm policy who-can create vmim -oc describe clusterrolebinding.rbac +$ oc adm policy who-can create migrationpolicy -Local roles and bindings can be determined by executing the following: +If these results show users with privileged access that do not require that access, this is a finding. -oc describe rolebinding.rbac +4. Use the following command to find users, service accounts, and groups who are allowed to create VirtualMachineInterfaceMigration and MigrationPolicy resources: +$ oc adm policy who-can create vmim -If these results show users with privileged access that do not require that access, this is a finding.SRG-APP-000038-CTR-000105<GroupDescription></GroupDescription>CNTR-OS-000100OpenShift must enforce network policy on the namespace for controlling the flow of information within the container platform based on organization-defined information flow control policies.<VulnDiscussion>OpenShift provides several layers of protection to control the flow of information between the container platform components and user services. Each user project is given a separate namespace and OpenShift enforces RBAC policies controlling which projects and services users can access. +$ oc adm policy who-can create migrationpolicy -OpenShift forces the use of namespaces. Service accounts are a namespace resource as well, so they are segregated. RBAC policies apply to service accounts. In addition, Network Policies are used to control the flow of requests between containers hosted on the container platform. +If these list users not authorized to perform namespace admin migration functions, this is a finding. -It is important to define a default Network Policy on the namespace that will be applied automatically to new projects to prevent unintended requests. These policies can be updated by the project's administrator (with the appropriate RBAC permissions) to apply a policy that is appropriate to the service(s) within the project namespace.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001368Add a Network Policy to an existing project namespace by performing the following steps: +5. Execute the following: +cat /sys/module/kvm_intel/parameters/nested -1. Create <YOURFILE>.yaml and insert the desired resource Network Policy content. The following is an example resource quota definition: +If the result is "1", this is a finding.SRG-APP-000038-CTR-000105<GroupDescription></GroupDescription>CNTR-OS-000100OpenShift must enforce network policy on the namespace for controlling the flow of information within the container platform based on organization-defined information flow control policies.<VulnDiscussion>OpenShift provides several layers of protection to control the flow of information between the container platform components and user services. Each user project is given a separate namespace and OpenShift enforces RBAC policies controlling which projects and services users can access. -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: +OpenShift forces the use of namespaces. Service accounts are a namespace resource as well, so they are segregated. RBAC policies apply to service accounts. In addition, network policies are used to control the flow of requests between containers hosted on the container platform. + +It is important to define a default network policy on the namespace that will be applied automatically to new projects to prevent unintended requests. These policies can be updated by the project's administrator (with the appropriate RBAC permissions) to apply a policy that is appropriate to the service(s) within the project namespace.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001368Add a network policy to an existing project namespace by performing the following steps: + +1. Create <YOURFILE>.yaml and insert the desired resource network policy content. The following is an example resource quota definition: + apiVersion: networking.k8s.io/v1 + kind: NetworkPolicy + metadata: name: allow-from-same-namespace namespace: <NAMESPACE> -spec: + spec: podSelector: {} ingress: - from: - - podSelector: {} - -2. Apply the Network Policy definition to the project namespace by executing the following: - + - podSelector: {} + +2. Apply the network policy definition to the project namespace by executing the following: oc apply -f <YOURFILE>.yaml -n <NAMESPACE> + +Details regarding the configuration of resource network policy can be reviewed at https://docs.openshift.com/container-platform/4.12/networking/network_policy/about-network-policy.html. -Details regarding the configuration of resource Network Policy can be reviewed at https://docs.openshift.com/container-platform/4.12/networking/network_policy/about-network-policy.html.Verify that each user namespace has a Network Policy by executing the following: +Where OpenShift Virtualization is enabled: +Enable MAC-spoof filtering per the deployed networking provider instructions. -for ns in $(oc get namespaces -ojson | jq -r '.items[] | select((.metadata.name | startswith("openshift") | not) and (.metadata.name | startswith("kube-") | not) and .metadata.name != "default") | .metadata.name '); do oc get networkpolicy -n$ns; done +Instructions for Bridge CNI and SR-IOV CNI: +https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/virtualization/networking#virt-creating-linux-bridge-nad-cli_virt-connecting-vm-to-linux-bridge +https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/virtualization/networking#nw-sriov-network-attachment_virt-connecting-vm-to-sriovVerify each user namespace has a network policy by executing the following: + + for ns in $(oc get namespaces -ojson | jq -r '.items[] | select((.metadata.name | startswith('openshift') | not) and (.metadata.name | startswith('kube-') | not) and .metadata.name != 'default') | .metadata.name '); do oc get networkpolicy -n$ns; done + +If the above returns any lines saying "No resources found in <PROJECT> namespace.", this is a finding. Empty output is not a finding. -If the above returns any lines saying "No resources found in <PROJECT> namespace.", this is a finding. Empty output is not a finding.SRG-APP-000039-CTR-000110<GroupDescription></GroupDescription>CNTR-OS-000110OpenShift must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.<VulnDiscussion>OpenShift provides several layers of protection to control the flow of information between the container platform components and user services. Each user project is given a separate namespace and OpenShift enforces RBAC policies controlling which projects and services users can access. In addition, Network Policies are used to control the flow of requests to and from externally integrated services to services hosted on the container platform. +Where OpenShift Virtualization is enabled: -It is important to define a default Network Policy that will be applied automatically to new projects to prevent unintended requests. These policies can be updated by the project's administrator (with the appropriate RBAC permissions) to apply a policy that is appropriate to the service(s) within the project namespace.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001414Configure a default network policy as necessary to protect the flow of information by performing the following steps: +For SR-IOV, use the following command: +$ oc get sriovnetwork -o json | jq ".items[].spec.spoofChk" -1. Create a bootstrap project template (if not already created) by executing the following: +If these results show the setting is off for any network, this is a finding. -oc adm create-bootstrap-project-template -o yaml > template.yaml +For Bridge CNI, use the following command: +$ oc get networkattachmentdefinition -o json | jq +".items[].spec.config.macspoofchk" -2. Edit the template and add Network Policy object definitions before the parameters section. For example, the following section defines two policies: one to allow requests from the same namespace and one to allow from the OpenShift ingress routing service. +If these results show the setting is false for any network, this is a finding.SRG-APP-000039-CTR-000110<GroupDescription></GroupDescription>CNTR-OS-000110OpenShift must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.<VulnDiscussion>OpenShift provides several layers of protection to control the flow of information between the container platform components and user services. Each user project is given a separate namespace and OpenShift enforces RBAC policies controlling which projects and services users can access. In addition, Network Policies are used to control the flow of requests to and from externally integrated services to services hosted on the container platform. -- apiVersion: networking.k8s.io/v1 +It is important to define a default network policy that will be applied automatically to new projects to prevent unintended requests. These policies can be updated by the project's administrator (with the appropriate RBAC permissions) to apply a policy that is appropriate to the service(s) within the project namespace.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001414Configure a default network policy as necessary to protect the flow of information by performing the following steps: + +1. Create a bootstrap project template (if not already created) by executing the following: + oc adm create-bootstrap-project-template -o yaml > template.yaml + +2. Edit the template and add network policy object definitions before the parameters section. For example, the following section defines two policies: one to allow requests from the same namespace and one to allow from the OpenShift ingress routing service. + - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: - name: allow-from-same-namespace + name: allow-from-same-namespace spec: - podSelector: - ingress: - - from: - - podSelector: {} -- apiVersion: networking.k8s.io/v1 + podSelector: + ingress: + - from: + - podSelector: {} + - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: - name: allow-from-openshift-ingress + name: allow-from-openshift-ingress spec: - ingress: - - from: - - namespaceSelector: - matchLabels: - network.openshift.io/policy-group: ingress - podSelector: {} - policyTypes: - - Ingress -parameters: - -3. Apply the project template to the cluster by executing the following: - -oc create -f template.yaml -n openshift-config - -4. Set the default cluster project request template by executing the following: + ingress: + - from: + - namespaceSelector: + matchLabels: + network.openshift.io/policy-group: ingress + podSelector: {} + policyTypes: + - Ingress + parameters: + + 3. Apply the project template to the cluster by executing the following: + oc create -f template.yaml -n openshift-config + + 4. Set the default cluster project request template by executing the following: + oc patch project.config.openshift.io/cluster --type=merge -p '{'spec':{'projectRequestTemplate':{'name': '<PROJECT_REQUEST_TEMPLATE>'}}}' + +For additional information regarding network policies, refer to https://docs.openshift.com/container-platform/4.8/networking/network_policy/about-network-policy.html. + +Where OpenShift Virtualization is enabled: +$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv +--type='json' -p='[ +{"op": "replace", "path": "/spec/featureGates/downwardMetrics", +"value": false }, +]'Check for network policy. Verify a default project template is defined by executing the following: +oc get project.config.openshift.io/cluster -o jsonpath='{.spec.projectRequestTemplate.name}' -oc patch project.config.openshift.io/cluster --type=merge -p '{"spec":{"projectRequestTemplate":{"name": "<PROJECT_REQUEST_TEMPLATE>"}}}' - -For additional information regarding network policies, refer to https://docs.openshift.com/container-platform/4.8/networking/network_policy/about-network-policy.html.Check for Network Policy. Verify a default project template is defined by executing the following: - -oc get project.config.openshift.io/cluster -o jsonpath="{.spec.projectRequestTemplate.name}" - If no project request template is in use by the project config, this is a finding. + +Verify the project request template creates a network policy: +oc get templates/<PROJECT-REQUEST-TEMPLATE> -n openshift-config -o jsonpath='{.objects[?(.kind=='NetworkPolicy')]}{'\n'}' + +Replace <PROJECT-REQUEST-TEMPLATE> with the name of the project request template returned from the earlier query. If the project template is not defined, or there are no network policy definitions in it, this is a finding. -Verify the project request template creates a Network Policy: - -oc get templates/<PROJECT-REQUEST-TEMPLATE> -n openshift-config -o jsonpath="{.objects[?(.kind=='NetworkPolicy')]}{'\n'}" +Where OpenShift Virtualization is enabled: +$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv +-ojsonpath='{.spec.featureGates.downwardMetrics}' -Replace <PROJECT-REQUEST-TEMPLATE> with the name of the project request template returned from the earlier query. If the project template is not defined, or there are no Network Policy definitions in it, this is a finding.SRG-APP-000068-CTR-000120<GroupDescription></GroupDescription>CNTR-OS-000130OpenShift must display the Standard Mandatory DOD Notice and Consent Banner before granting access to platform components.<VulnDiscussion>OpenShift has countless components where different access levels are needed. To control access, the user must first log into the component and then be presented with a DOD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000048The following command will create a configmap that displays the DOD Notice and Consent Banner when logging in using the OpenShift CLI tool by executing the following: +If this is set to anything other than "false", this is a finding.SRG-APP-000068-CTR-000120<GroupDescription></GroupDescription>CNTR-OS-000130OpenShift must display the Standard Mandatory DOD Notice and Consent Banner before granting access to platform components.<VulnDiscussion>OpenShift has countless components where different access levels are needed. To control access, the user must first log into the component and then be presented with a DOD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000048The following command will create a configmap that displays the DOD Notice and Consent Banner when logging in using the OpenShift CLI tool by executing the following: echo 'apiVersion: v1 kind: ConfigMap @@ -669,17 +803,30 @@ Verify that motd config map exists and contains the DOD Notice and Consent Banne oc describe configmap/motd -n openshift -If the configmap does not exist, or it does not contain the DOD Notice and Consent Banner text in the message data attribute, this is a finding.SRG-APP-000089-CTR-000150<GroupDescription></GroupDescription>CNTR-OS-000150OpenShift must generate audit records for all DOD-defined auditable events within all components in the platform.<VulnDiscussion>The OpenShift Platform supports three audit levels: Default, WriteRequestBodies, and AllRequestBodies. The identities of the users are logged for all three audit levels log level. The WriteRequestBodies will log the metadata and the request body for any create, update, or patch request. The AllRequestBodies will log the metadata and the request body for all read and write requests. As this generates a significant number of logs, this level is only to be used as needed. To capture sufficient data to investigate an issue, it is required to set the audit level to WriteRequestBodies. +If the configmap does not exist, or it does not contain the DOD Notice and Consent Banner text in the message data attribute, this is a finding.SRG-APP-000089-CTR-000150<GroupDescription></GroupDescription>CNTR-OS-000150OpenShift must generate audit records for all DOD-defined auditable events within all components in the platform.<VulnDiscussion>The OpenShift Platform supports three audit levels: Default, WriteRequestBodies, and AllRequestBodies. The identities of the users are logged for all three audit levels log level. The WriteRequestBodies will log the metadata and the request body for any create, update, or patch request. The AllRequestBodies will log the metadata and the request body for all read and write requests. As this generates a significant number of logs, this level is only to be used as needed. To capture sufficient data to investigate an issue, it is required to set the audit level to WriteRequestBodies. For more detailed documentation on what is being logged, refer to https://docs.openshift.com/container-platform/4.8/security/audit-log-view.html. -Satisfies: SRG-APP-000089-CTR-000150, SRG-APP-000090-CTR-000155, SRG-APP-000101-CTR-000205, SRG-APP-000510-CTR-001310, SRG-APP-000516-CTR-000790</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000135CCI-000169CCI-000171CCI-000172CCI-000366As the cluster administrator, update the APIServer.config.openshift.io/cluster object to set the profile to the defined level of detail. For example, to configure the profile to WriteRequestBodies, meaning that all write requests to any API server object are logged in their entirety, by executing the following: +Satisfies: SRG-APP-000089-CTR-000150, SRG-APP-000090-CTR-000155, SRG-APP-000101-CTR-000205, SRG-APP-000510-CTR-001310, SRG-APP-000516-CTR-000790</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000135CCI-000169CCI-000171CCI-000172CCI-000366As the cluster administrator, update the APIServer.config.openshift.io/cluster object to set the profile to the defined level of detail. For example, to configure the profile to WriteRequestBodies, meaning that all write requests to any API server object are logged in their entirety, execute the following: +oc patch apiserver.config.openshift.io/cluster --type=merge -p '{'spec': {'audit': {'profile': 'WriteRequestBodies'}}}' -oc patch apiserver.config.openshift.io/cluster --type=merge -p '{"spec": {"audit": {"profile": "WriteRequestBodies"}}}'To determine at what level the OpenShift audit policy logging verbosity is configured, as a cluster-administrator:execute the following command: +Where OpenShift Virtualization is enabled: +To remove the errorPolicy flag on the first disk (index 0) of a given VM, use this command: +$ oc patch vm <vm-name> --type='json' -p='[ +{"op": "remove", "path": +"/spec/template/spec/domain/devices/disks/0/errorPolicy"}, +]'To determine at what level the OpenShift audit policy logging verbosity is configured, as a cluster-administrator execute the following command: oc get apiserver.config.openshift.io/cluster -ojsonpath='{.spec.audit.profile}' + +If the output from the options does not return WriteRequestBodies or AllRequestBodies, this is a finding. + +Where OpenShift Virtualization is enabled: +$ oc get vm -ojson -A | jq '.items[] | +select(.spec.template.spec.domain.devices.disks[].errorPolicy == +"ignore")| .metadata.namespace + "/" + .metadata.name' -If the output from the options does not return WriteRequestBodies or AllRequestBodies, this is a finding.SRG-APP-000091-CTR-000160<GroupDescription></GroupDescription>CNTR-OS-000160OpenShift must generate audit records when successful/unsuccessful attempts to access privileges occur.<VulnDiscussion>OpenShift and its components must generate audit records when successful/unsuccessful attempts to access or delete security objects, security levels, and privileges occur. +If the results show errorPolicy is set to "ignore", this is a finding.SRG-APP-000091-CTR-000160<GroupDescription></GroupDescription>CNTR-OS-000160OpenShift must generate audit records when successful/unsuccessful attempts to access privileges occur.<VulnDiscussion>OpenShift and its components must generate audit records when successful/unsuccessful attempts to access or delete security objects, security levels, and privileges occur. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and assist with investigating the events relating to an incident or identify those responsible. @@ -1540,14 +1687,13 @@ Review the PPSM Category Assurance List (CAL) directly at the following link: ht Verify the ports used by the OpenShift are approved by the PPSM CAL. -If the ports, protocols, and services have not been registered locally, this is a finding.SRG-APP-000148-CTR-000335<GroupDescription></GroupDescription>CNTR-OS-000400OpenShift must disable root and terminate network connections.<VulnDiscussion>Direct login as the "root" user must be disabled to prevent unrestricted access and control over the entire system. +If the ports, protocols, and services have not been registered locally, this is a finding.SRG-APP-000148-CTR-000335<GroupDescription></GroupDescription>CNTR-OS-000400OpenShift must disable root and terminate network connections.<VulnDiscussion>Direct login as the "root" user must be disabled to prevent unrestricted access and control over the entire system. Terminating an idle session within a short time reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single operating system level network connection. This does not mean that the application terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session. -Satisfies: SRG-APP-000148-CTR-000335, SRG-APP-000190-CTR-000500</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000764CCI-001133Apply the machine config that disables root and terminates network connections by executing the following: - +Satisfies: SRG-APP-000148-CTR-000335, SRG-APP-000190-CTR-000500</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000764CCI-001133Apply the machine config that disables root and terminates network connections by executing the following: for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do echo "apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig @@ -1567,24 +1713,35 @@ spec: overwrite: true path: /etc/ssh/sshd_config " | oc apply -f - -doneVerify SSH is restricted from logging on as root and network connections are terminated. +done -Prevent logging on directly as "root" using SSH by executing the following command: +Where OpenShift Virtualization is enabled on versions older than 4.18: +$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv +--type='json' -p='[ +{"op": "replace", "path": "/spec/featureGates/nonRoot", "value": +true }, +]'Verify SSH is restricted from logging on as root and network connections are terminated. -for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep -i PermitRootLogin /etc/ssh/sshd_config' 2>/dev/null; done +Prevent logging on directly as "root" using SSH by executing the following command: + for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep -i PermitRootLogin /etc/ssh/sshd_config' 2>/dev/null; done If the "PermitRootLogin" keyword is set to "yes", is missing, or is commented out, this is a finding. Verify all network connections associated with SSH traffic are automatically terminated at the end of the session or after 10 minutes of inactivity. Check the "ClientAliveCountMax" and ClientAliveInterval by executing the following command: - -for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep -i clientalive /etc/ssh/sshd_config + for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep -i clientalive /etc/ssh/sshd_config ' 2>/dev/null; done If "ClientAliveCountMax" do not exist, is not set to a value of "0" in "/etc/ssh/sshd_config", or is commented out, this is a finding. -If "ClientAliveInterval" does not exist, or has a value of > 600 in "/etc/ssh/sshd_config", or is commented out, this is a finding.SRG-APP-000149-CTR-000355<GroupDescription></GroupDescription>CNTR-OS-000430OpenShift must use multifactor authentication for network access to accounts.<VulnDiscussion>Without the use of multifactor authentication, the ease of access to privileged and nonprivileged functions is greatly increased. +If "ClientAliveInterval" does not exist, or has a value of > 600 in "/etc/ssh/sshd_config", or is commented out, this is a finding. + +Where OpenShift Virtualization is enabled on versions older than 4.18: +$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv +-ojsonpath='{.spec.featureGates.nonRoot}' + +If this is set to anything other than "true", this is a finding.SRG-APP-000149-CTR-000355<GroupDescription></GroupDescription>CNTR-OS-000430OpenShift must use multifactor authentication for network access to accounts.<VulnDiscussion>Without the use of multifactor authentication, the ease of access to privileged and nonprivileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. @@ -1862,36 +2019,41 @@ Determine if the session token inactivity timeout is set on the oauthclients by oc get oauthclients -ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.accessTokenInactivityTimeoutSeconds}{"\n"}' -The output will list each oauth client name followed by a number. The number represents the timeout in seconds. If no number is displayed, or the timeout value is >600, this is a finding.SRG-APP-000211-CTR-000530<GroupDescription></GroupDescription>CNTR-OS-000500OpenShift must separate user functionality (including user interface services) from information system management functionality.<VulnDiscussion>Red Hat Enterprise Linux CoreOS (RHCOS) is a single-purpose container operating system. RHCOS is only supported as a component of the OpenShift Container Platform. Remote management of the RHCOS nodes is performed at the OpenShift Container Platform API level. +The output will list each oauth client name followed by a number. The number represents the timeout in seconds. If no number is displayed, or the timeout value is >600, this is a finding.SRG-APP-000211-CTR-000530<GroupDescription></GroupDescription>CNTR-OS-000500OpenShift must separate user functionality (including user interface services) from information system management functionality.<VulnDiscussion>Red Hat Enterprise Linux CoreOS (RHCOS) is a single-purpose container operating system. RHCOS is only supported as a component of the OpenShift Container Platform. Remote management of the RHCOS nodes is performed at the OpenShift Container Platform API level. -Any direct access to the RHCOS nodes is unnecessary. RHCOS only has two user accounts defined, root(0) and core(1000). These are the only two user accounts that should exist on the RHCOS nodes. As any administrative access or actions are to be done through the OpenShift Container Platform's administrative APIs, direct logon access to the RHCOS host must be disabled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001082Disable and remove passwords from root and core accounts by executing the following: - -for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'usermod -p "*" root; usermod -p "*" core' 2>/dev/null; done +Any direct access to the RHCOS nodes is unnecessary. RHCOS only has two user accounts defined, root(0) and core(1000). These are the only two user accounts that should exist on the RHCOS nodes. As any administrative access or actions are to be done through the OpenShift Container Platform's administrative APIs, direct logon access to the RHCOS host must be disabled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001082Disable and remove passwords from root and core accounts by executing the following: + for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'usermod -p '*' root; usermod -p '*' core' 2>/dev/null; done + Remove any additional user accounts from the nodes by executing the following: +oc debug node/<node> -- chroot /host /bin/bash -c 'userdel <user>' -oc debug node/<node> -- chroot /host /bin/bash -c 'userdel <user>'Verify that root and core are the only user accounts on the nodes by executing the following: - -for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; cat /etc/passwd' 2>/dev/null; done - +Where OpenShift Virtualization is enabled: +oc get rolebinding -ojson | jq -r '.items[] | select(.roleRef.name | contains("token.kubevirt.io:generate")) | .metadata.name' | xargs oc delete rolebindingVerify root and core are the only user accounts on the nodes by executing the following: + for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n '$HOSTNAME '; cat /etc/passwd' 2>/dev/null; done + The output will look similar to: - <node_name> root:x:0:0:root:/root:/bin/bash core:x:1000:1000:CoreOS Admin:/var/home/core:/bin/bash containers:x:993:995:User for housing the sub ID range for containers:/var/home/containers:/sbin/nologin - + If there are any user accounts in addition to root, containers, and core, this is a finding. - + Verify the root and core users are set to disable password logon by executing the following: - -for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep -e "^root" -e "^core" /etc/shadow' 2>/dev/null; done + for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n '$HOSTNAME '; grep -e '^root' -e '^core' /etc/shadow' 2>/dev/null; done The output will look similar to: <node_name> root:*:18367:0:99999:7::: core:*:18939:0:99999:7::: + +If the password entry has anything other than '*', this is a finding. -If the password entry has anything other than '*', this is a finding.SRG-APP-000219-CTR-000550<GroupDescription></GroupDescription>CNTR-OS-000510OpenShift must protect authenticity of communications sessions with the use of FIPS-validated 140-2 or 140-3 validated cryptography.<VulnDiscussion>FIPS compliance is one of the most critical components required in highly secure environments, to ensure that only supported cryptographic technologies are allowed on nodes. +Where OpenShift Virtualization is enabled: +$ oc get rolebinding -ojson | jq -c '.items[] | select(.roleRef.name +| contains("token.kubevirt.io:generate"))' + +If these results show users with this rolebinding, this is a finding.SRG-APP-000219-CTR-000550<GroupDescription></GroupDescription>CNTR-OS-000510OpenShift must protect authenticity of communications sessions with the use of FIPS-validated 140-2 or 140-3 validated cryptography.<VulnDiscussion>FIPS compliance is one of the most critical components required in highly secure environments, to ensure that only supported cryptographic technologies are allowed on nodes. Because FIPS must be enabled before the operating system used by the cluster boots for the first time, FIPS cannot be disabled after a cluster is deployed. @@ -1955,27 +2117,62 @@ done for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; getenforce' 2>/dev/null; done -If "SELinux" is not active and not in "Enforcing" mode, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000560OpenShift must prevent unauthorized and unintended information transfer via shared system resources and enable page poisoning.<VulnDiscussion>Enabling page poisoning in OpenShift improves memory safety, mitigates memory corruption vulnerabilities, aids in fault isolation, assists with debugging. It enhances the overall security and stability of the platform, reducing the risk of memory-related exploits and improving the resilience of applications running on OpenShift.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to enable page poisoning by executing the following: +If "SELinux" is not active and not in "Enforcing" mode, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000560OpenShift must prevent unauthorized and unintended information transfer via shared system resources and enable page poisoning.<VulnDiscussion>Enabling page poisoning in OpenShift improves memory safety, mitigates memory corruption vulnerabilities, aids in fault isolation, assists with debugging. It enhances the overall security and stability of the platform, reducing the risk of memory-related exploits and improving the resilience of applications running on OpenShift.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to enable page poisoning by executing the following: -for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do -echo "apiVersion: machineconfiguration.openshift.io/v1 + for mcpool in $(oc get mcp -oname | sed &#039;s:.*/::&#039; ); do +echo &#039;apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: - name: 05-kernelarg-page-poison-$mcpool - labels: - machineconfiguration.openshift.io/role: $mcpool + name: 05-kernelarg-page-poison-$mcpool + labels: + machineconfiguration.openshift.io/role: $mcpool spec: - config: - ignition: - version: 3.1.0 - kernelArguments: - - page_poison=1 -" | oc apply -f - -doneCheck the current CoreOS boot loader configuration has page poisoning enabled by executing the following: + config: + ignition: + version: 3.1.0 + kernelArguments: + - page_poison=1 +&#039; | oc apply -f - +done + +Where OpenShift Virtualization is enabled and Windows SCF is not in use execute the following: +$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv +--type='json' -p='[ +{"op": "replace", "path": +"/spec/featureGates/persistentReservation", "value": false }, +]' + +Where OpenShift Virtualization is enabled: +Edit the object and set the field to false: +'oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv' + +To set a shareable flag to false on every disk, this (experimental) command can be used: +$ oc get vm <vm-name> -o json | jq +'.spec.template.spec.domain.devices.disks[] += {"shareable":false}' | +oc apply -f -1. Check the current CoreOS boot loader configuration has page poisoning enabled by executing the following: + for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep page_poison /boot/loader/entries/*.conf|| echo "not found"' 2>/dev/null; done + +If "page_poison" is not set to "1" or returns "not found", this is a finding. + +2. Where OpenShift Virtualization is enabled, execute the following: +$ oc get hyperconvergeds kubevirt-hyperconverged -n openshift-cnv +-ojsonpath='{.spec.ksmConfiguration}' -for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep page_poison /boot/loader/entries/*.conf|| echo "not found"' 2>/dev/null; done +If this is set to anything other than "false", this is a finding. -If "page_poison" is not set to "1" or returns "not found", this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000570OpenShift must disable virtual syscalls.<VulnDiscussion>Virtual syscalls are a mechanism that allows user-space programs to make privileged system calls without transitioning to kernel mode. However, this feature can introduce additional security risks. Disabling virtual syscalls helps to mitigate potential vulnerabilities associated with this mechanism. By reducing the attack surface and limiting the ways in which user-space programs can interact with the kernel, OpenShift can enhance the overall security posture of the platform.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to disable virtual syscalls by executing the following: +3. Where OpenShift Virtualization is enabled, execute the following: +$ oc get vm -ojson -A | jq '.items[] | +select(.spec.template.spec.domain.devices.disks[].shareable == true)| +.metadata.namespace + "/" + .metadata.name' + +If these results show disks flagged the shareable, this is a finding. + +4. Where OpenShift Virtualization is enabled, and Windows SCF is not in use: +$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv +-ojsonpath='{.spec.featureGates.persistentReservation}' + +If this is set to anything other than "false", this is a finding. + SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000570OpenShift must disable virtual syscalls.<VulnDiscussion>Virtual syscalls are a mechanism that allows user-space programs to make privileged system calls without transitioning to kernel mode. However, this feature can introduce additional security risks. Disabling virtual syscalls helps to mitigate potential vulnerabilities associated with this mechanism. By reducing the attack surface and limiting the ways in which user-space programs can interact with the kernel, OpenShift can enhance the overall security posture of the platform.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to disable virtual syscalls by executing the following: for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do echo "apiVersion: machineconfiguration.openshift.io/v1 @@ -1995,7 +2192,7 @@ done for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep vsyscall=none boot/loader/entries/*.conf || echo "not found"' 2>/dev/null; done -If "vsyscall" is not set to "none" or returns "not found", this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000580OpenShift must enable poisoning of SLUB/SLAB objects.<VulnDiscussion>By enabling poisoning of SLUB/SLAB objects, OpenShift can detect and identify use-after-free scenarios more effectively. The poisoned objects are marked as invalid or inaccessible, causing crashes or triggering alerts when an application attempts to access them. This helps identify and mitigate potential security vulnerabilities before they can be exploited.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to enable poisoning of SLUB/SLAB objects by executing the following: +If "vsyscall" is not set to "none" or returns "not found", this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000580OpenShift must enable poisoning of SLUB/SLAB objects.<VulnDiscussion>By enabling poisoning of SLUB/SLAB objects, OpenShift can detect and identify use-after-free scenarios more effectively. The poisoned objects are marked as invalid or inaccessible, causing crashes or triggering alerts when an application attempts to access them. This helps identify and mitigate potential security vulnerabilities before they can be exploited.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to enable poisoning of SLUB/SLAB objects by executing the following: for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do echo "apiVersion: machineconfiguration.openshift.io/v1 @@ -2015,7 +2212,7 @@ done for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep slub_debug /boot/loader/entries/*.conf ' 2>/dev/null; done -If "slub_debug" is not set to "P" or is missing, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000590OpenShift must set the sticky bit for world-writable directories.<VulnDiscussion>Removing world-writable permissions or setting the sticky bit helps enforce access control on directories within the OpenShift platform. World-writable permissions allow any user to modify or delete files within the directory, which can introduce security risks. By removing these permissions or setting the sticky bit, OpenShift restricts modifications to the directory's owner and prevents unauthorized or unintended changes by other users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Fix the directory permissions, by either removing world-writeable permission, or setting the sticky bit by executing the following: +If "slub_debug" is not set to "P" or is missing, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000590OpenShift must set the sticky bit for world-writable directories.<VulnDiscussion>Removing world-writable permissions or setting the sticky bit helps enforce access control on directories within the OpenShift platform. World-writable permissions allow any user to modify or delete files within the directory, which can introduce security risks. By removing these permissions or setting the sticky bit, OpenShift restricts modifications to the directory's owner and prevents unauthorized or unintended changes by other users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Fix the directory permissions, by either removing world-writeable permission, or setting the sticky bit by executing the following: oc debug node/<node_name> -- chroot /host /bin/bash -c 'chmod XXXX <directory>' @@ -2026,7 +2223,7 @@ where for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; find / -type d \( -perm -0002 -a ! -perm -1000 ! -path "/var/lib/containers/*" ! -path "/var/lib/kubelet/pods/*" ! -path "/sysroot/ostree/deploy/*" \) -print 2>/dev/null' 2>/dev/null; done -If there are any directories listed in the results, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000600OpenShift must restrict access to the kernel buffer.<VulnDiscussion>Restricting access to the kernel buffer in OpenShift is crucial for preventing unauthorized access, protecting system stability, mitigating kernel-level attacks, preventing information leakage, and adhering to the principle of least privilege. It enhances the security posture of the platform and helps maintain the confidentiality, integrity, and availability of critical system resources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to restrict access to the kernel message buffer by executing the following: +If there are any directories listed in the results, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000600OpenShift must restrict access to the kernel buffer.<VulnDiscussion>Restricting access to the kernel buffer in OpenShift is crucial for preventing unauthorized access, protecting system stability, mitigating kernel-level attacks, preventing information leakage, and adhering to the principle of least privilege. It enhances the security posture of the platform and helps maintain the confidentiality, integrity, and availability of critical system resources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to restrict access to the kernel message buffer by executing the following: for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do echo "apiVersion: machineconfiguration.openshift.io/v1 @@ -2053,7 +2250,7 @@ Check the status of the kernel.dmesg_restrict kernel parameter by executing the for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; sysctl kernel.dmesg_restrict' 2>/dev/null; done -If "kernel.dmesg_restrict" is not set to "1" or is missing, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000610OpenShift must prevent kernel profiling.<VulnDiscussion>Kernel profiling involves monitoring and analyzing the behavior of the kernel, including its internal operations and system calls. This level of access and visibility into the kernel can potentially be exploited by attackers to gather sensitive information or launch attacks. By preventing kernel profiling, the attack surface is minimized and the risk of unauthorized access or malicious activities targeting the kernel is reduced. +If "kernel.dmesg_restrict" is not set to "1" or is missing, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-OS-000610OpenShift must prevent kernel profiling.<VulnDiscussion>Kernel profiling involves monitoring and analyzing the behavior of the kernel, including its internal operations and system calls. This level of access and visibility into the kernel can potentially be exploited by attackers to gather sensitive information or launch attacks. By preventing kernel profiling, the attack surface is minimized and the risk of unauthorized access or malicious activities targeting the kernel is reduced. Kernel profiling can introduce additional overhead and resource utilization, potentially impacting the stability and performance of the system. Profiling tools and techniques often involve instrumenting the kernel code, injecting hooks, or collecting detailed data, which may interfere with the normal operation of the kernel. By disallowing kernel profiling, OpenShift helps ensure the stability and reliability of the platform, preventing any potential disruptions caused by profiling activities.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001090Apply the machine config to prevent kernel profiling by executing the following: @@ -2122,17 +2319,17 @@ oc get templates/<PROJECT-REQUEST-TEMPLATE> -n openshift-config -o jsonpat Replace <PROJECT-REQUEST-TEMPLATE> with the name of the project request template returned from the earlier query. -If the project template is not defined, or there are no ResourceQuota definitions in it, this is a finding.SRG-APP-000246-CTR-000605<GroupDescription></GroupDescription>CNTR-OS-000630OpenShift must restrict individuals the ability to launch organizational-defined Denial-of-Service (DOS) attacks against other information systems by rate-limiting.<VulnDiscussion>By setting rate limits, OpenShift can control the number of requests or connections allowed from a single source within a specific period. This prevents an excessive influx of requests that can overwhelm the application and degrade its performance or availability. +If the project template is not defined, or there are no ResourceQuota definitions in it, this is a finding.SRG-APP-000246-CTR-000605<GroupDescription></GroupDescription>CNTR-OS-000630OpenShift must restrict individuals' ability to launch organization-defined denial-of-service (DOS) attacks against other information systems by rate-limiting.<VulnDiscussion>By setting rate limits, OpenShift can control the number of requests or connections allowed from a single source within a specific period. This prevents an excessive influx of requests that can overwhelm the application and degrade its performance or availability. -Setting rate limits also ensures fair resource allocation, prevents service degradation, protects backend systems, and enhances overall security. Along with, helping to maintain the availability, performance, and security of the applications hosted on the platform, contributing to a reliable and robust application infrastructure. +Setting rate limits ensures fair resource allocation, prevents service degradation, protects backend systems, and enhances overall security. It also helps to maintain the availability, performance, and security of the applications hosted on the platform, contributing to a reliable and robust application infrastructure. -OpenShift has an option to set the rate limit for Routes (refer to link below) when creating new Routes. All routes outside the OpenShift namespaces and the kube namespaces must use the rate-limiting annotations. +OpenShift has an option to set the rate limit for routes (refer to link below) when creating new routes. All routes outside the OpenShift namespaces and the kube namespaces must use the rate-limiting annotations. -https://docs.openshift.com/container-platform/4.9/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001094Add the haproxy.router.openshift.io/rate-limit-connections annotation to any routes outside the kube-* or openshift-* namespaces +https://docs.openshift.com/container-platform/4.9/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001094Add the "haproxy.router.openshift.io/rate-limit-connections= true" annotation to any routes outside the kube-* or openshift-* namespaces. -oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/timeout=2s" +oc annotate route <route_name> -n <namespace> --overwrite=true " haproxy.router.openshift.io/rate-limit-connections= true " -https://docs.openshift.com/container-platform/4.9/networking/routes/route-configuration.htmlVerify that all namespaces except those that start with kube-* or openshift-* use the rate-limiting annotation by executing the following: +https://docs.openshift.com/container-platform/4.9/networking/routes/route-configuration.htmlVerify that all namespaces except those that start with kube-* or openshift-* use the rate-limiting annotation by executing the following: oc get routes --all-namespaces -o json | jq '[.items[] | select(.metadata.namespace | startswith("kube-") or startswith("openshift-") | not) | select(.metadata.annotations["haproxy.router.openshift.io/rate-limit-connections"] == "true" | not) | .metadata.name]' @@ -2326,20 +2523,45 @@ Confirm the following rules exist on each node: -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k execpriv -If the above rules are not listed on each node, this is a finding.SRG-APP-000384-CTR-000915<GroupDescription></GroupDescription>CNTR-OS-000740OpenShift must prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization.<VulnDiscussion>Integrity of the OpenShift platform is handled by the cluster version operator. The cluster version operator will by default GPG verify the integrity of the release image before applying it. The release image contains a sha256 digest of machine-os-content which is used by the machine config operators for updates. On the host, the container runtime (podman) verifies the integrity of that sha256 when pulling the image before the machine config operator reads its content. Hence, there is end-to-end GPG-verified integrity for the operating system updates (as well as the rest of the cluster components which run as regular containers).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001764By default, the integrity of RH CoreOS is checked by cluster version operator on OpenShift platform. If the integrity is not verified, reinstall of the cluster is necessary. - +If the above rules are not listed on each node, this is a finding.SRG-APP-000384-CTR-000915<GroupDescription></GroupDescription>CNTR-OS-000740OpenShift must prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization.<VulnDiscussion>Integrity of the OpenShift platform is handled by the cluster version operator. The cluster version operator will by default GPG verify the integrity of the release image before applying it. The release image contains a sha256 digest of machine-os-content which is used by the machine config operators for updates. On the host, the container runtime (podman) verifies the integrity of that sha256 when pulling the image before the machine config operator reads its content. Hence, there is end-to-end GPG-verified integrity for the operating system updates (as well as the rest of the cluster components, which run as regular containers).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-001764By default, the integrity of RH CoreOS is checked by cluster version operator on OpenShift platform. If the integrity is not verified, reinstall of the cluster is necessary. + Refer to instructions: -https://docs.openshift.com/container-platform/4.10/installing/index.htmlTo verify integrity of the cluster version, execute the following: +https://docs.openshift.com/container-platform/4.10/installing/index.html +Where OpenShift Virtualization is enabled: +Annotations must be removed from the Hyperconverged by directly editing the object with oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv or by removing the annotation with the annotate command. + +Example: +$ oc annotate --overwrite -n openshift-cnv hco +kubevirt-hyperconverged +'containerizeddataimporter.kubevirt.io/jsonpatch-'To verify integrity of the cluster version, execute the following: oc get clusterversion version + +If the Cluster Version Operator is not installed or the AVAILABLE is not set to "True", this is a finding. + +Run the following command to retrieve the Cluster Version objects in the system: +oc get clusterversion version -o yaml + +If &#039;verified: true&#039;, under status history for each item is not present, this is a finding. -If the Cluster Version Operator is not installed or the AVAILABLE is not set to True, this is a finding. +Where OpenShift Virtualization is enabled: +$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o +jsonpath='{.metadata.annotations}'| jq +'.|has("kubevirt.kubevirt.io/jsonpatch")' -Run the following command to retrieve the Cluster Version objects in the system: +$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o +jsonpath='{.metadata.annotations}'| jq +'.|has("containerizeddataimporter.kubevirt.io/jsonpatch")' -oc get clusterversion version -o yaml +$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o +jsonpath='{.metadata.annotations}'| jq +'.|has("networkaddonsconfigs.kubevirt.io/jsonpatch")' -If "verified: true", under status history for each item is not present, this is a finding.SRG-APP-000400-CTR-000960<GroupDescription></GroupDescription>CNTR-OS-000760OpenShift must set server token max age no greater than eight hours.<VulnDiscussion>The setting for OAuth server token max age is used to control the maximum duration for which an issued OAuth access token remains valid. Access tokens serve as a form of authentication and authorization in OAuth-based systems. By setting a maximum age for these tokens, OpenShift helps mitigate security risks associated with long-lived tokens. If a token is compromised, its impact is limited to the maximum age duration, as the token will expire and become invalid after that period. It reduces the window of opportunity for unauthorized access and enhances the security of the system. +$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o +jsonpath='{.metadata.annotations}'| jq +'.|has("ssp.kubevirt.io/jsonpatch")' + +If any results are returned aside from empty strings, this is a finding.SRG-APP-000400-CTR-000960<GroupDescription></GroupDescription>CNTR-OS-000760OpenShift must set server token max age no greater than eight hours.<VulnDiscussion>The setting for OAuth server token max age is used to control the maximum duration for which an issued OAuth access token remains valid. Access tokens serve as a form of authentication and authorization in OAuth-based systems. By setting a maximum age for these tokens, OpenShift helps mitigate security risks associated with long-lived tokens. If a token is compromised, its impact is limited to the maximum age duration, as the token will expire and become invalid after that period. It reduces the window of opportunity for unauthorized access and enhances the security of the system. By setting a maximum age for access tokens, OpenShift encourages the use of token refresh rather than relying on the same token for an extended period. Regular token refresh helps maintain a higher level of security by ensuring that tokens are periodically revalidated and rotated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-002007To set the OAuth server token max age, edit the OAuth server object by executing the following: @@ -2568,7 +2790,7 @@ https://docs.openshift.com/container-platform/4.8/applications/pruning-objects.h oc get imagepruners.imageregistry.operator.openshift.io/cluster -o jsonpath='{.spec}{"\n"}' -Review the settings. If "suspend" is set to "true", this is a finding.SRG-APP-000456-CTR-001125<GroupDescription></GroupDescription>CNTR-OS-000890OpenShift must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs.<VulnDiscussion>It is critical to the security and stability of the container platform and the software services running on the platform to ensure that images are deployed through a trusted software supply chain. The OpenShift platform can be configured to limit and control which image source repositories may be used by the platform and the users of the platform. By configuring this to only allow users to deploy images from trusted sources, lowers the risk for a user to deploy unsafe or untested images that would be detrimental to the security and stability of the platform. +Review the settings. If "suspend" is set to "true", this is a finding.SRG-APP-000456-CTR-001125<GroupDescription></GroupDescription>CNTR-OS-000890OpenShift must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs.<VulnDiscussion>It is critical to the security and stability of the container platform and the software services running on the platform to ensure that images are deployed through a trusted software supply chain. The OpenShift platform can be configured to limit and control which image source repositories may be used by the platform and the users of the platform. By configuring this to only allow users to deploy images from trusted sources, lowers the risk for a user to deploy unsafe or untested images that would be detrimental to the security and stability of the platform. In order to help users manage images, OpenShift uses image streams to provide a level of obstruction for the users. In this way the users can trigger automatic redeployments as images are updated. It is also possible to configure the image stream to periodically check the image source repository for any updates and automatically pull in the latest updates.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-002605Edit the cluster image config resource to define the allowed registries by executing the following: @@ -2611,7 +2833,7 @@ status: If nothing is returned, this is a finding. -If the registries listed under allowedRegistries, insecureRegistries, or AllowedRegistriesForImport are not from trusted sources as defined by the organization, this is a finding.SRG-APP-000456-CTR-001130<GroupDescription></GroupDescription>CNTR-OS-000900OpenShift runtime must have updates installed within the period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).<VulnDiscussion>OpenShift runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly. A vulnerable runtime exposes all containers it supports, as well as the host itself, to potentially significant risk. Organizations must use tools to look for Common Vulnerabilities and Exposures (CVEs) in the runtimes deployed, to upgrade any instances at risk, and to ensure that orchestrators only allow deployments to properly maintained runtimes. +If the registries listed under allowedRegistries, insecureRegistries, or AllowedRegistriesForImport are not from trusted sources as defined by the organization, this is a finding.SRG-APP-000456-CTR-001130<GroupDescription></GroupDescription>CNTR-OS-000900OpenShift runtime must have updates installed within the period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).<VulnDiscussion>OpenShift runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly. A vulnerable runtime exposes all containers it supports, as well as the host itself, to potentially significant risk. Organizations must use tools to look for Common Vulnerabilities and Exposures (CVEs) in the runtimes deployed, to upgrade any instances at risk, and to ensure that orchestrators only allow deployments to properly maintained runtimes. Satisfies: SRG-APP-000456-CTR-001130, SRG-APP-000456-CTR-001125</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-002605For container images that are not scheduled to check for updates that otherwise should, update the imagestream to schedule updates for each tag by executing the following: @@ -3849,38 +4071,59 @@ done for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; systemctl is-enabled sshd.service; systemctl is-active sshd.service' 2>/dev/null; done -If the SSHD service is either active or enabled this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-OS-001020Red Hat Enterprise Linux CoreOS (RHCOS) must disable USB Storage kernel module.<VulnDiscussion>Disabling the USB Storage kernel module helps protect against potential data exfiltration or unauthorized access to sensitive data. USB storage devices can be used to transfer data in and out of the system, which poses a risk if unauthorized or untrusted devices are connected. By disabling the USB Storage kernel module, OpenShift can prevent the use of USB storage devices and reduce the risk of data breaches or unauthorized data transfers. +If the SSHD service is either active or enabled this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-OS-001020Red Hat Enterprise Linux CoreOS (RHCOS) must disable USB Storage kernel module.<VulnDiscussion>Disabling the USB Storage kernel module helps protect against potential data exfiltration or unauthorized access to sensitive data. USB storage devices can be used to transfer data in and out of the system, which poses a risk if unauthorized or untrusted devices are connected. By disabling the USB Storage kernel module, OpenShift can prevent the use of USB storage devices and reduce the risk of data breaches or unauthorized data transfers. USB storage devices can potentially introduce malware or malicious code into the system. Disabling the USB Storage kernel module helps mitigate the risk of malware infections or the introduction of malicious software from external storage devices. It prevents unauthorized execution of code from USB storage devices, reducing the attack surface and protecting the system from potential security threats. -Disabling USB storage prevents unauthorized data transfers to and from the system. This helps enforce data loss prevention (DLP) policies and mitigates the risk of sensitive or confidential data being copied or stolen using USB storage devices. It adds an additional layer of control to protect against data leakage or unauthorized data movement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000381Apply the machine config to disable USB Storage to load USB Storage kernel module by executing the following: - -for mcpool in $(oc get mcp -oname | sed "s:.*/::" ); do -echo "apiVersion: machineconfiguration.openshift.io/v1 -kind: MachineConfig -metadata: +Disabling USB storage prevents unauthorized data transfers to and from the system. This helps enforce data loss prevention (DLP) policies and mitigates the risk of sensitive or confidential data being copied or stolen using USB storage devices. It adds an additional layer of control to protect against data leakage or unauthorized data movement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000381Apply the machine config to disable USB Storage to load USB Storage kernel module by executing the following: + + for mcpool in $(oc get mcp -oname | sed 's:.*/::' ); do + echo 'apiVersion: machineconfiguration.openshift.io/v1 + kind: MachineConfig + metadata: name: 80-kernmod-usb-storage-disable-$mcpool labels: - machineconfiguration.openshift.io/role: $mcpool -spec: + machineconfiguration.openshift.io/role: $mcpool + spec: config: - ignition: - version: 3.1.0 - storage: - files: - - contents: - source: data:,install%20usb-storage%20/bin/true%0A - mode: 0644 - path: /etc/modprobe.d/75-kernel_module_usb-storage_disabled.conf - overwrite: true -" | oc apply -f - -doneVerify the operating system disables the ability to load the USB Storage kernel module by executing the following: - -for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n "$HOSTNAME "; grep -r usb-storage /etc/modprobe.d/* | grep -i "/bin/true"' 2>/dev/null; done + ignition: + version: 3.1.0 + storage: + files: + - contents: + source: data:,install%20usb-storage%20/bin/true%0A + mode: 0644 + path: /etc/modprobe.d/75-kernel_module_usb-storage_disabled.conf + overwrite: true + ' | oc apply -f - + done + +Where OpenShift Virtualization is enabled: + +Remove individual devices (e.g. DEVICE_A at index 0): +$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv +--type='json' -p='[ +{"op": "remove", "path": +"/spec/permittedHostDevices/pciHostDevices/0"}, + +]' + +Remove all devices: +$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv +--type='json' -p='[ +{"op": "remove", "path": "/spec/permittedHostDevices"}, +]'Verify the operating system disables the ability to load the USB Storage kernel module by executing the following: + for node in $(oc get node -oname); do oc debug $node -- chroot /host /bin/bash -c 'echo -n '$HOSTNAME '; grep -r usb-storage /etc/modprobe.d/* | grep -i '/bin/true'' 2>/dev/null; done + + install usb-storage /bin/true + +If the command does not return any output, or the line is commented out, and use of USB Storage is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding. -install usb-storage /bin/true +Where OpenShift Virtualization is enabled: +$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv +-ojsonpath='{.spec.permittedHostDevices}' -If the command does not return any output, or the line is commented out, and use of USB Storage is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-OS-001030Red Hat Enterprise Linux CoreOS (RHCOS) must use USBGuard for hosts that include a USB Controller.<VulnDiscussion>USBGuard adds an extra layer of security to the overall OpenShift infrastructure. It provides an additional control mechanism to prevent potential security threats originating from USB devices. By monitoring and controlling USB access, USBGuard helps mitigate risks associated with unauthorized or malicious devices that may attempt to exploit vulnerabilities within the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000381If there is not a USB Controller, this requirement is Not Applicable. +If unapproved devices are listed, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-OS-001030Red Hat Enterprise Linux CoreOS (RHCOS) must use USBGuard for hosts that include a USB Controller.<VulnDiscussion>USBGuard adds an extra layer of security to the overall OpenShift infrastructure. It provides an additional control mechanism to prevent potential security threats originating from USB devices. By monitoring and controlling USB access, USBGuard helps mitigate risks associated with unauthorized or malicious devices that may attempt to exploit vulnerabilities within the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Red Hat OpenShift Container Platform 4.xDISADPMS TargetRed Hat OpenShift Container Platform 4.x5547CCI-000381If there is not a USB Controller, this requirement is Not Applicable. 1. Install the service by executing the following: diff --git a/shared/references/disa-stig-rhcos4-v2r3-xccdf-manual.xml b/shared/references/disa-stig-rhcos4-v2r3-xccdf-manual.xml deleted file mode 120000 index f356703bd8f8..000000000000 --- a/shared/references/disa-stig-rhcos4-v2r3-xccdf-manual.xml +++ /dev/null @@ -1 +0,0 @@ -./disa-stig-ocp4-v2r3-xccdf-manual.xml \ No newline at end of file diff --git a/shared/references/disa-stig-rhcos4-v2r6-xccdf-manual.xml b/shared/references/disa-stig-rhcos4-v2r6-xccdf-manual.xml new file mode 120000 index 000000000000..ec3bbf2b4acd --- /dev/null +++ b/shared/references/disa-stig-rhcos4-v2r6-xccdf-manual.xml @@ -0,0 +1 @@ +./disa-stig-ocp4-v2r6-xccdf-manual.xml \ No newline at end of file