From f8e9f847a334e59459b50de30c294f816e407583 Mon Sep 17 00:00:00 2001 From: Automated Update Date: Tue, 16 Apr 2024 00:04:05 +0000 Subject: [PATCH] Update Benchmarks --- ...bernetes_Engine_STIG_V1R1_Manual-xccdf.xml | 1114 +++++++++++++++++ stigs.json | 22 +- 2 files changed, 1129 insertions(+), 7 deletions(-) create mode 100644 benchmarks/DISA/U_Mirantis_Kubernetes_Engine_STIG_V1R1_Manual-xccdf.xml diff --git a/benchmarks/DISA/U_Mirantis_Kubernetes_Engine_STIG_V1R1_Manual-xccdf.xml b/benchmarks/DISA/U_Mirantis_Kubernetes_Engine_STIG_V1R1_Manual-xccdf.xml new file mode 100644 index 000000000..4e342d32a --- /dev/null +++ b/benchmarks/DISA/U_Mirantis_Kubernetes_Engine_STIG_V1R1_Manual-xccdf.xml @@ -0,0 +1,1114 @@ +acceptedMirantis Kubernetes Engine 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: 1 Benchmark Date: 08 May 20243.4.1.229161.10.01I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-APP-000190-CTR-000500<GroupDescription></GroupDescription>CNTR-MK-000940The Lifetime Minutes and Renewal Threshold Minutes Login Session Controls on MKE must be set.<VulnDiscussion>The "Lifetime Minutes" and "Renewal Threshold Minutes" login session controls in MKE are part of security features that help manage user sessions within the MKE environment. Setting these controls is essential. + +MKE must terminate all network connections associated with a communications session at the end of the session, or as follows: For in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001133CCI-002038CCI-002007Log in to the MKE web UI and navigate to admin >> Admin Settings >> Authentication & Authorization. + +- Below Lifetime Minutes, enter "10". +- Below Renewal Threshold, enter "0". +- Click "Save".Log in to the MKE web UI and navigate to admin >> Admin Settings >> Authentication & Authorization. + +Ensure that "Lifetime Minutes" is set to "10" and "Renewal Threshold Minutes" is set to "0". + +If these settings are not configured as specified, this is a finding.SRG-APP-000133-CTR-000290<GroupDescription></GroupDescription>CNTR-MK-000430In an MSR organization, user permissions and repositories must be configured.<VulnDiscussion>Configuring user permissions, organizations, and repositories in MSR is crucial for maintaining a secure, organized, and efficient container image management environment. This will provide access control, security, and compliance when utilizing MSR.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001499If MSR is not being utilized, this is Not Applicable. + +Set the organizations, user permissions, and repositories in MSR so they are configured per the SSP. + +1. Modify Organizations according to the SSP by logging in to the MSR web UI as Admin and navigating to Organizations. + +To delete an Organization: +- Click on the "Organization". +- Click the "Settings Tab". +- Click "Delete". +- Confirm and click "Delete". + +To Add an Organization: +- Click "New organization". +- Input the Organization name. +- Click "Save". + +To Assign Users to an Organization: +- Click on an Organization. +- Under the Members tab, click "Add user". +- Select "New" or "Existing". +- Fill in User information. +- Click "Save". + +2. Modify Users according to the SSP. +- Navigate to "Users". + +To add a User: +- Click "New User". +- Fill in User information. +- Click "Save". + +To Delete a User: +- Click on the "User". +- Select "Settings Tab". +- Click "Delete User". +- Confirm and click "Delete". + +3. Modify Repositories according to the SSP: +- Click on the User. +- Under the Repositories tab, modify the assigned repositories to what is appropriate per the SSP.If MSR is not being utilized, this is Not Applicable. + +Verify the organization, user permissions, and repositories in MSR are configured per the System Security Plan (SSP). Obtain and review the SSP. + +1. Log in to the MSR web UI as Admin and navigate to "Organizations". Verify the list of organizations are setup per the SSP. + +2. Navigate to "Users" and verify that the list of users are assigned to appropriate organizations per the SSP. + +3. Click on the user and verify the assigned repositories are appropriate per the SSP. + +If the organization, user, or assigned repositories in MSR are not configured per the SSP, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000580User-managed resources must be created in dedicated namespaces.<VulnDiscussion>Dedicated namespaces act as security boundaries, limiting the blast radius in case of security incidents or misconfigurations. If an issue arises within a specific namespace, it is contained within that namespace and does not affect the resources in other namespaces. Kubernetes provides Role-Based Access Control (RBAC) mechanisms, and namespaces are a fundamental unit for access control. Using dedicated namespaces for user-managed resources provides a level of isolation. Each namespace acts as a separate environment, allowing users or teams to deploy their applications and services without interfering with the resources in other namespaces. This isolation helps prevent unintentional conflicts and ensures a more predictable deployment environment.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381Log in to the MKE web UI and navigate to Kubernetes >> Namespaces. + +In the top right corner, enable "Set context for all namespaces". + +Move any user-managed resources from the default, kube-public and kube-node-lease namespaces, to user namespaces. + +- Navigate to Kubernetes >> Services. +- Select the user-managed service. +- Click on the settings wheel in the top right corner to view the .yaml for that service. +- Change the "namespace" to a user namespace. +- Click "Save".This check only applies when using Kubernetes orchestration. + +Log in to the MKE web UI and navigate to Kubernetes >> Namespaces. + +The default namespaces are: "default", "kube-public", and "kube-node-lease". + +1. In the top right corner, if "Set context for all namespaces" is not enabled, this is a finding. + +2. Navigate to Kubernetes >> Services. Confirm that no service except "kubernetes" has the "default" namespace listed. Confirm that only approved system services have the "kube-system" namespace listed. + +If "default" has a service other than the "kubernetes" services, this is a finding. + +If "kube-system" has a service that is not listed in the System Security Plan (SSP), this is a finding.SRG-APP-000033-CTR-000095<GroupDescription></GroupDescription>CNTR-MK-000110Least privilege access and need to know must be required to access MKE runtime and instantiate container images.<VulnDiscussion>To control what is instantiated within MKE, it is important to control access to the runtime. Without this control, container platform specific services and customer services can be introduced without receiving approval and going through proper testing. Only those individuals and roles approved by the organization can have access to the container platform runtime.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000213CCI-001499CCI-001094CCI-001812CCI-001813CCI-001764CCI-002385To remove unauthorized users from the docker group, access the host CLI and run: + +gpasswd -d docker [username to remove] + +To ensure that docker.socket is group owned, execute the following: + +chown root:docker /var/run/docker.sock + +Set the file permissions of the Docker socket file to "660" execute the following: + +chmod 660 /var/run/docker.sockAccess to use the docker CLI must be limited to root only. + +1. Log on to the host CLI and execute the following: + +stat -c %U:%G /var/run/docker.sock | grep -v root:docker + +If any output is present, this is a finding. + +2. Verify that the docker group has only the required users by executing: + +getent group docker + +If any users listed are not required to have direct access to MCR, this is a finding. + +3. Execute the following command to verify the Docker socket file has permissions of 660 or more restrictive: + stat -c %a /var/run/docker.sock + +If permissions are not set to "660", this is a finding.SRG-APP-000142-CTR-000325<GroupDescription></GroupDescription>CNTR-MK-000640Only required ports must be open on containers in MKE.<VulnDiscussion>Ports, protocols, and services within MKE runtime must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DOD Instruction 8551.01 Policy. + +A container can be run just with the ports defined in the Dockerfile for its image or can be arbitrarily passed runtime parameters to open a list of ports. A periodic review of open ports must be performed. + +By default, all the ports that are listed in the Dockerfile under EXPOSE instruction for an image are opened when a container is run with -P or --publish-all flag.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000382CCI-000366Document the ports required for each container in the SSP. + +Fix the container image to expose only needed ports by the containerized application. Ignore the list of ports defined in the Dockerfile by NOT using -P (UPPERCASE) or --publish-all flag when starting the container. Use the -p (lowercase) or --publish flag to explicitly define the ports needed for a particular container instance. + +Example: +docker run --interactive --tty --publish 5000 --publish 5001 --publish 5002 centos /bin/bashThis check must be executed on all nodes in an MKE cluster to ensure that mapped ports are the ones that are needed by the containers. + +Via CLI: +Linux: As an administrator, execute the following command using a Universal Control Plane (MKE) client bundle: + +docker ps --quiet | xargs docker inspect --format '{{ .Id }}: Ports={{ .NetworkSettings.Ports }}' + +Review the list and ensure the ports mapped are those needed for the container. If there are any mapped ports not documented by the System Security Plan (SSP), this is a finding.SRG-APP-000172-CTR-000440<GroupDescription></GroupDescription>CNTR-MK-000870FIPS mode must be enabled.<VulnDiscussion>During any user authentication, MKE must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process. + +FIPS mode enforces the use of cryptographic algorithms and modules. This ensures a higher level of cryptographic security, reducing the risk of vulnerabilities related to cryptographic functions. FIPS-compliant cryptographic modules are designed to provide strong protection for sensitive data. Enabling FIPS mode helps safeguard cryptographic operations, securing data both at rest and in transit within containerized applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000197CCI-001184CCI-002890CCI-003123CCI-002418CCI-002420CCI-002422CCI-002450CCI-000803If the operating system has FIPS enabled, FIPS mode is enabled by default in MCR. The preferred method is to ensure FIPS mode is set on the operating system prior to installation. + +If a change is required on a deployed system, create the directory if it does not exist by executing the following: + +mkdir -p /etc/systemd/system/docker.service.d/ + +Create a file called /etc/systemd/system/docker.service.d/fips-module.conf and add the following: + +[Service] +Environment="DOCKER_FIPS=1" + +Reload the Docker configuration to systemd by executing the following: + +sudo systemctl daemon-reload + +Restart the Docker service by executing the following: + +sudo systemctl restart dockerOn the MKE controller, verify FIPS mode is enabled. + +Execute the following command through the CLI: + +docker info + +The "Security Options" section in the response must show a "fips" label, indicating that, when configured, the remotely accessible MKE UI uses FIPS-validated digital signatures in conjunction with an approved hash function to protect the integrity of remote access sessions. + +If the "fips" label is not shown in the "Security Options" section, then this is a finding.SRG-APP-000023-CTR-000055<GroupDescription></GroupDescription>CNTR-MK-000030MKE must be configured to integrate with an Enterprise Identity Provider.<VulnDiscussion>Configuring MKE to integrate with an Enterprise Identity Provider enhances security, simplifies user management, ensures compliance, provides auditing capabilities, and offers a more seamless and consistent user experience. It aligns MKE with enterprise standards and contributes to a more efficient and secure environment.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000015CCI-000016CCI-000017CCI-000044CCI-000765CCI-000766CCI-000767CCI-000768CCI-000770CCI-001942CCI-000795CCI-000205CCI-000200CCI-000192CCI-000193CCI-000194CCI-001619CCI-000195CCI-000198CCI-000199CCI-000187CCI-001683CCI-001684CCI-001685CCI-001686CCI-002142CCI-002145CCI-002130CCI-002132CCI-002238CCI-001814CCI-001953CCI-002041CCI-002009CCI-002699CCI-000172CCI-000366To configure Identity Provider. +Log in to the MKE web UI and navigate to admin >> Admin Settings >> Authentication & Authorization >> Identity Provider Integration section. + +To configure LDAP: +Click the radial button to set LDAP to "Enabled". + +In the "LDAP Server" subsection set the following: +- "LDAP Server URL" to the URL for the organization's AD or LDAP server (URL must be https). +- "Reader DN" with the DN of the account used to search the LDAP entries. +- "Reader Password" with the password for the Reader account. + +Click "Save". + +To configure SAML: +Click the radial button to set SAML to "Enabled". + +Enter URL in the "Service Provider Metadata URL" field. + +Upload the certificate bundle for the IdP provider in "Root Certificates Bundle". + +In the "SAML Service Provider" section, enter the "MKE IP address" in the MKE Host field. + +Click "Save".Verify that Enterprise Identity Provider integration is enabled and properly configured in the MKE Admin Settings. + +1. Log in to the MKE web UI and navigate to admin >> Admin Settings >> Authentication & Authorization. + +If LDAP or SAML are not set to "Enabled", this is a finding. + +2. Identity Provider configurations: +When using LDAP, ensure the following are set: +- LDAP/AD server's URL. +- Reader DN. +- Reader Password. + +When using SAML: +In the "SAML IdP Server" section, ensure the following: +- URL for the identity provider exists in the "IdP Metadata URL" field. +- Skip TLS Verification is unchecked. +- Root Certificate Bundle is filled. + +In the "SAML Service Provider" section, ensure the MKE Host field has the MKE UI IP address. + +If the Identity Provider configurations do not match the System Security Plan (SSP), this is a finding.SRG-APP-000033-CTR-000095<GroupDescription></GroupDescription>CNTR-MK-000120SSH must not run within Linux containers.<VulnDiscussion>To limit the attack surface of MKE, it is important that the nonessential services are not installed. Containers are designed to be lightweight and isolated, and introducing SSH can add attack vectors. Unauthorized access or exploitation of SSH vulnerabilities would compromise the security of the container and the host system. SSH is not necessary for process management within containers, as container orchestration platforms provide mechanisms for starting, stopping, and monitoring containerized processes. SSH access within containers may bypass auditing mechanisms, making it harder to track and audit user 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 Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000213Containers found with SSH server must be removed by executing the following: + +docker rm [container name] + +Then, a new image must be added with SSH server removed.This check must be executed on all nodes in a Docker Enterprise cluster. + +Verify no running containers have a process for SSH server. Using CLI, execute the following: + +for i in $(docker container ls --format "{{.ID}}"); do + pid=$(docker inspect -f '{{.State.Pid}}' "$i") + ps -h --ppid "$pid" -o cmd +done | grep sshd + +If a container is output, it has a process for SSH server, this is a finding.SRG-APP-000033-CTR-000100<GroupDescription></GroupDescription>CNTR-MK-000130Swarm Secrets or Kubernetes Secrets must be used.<VulnDiscussion>Swarm Secrets in Docker Swarm and Kubernetes Secrets both provide mechanisms for encrypting sensitive data at rest. This adds an additional layer of security, ensuring that even if unauthorized access occurs, the stored secrets remain encrypted. + +MKE keystore must implement encryption to prevent unauthorized disclosure of information at rest within MKE. By leveraging Docker Secrets or Kubernetes secrets to store configuration files and small amounts of user-generated data (up to 500 kb in size), the data is encrypted at rest by the Engine's FIPS-validated cryptography.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000213CCI-001499CCI-000196CCI-002450CCI-002476To create secrets when using Swarm Orchestration, log in to the MKE UI. Navigate to Swarm >> Secrets, and then click "Create". + +Provide a name for the secret and enter the data into the "Content" field. + +Add a label to allow for RBAC features to be used for access to secret. + +Click "Save". + +To create secrets when using Kubernetes orchestration, run the following command on the MKE Controller node: + +Configure the $AUTH variable to contain the token for the SCIM API endpoint. + +curl -X PUT -H 'Accept: application/json' -H "Authorization: Bearer $AUTH" -d '{"KMSEnabled":true,"KMSName"":"<kms_name>","KMSEndpoint":"/var/kms"}' "https://$MKE_ADDRESS/api/MKE/config/kubernetes"Review the System Security Plan (SSP) and identify applications that leverage configuration files and/or small amounts of user-generated data, and ensure the data is stored in Docker Secrets or Kubernetes Secrets. + +When using Swarm orchestration, log in to the MKE web UI and navigate to Swarm >> Secrets and view the configured secrets. + +If items identified for secure storage are not included in the secrets, this is a finding. + +When using Kubernetes orchestration, log on to the MKE Controller node then run the following command: + +kubectl get all -o jsonpath='{range .items[?(@..secretKeyRef)]} {.kind} {.metadata.name} {"\n"}{end}' -A + +Or, using API, configure the $AUTH variable to contain the token for the SCIM API endpoint: + +curl -k 'Accept: application/json' -H "Authorization: Bearer $AUTH" -s "https://$MKE_ADDRESS/api/MKE/config/kubernetes" | jq '.KMSEnabled' true + +If any of the values returned reference environment variables, this is a finding.SRG-APP-000038-CTR-000105<GroupDescription></GroupDescription>CNTR-MK-000140MKE must have Grants created to control authorization to cluster resources.<VulnDiscussion>MKE uses Role-Based Access Controls (RBAC) to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. + +Using an IDP (per this STIG) still requires configure mapping. Refer to the following for more information: https://docs.mirantis.com/mke/3.7/ops/authorize-rolebased-access/rbac-tutorials/access-control-standard.html#access-control-standard.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001368Create Role Bindings/Grants by logging in to the MKE web UI as an MKE Admin. Navigate to Access Control >> Grants. + +Using Kubernetes orchestration: +- Select the "Kubernetes" tab and click "Create Role Binding". +- Add Users, Organizations or Service Accounts as needed and click "Next". +- Under "Resource Set", enable "Apply Role Binding to all namespaces", and then click "Next". +- Under "Role" select a cluster role. +- Click "Create". + +Using Swarm orchestration: +- Select the "Swarm" tab and click "Create Grant". +- Add Users, Organizations, or Service Accounts as needed and click "Next". +- Under "Resource Set", click "View Children" until the required Swarm collection displays, and then click "Next". +- Under "Role" select a cluster role. +- Click "Create".Verify the applied RBAC policies set in MKE are configured per the requirements set forth by the System Security Plan (SSP). + +Log in to the MKE web UI as an MKE Admin and navigate to Access Control >> Grants. + +When using Kubernetes orchestration, select the "Kubernetes" tab and verify that cluster role bindings are configured per the requirements set forth by the SSP. + +When using Swarm orchestration, select the "Swarm" tabs. Verify that all grants are configured per the requirements set forth by the SSP. + +If the grants are not configured per the requirements set forth by the SSP, then this is a finding.SRG-APP-000039-CTR-000110<GroupDescription></GroupDescription>CNTR-MK-000150MKE host network namespace must not be shared.<VulnDiscussion>MKE can be built with privileges that are not approved within the organization. To limit the attack surface of MKE, it is essential that privileges meet organization requirements. + +The networking mode on a container when set to --net=host, skips placing the container inside a separate network stack. This is potentially dangerous because it allows the container process to open low-numbered ports like any other root process. Thus, a container process can potentially do unexpected things such as shutting down the Docker host. Do not use this option. + +By default, bridge mode is used.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001414When using Kubernetes orchestration: +In Kubernetes, the hostNetwork setting is a part of the Pod's specification, and once a Pod is created, its hostNetwork setting cannot be directly modified. However, the desired effect can be achieved by creating a new Pod with the updated hostNetwork setting and then deleting the existing Pod. This process replaces the old Pod with the new one. + +When using Swarm orchestration: +Review and remove nonsystem containers previously created by these users that allowed access to the host network namespace must be removed using: + +docker container rm [container]When using Kubernetes orchestration, ensure that Pods do not use the host machine's network namespace and uses its own isolated network namespace. + +Note: If the hostNetwork field is not explicitly set in the Pod's specification, it will use the default behavior, which is equivalent to hostNetwork: false. + +Execute the following for all pods: + +kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.hostNetwork == true) | .metadata.name' + +If the above command returns a namespace then the "hostNetwork" = true, this is a finding unless a documented exception is present in the System Security Plan (SSP). + +When using Swarm orchestration, check that the host's network namespace is not shared. + +Via CLI: +Linux: As an administrator, execute the following command using a Universal Control Plane (MKE) client bundle: + +docker ps --filter "label=com.docker.ucp.version" | awk '{print $1}' | xargs docker inspect --format '{{ .Name }}: NetworkMode={{ .HostConfig.NetworkMode }}' + +If the above command returns NetworkMode=host, this is a finding unless a documented exception is present in the SSP.SRG-APP-000092-CTR-000165<GroupDescription></GroupDescription>CNTR-MK-000220Audit logging must be enabled on MKE.<VulnDiscussion>Enabling audit logging on MKE enhances security, supports compliance efforts, provides user accountability, and offers valuable insights for incident response and operational management. It is an essential component of maintaining a secure, compliant, and well-managed Kubernetes environment. + +Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001464CCI-000018CCI-001403CCI-001404CCI-001405CCI-000169CCI-000172CCI-000135CCI-002234Log in to the MKE web UI and navigate to admin >> Admin Settings >> Logs & Audit Logs. + +In the "Configure Audit Log Level" section, select "Request" + +In the "Configure Global Log Level" section, select "INFO" or "DEBUG". +Note: The recommended setting is "INFO". + +Click "Save".Check auditing configuration level for MKE nodes and controller: + +Log in to the MKE web UI and navigate to admin >> Admin Settings >> Logs & Audit Logs. + +If "AUDIT LOG LEVEL" is not set to "Request", this is a finding. + +If "DEBUG LEVEL" is set to "ERROR", this is a finding.SRG-APP-000109-CTR-000215<GroupDescription></GroupDescription>CNTR-MK-000310MKE must be configured to send audit data to a centralized log server.<VulnDiscussion>Sending audit data from MKE to a centralized log server enhances centralized monitoring, facilitates efficient incident response, scales effectively, provides redundancy, and helps organizations meet compliance requirements. This is the recommended best practice for managing Kubernetes environments, especially in enterprise settings.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000140CCI-000154CCI-001851CCI-002702Configure logging driver by setting the log-driver and log-opts keys to appropriate values in the daemon.json file. Refer to this link for extra assistance: https://docs.docker.com/config/containers/logging/syslog/. + +Via CLI: +Linux: +1. As a trusted user on the host OS, open the /etc/docker/daemon.json file for editing. If the file does not exist, it must be created. + +2. Set the "log-driver" property to one of the following: +"syslog", "journald", or "<plugin>" (where <plugin> is the naming of a third-party MKE logging driver plugin). +Note: Mirantis recommends the "journald" setting. + +The following example sets the log driver to journald: + +{ + "log-driver": "journald" +} + + +3. Configure the "log-opts" object as required by the selected "log-driver". + +4. Save the file. + +5. Restart the Docker daemon by executing the following: + +sudo systemctl restart docker + +Configure rsyslog to send logs to the SEIM system. + +1. Edit the /etc/rsyslog.conf file and add the IP address of remote server. +Example: *.* @@loghost.example.com + +2. Work with the SIEM administrator to configure an alert when no audit data is received from Mirantis.Check centralized log server configuration. + +Via CLI, execute the following commands as a trusted user on the host operating system: + +cat /etc/docker/daemon.json + +Verify that the "log-driver" property is set to one of the following: "syslog", "journald", or "<plugin>" (where <plugin> is the naming of a third-party Docker logging driver plugin). + +Work with the SIEM administrator to determine if an alert is configured when audit data is no longer received as expected. + +If "log-driver" is not set, or if alarms are not configured in the SIEM, then this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000480MSR's self-signed certificates must be replaced with DOD trusted, signed certificates.<VulnDiscussion>Self-signed certificates pose security risks, as they are not issued by a trusted third party. DOD trusted, signed certificates have undergone a validation process by a trusted CA, reducing the risk of man-in-the-middle attacks and unauthorized access. Using these certificates enhances the trust and authenticity of the communication between clients and the MSR server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381If MSR is not being utilized, this is Not Applicable. + +Ensure the certificates are from a trusted DOD CA. + +1. Add the secret to the cluster by executing the following: + +kubectl create secret tls <secret-name> --key <keyfile>.pem --cert <certfile>.pem + +2. Update MSR with the custom certificate by executing the following: + +helm upgrade msr [REPO_NAME]/msr --version <helm-chart-version> --set-file license=path/to/file/license.lic --set +nginx.webtls.create=false --set nginx.webtls.secretName="<secret-name>"If MSR is not being utilized, this is Not Applicable. + +Check that MSR has been integrated with a trusted certificate authority (CA). + +1. In one terminal window execute the following: +kubectl port-forward service/msr 8443:443 + +2. In a second terminal window execute the following: +openssl s_client -connect localhost:8443 -showcerts </dev/null + +If the certificate chain in the output is not valid and does not match that of the trusted CA, then this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000490Allowing users and administrators to schedule containers on all nodes must be disabled.<VulnDiscussion>MKE and MSR are set to disallow administrators and users to schedule containers. This setting must be checked for allowing administrators or users to schedule containers may override essential settings, and therefore is not permitted.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381Set MKE and MSR to disallow administrators and users to schedule containers. + +Log in to the MKE web UI and navigate to admin >> Admin Settings >> Orchestration. Scroll to down "Container Scheduling". + +Disable the "Allow administrators to deploy containers on MKE managers or nodes running MSR". + +Disable "Allow users to schedule on all nodes, including MKE managers and MSR nodes" options. + +Click "Save".To ensure this setting has not been modified follow these steps on each node: + +Log in to the MKE web UI and navigate to admin >> Admin Settings >> Orchestration. Scroll to down "Container Scheduling". + +Verify that the "Allow administrators to deploy containers on MKE managers or nodes running MSR" is disabled. If it is checked (enabled), this is a finding. + +Verify that the "Allow users to schedule on all nodes, including MKE managers and MSR nodes" is disabled. If it is checked (enabled), this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000500MKE telemetry must be disabled.<VulnDiscussion>MKE provides a telemetry service that automatically records and transmits data to Mirantis through an encrypted channel for monitoring and analysis purposes. While this channel is secure, it introduces an attack vector and 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 Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381Disable usage and API analytics tracking in MKE. + +Log in to the MKE web UI and navigate to admin >> Admin Settings >> Usage. + +Uncheck both the "Enable hourly usage reporting" and "Enable API and UI tracking" options. + +Click "Save".Verify that usage and API analytics tracking is disabled in MKE. + +Log in to the MKE web UI and navigate to admin >> Admin Settings >> Usage. + +Verify the "Enable hourly usage reporting" and "Enable API and UI tracking" options are both unchecked. + +If either box is checked, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000510MSR telemetry must be disabled.<VulnDiscussion>MSR provides a telemetry service that automatically records and transmits data to Mirantis through an encrypted channel for monitoring and analysis purposes. While this channel is secure, it introduces an attack vector and 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 Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381If MSR is not being utilized, this is Not Applicable. + +Disable usage and API analytics tracking in MSR. + +Log in to the MSR web UI and navigate to System >> General Tab. Scroll to the "Analytics" section. + +Click the "Send data" slider to disable this capability.If MSR is not being utilized, this is Not Applicable. + +Verify that usage and API analytics tracking is disabled in MSR. + +Log in to the MSR web UI and navigate to System >> General Tab. Scroll to the "Analytics" section. + +If the "Send data" option is enabled, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000520For MKE's deployed on an Ubuntu host operating system, the AppArmor profile must be enabled.<VulnDiscussion>AppArmor protects the Ubuntu OS and applications from various threats by enforcing security policy which is also known as AppArmor profile. The user can either create their own AppArmor profile for containers or use the Docker default AppArmor profile. This would enforce security policies on the containers as defined in the profile. + +By default, docker-default AppArmor profile is applied for running containers and this profile can be found at /etc/apparmor.d/docker.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381If not using MKE on Ubuntu host operating system, this is Not Applicable. +If AppArmor is not in use, this is Not Applicable. + +This check must be executed on all nodes in a cluster. + +Run on all nonprivileged containers using an AppArmor profile: + +Via CLI: +Linux: Install AppArmor (if not already installed). + +Create/import an AppArmor profile (if not using the "docker-default" profile). Put the profile in "enforcing" model. Execute the following command as a trusted user on the host operating system to run the container using the customized AppArmor profile: + +docker run [options] --security-opt="apparmor:[PROFILENAME]" [image] [command] + +When using the "docker-default" default profile, run the container using the following command instead: + +docker run [options] --security-opt apparmor=docker-default [image] [command]If MKE is not being used on an Ubuntu host operating system, this is Not Applicable. + +If AppArmor is not in use, this is Not Applicable. + +This check must be executed on all nodes in a cluster. + +Via CLI: +Linux: Execute the following command as a trusted user on the host operating system: + +docker ps -a -q | xargs -I {} docker inspect {} --format '{{ .Name }}: AppArmorProfile={{ .AppArmorProfile }}, Privileged={{ .HostConfig.Privileged }}' | grep 'AppArmorProfile=unconfined' | grep 'Privileged=false' + +If any output, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000530If MKE is deployed on a Red Hat or CentOS system, SELinux security must be enabled.<VulnDiscussion>SELinux provides a Mandatory Access Control (MAC) system on RHEL and CentOS that greatly augments the default Discretionary Access Control (DAC) model. The user can thus add an extra layer of safety by enabling SELinux on the RHEL or CentOS host. When applied to containers, SELinux helps isolate and restrict the actions that containerized processes can perform, reducing the risk of container escapes and unauthorized access. + +By default, no SELinux security options are applied on 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 Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381If using MKE on operating systems other than Red Hat Enterprise Linux or CentOS host operating systems where SELinux is in use, this check is Not Applicable. + +Execute on all nodes in a cluster. + +Start MKE with SELinux mode enabled. Run containers using appropriate security options. + +Via CLI: +Linux: Set the SELinux state and policy. Create or import a SELinux policy template for MKE. Then, start MKE with SELinux mode enabled by setting the "selinux-enabled" property to "true" in the "/etc/docker/daemon.json" daemon configuration file. + +Restart MKE.If using MKE on operating systems other than Red Hat Enterprise Linux or CentOS host operating systems where SELinux is in use, this check is Not Applicable. + +Execute on all nodes in a cluster. + +Verify that the appropriate security options are configured for all running containers: + +Via CLI: +Linux: Execute the following command as a user on the host operating system: + +docker info --format '{{.SecurityOptions}}' + +expected output [name=seccomp, profile=default name=selinux name=fips] + +If there is no output or name does not equal SELinux, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000550The Docker socket must not be mounted inside any containers.<VulnDiscussion>The Docker socket docker.sock must not be mounted inside a container, with the exception case being during the installation of Universal Control Plane (UCP) component of Docker Enterprise as it is required for install. + +If the Docker socket is mounted inside a container, it would allow processes running within the container to execute docker commands which effectively allows for full control of the host. + +By default, docker.sock (Linux) and \\.\pipe\docker_engine (Windows) is not mounted inside 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 Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381If using Kubernetes orchestration, this check is Not Applicable. + +When using Swarm orchestration and using the -v/--volume flags to mount volumes to containers in a docker run command, do not use docker.sock as a volume. + +A reference for the docker run command can be found at https://docs.docker.com/engine/reference/run/. + +Review and remove nonsystem containers previously created by these users without the runAsGroup must be removed using: + +docker container rm [container]If using Kubernetes orchestration, this check is Not Applicable. + +When using Swarm orchestration, log in to the CLI as an MKE Admin, and execute the following command using an MKE client bundle: + +docker ps --all --filter "label=com.docker.ucp.version" | xargs docker inspect --format '{{ .Id }}: Volumes={{ .Mounts }}' | grep -i "docker.sock\|docker_engine" + +If the Docker socket is mounted inside containers, this is a finding. + +If "volumes" is not present or if "docker.sock" is listed, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000560Linux Kernel capabilities must be restricted within containers.<VulnDiscussion>By default, MKE starts containers with a restricted set of Linux Kernel Capabilities. Any process may be granted the required capabilities instead of root access. Using Linux Kernel Capabilities, the processes do not have to run as root for almost all the specific areas where root privileges are usually needed. MKE supports the addition and removal of capabilities, allowing the use of a nondefault profile. Remove all capabilities except those explicitly required for the user's container process. + +By default, below capabilities are available for Linux containers: + +AUDIT_WRITE +CHOWN +DAC_OVERRIDE +FOWNER +FSETID +KILL +MKNOD +NET_BIND_SERVICE +NET_RAW +SETFCAP +SETGID +SETPCAP +SETUID +SYS_CHROOT</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381When using Kubernetes orchestration this check is Not Applicable. + +When using Swarm orchestration, review and remove nonsystem containers previously created by these users that allowed capabilities to be added or must be removed using: + +docker container rm [container]When using Kubernetes orchestration this check is Not Applicable. + +When using Swarm orchestration, via CLI: + +Linux: Execute the following command as a trusted user on the host operating system: + +docker ps --quiet --all | xargs docker inspect --format '{{ .Name }}: CapAdd={{ .HostConfig.CapAdd }} CapDrop={{ .HostConfig.CapDrop }}' + +The command will output all Linux Kernel Capabilities. + +If Linux Kernel Capabilities exceed what is defined in the System Security Plan (SSP), this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000570Incoming container traffic must be bound to a specific host interface.<VulnDiscussion>Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. MKE must stop containers that try to map to these ports directly. Allowing nonprivileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container. + +By default, if the user does not specifically declare the container port to host port mapping, MKE automatically and correctly maps the container port to one available in 49153-65535 block on the host. But, MKE allows a container port to be mapped to a privileged port on the host if the user explicitly declared it. This is because containers are executed with NET_BIND_SERVICE Linux kernel capability that does not restrict the privileged port mapping. The privileged ports receive and transmit various sensitive and privileged data. Allowing containers to use them can bring serious implications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381To edit container ports, log in to the MKE web UI and navigate to Shared Resources >> Containers. + +- Locate the container with the incorrect port mapping. +- Click on the container name and stop the container by clicking on the three dots in the upper right hand corner. +- Scroll down to Ports to check if ports have been manually assigned. +- Edit the port to a nonprivileged port.This check must be executed on all nodes in an MKE cluster. + +Verify that no running containers are mapping host port numbers below 1024. + +Via CLI: +Linux: Execute the following command as a trusted user on the host operating system: + +docker ps --quiet --all | xargs docker inspect --format '{{ .Id }}: Ports={{ .NetworkSettings.Ports }}' + +Review the list and ensure that container ports are not mapped to host port numbers below 1024. If they are, then this is a finding. + +Ensure that there is no such container to host privileged port mapping declarations in the Mirantis config file. View the config file. If container to host privileged port mapping declarations exist, this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000590CPU priority must be set appropriately on all containers.<VulnDiscussion>All containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as CPU shares, the user controls the host CPU resources that a container may consume. + +By default, CPU time is divided between containers equally. If CPU shares are not properly set, the container process may have to starve if the resources on the host are not available. If the CPU resources on the host are free, CPU shares do not place any restrictions on the CPU that the container may use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381CCI-002530CCI-002824Set Resource Quotas and CPU priority for each namespace. + +When using Kubernetes orchestration: + +1. Create a resource quota as follows (quotaexample.yaml): + +apiVersion: v1 +kind: ResourceQuota +metadata: + name: mem-cpu-demo +spec: + hard: + requests.cpu: ""1"" + requests.memory: 1Gi + limits.cpu: ""2"" + limits.memory: 2Gi +Where the limits can be set according to the SSP. + +Save this file. + +2. Apply the quota to a namespace within the cluster by executing: + +kubectl apply -f [full path to quotaexample.yaml] --namespace=[name of namespace on cluster] + +This must be repeated for all namespaces. Quotas can differ per namespace as required by the site. + +When using Swarm orchestration: + +1. Set Resource Quotas by executing the following: + +docker exec -it [container name] --memory=""""2g"""" + +This must be repeated for all containers. Quotas can differ per container as required by the site. + +2. Set CPU Priority: + +When using Swarm orchestration to manage the CPU shares between containers, start the container using the --cpu-shares argument. + +For example, run a container as below: + +docker run --interactive --tty --cpu-shares 512 [image] [command] + +In the above example, the container is started with CPU shares of 50 percent of what the other containers use. So, if the other container has CPU shares of 80 percent, this container will have CPU shares of 40 percent. + +Note: Every new container will have 1024 shares of CPU by default. However, this value is shown as "0" if running the command mentioned in the audit section. + +Alternatively: +1. Navigate to /sys/fs/cgroup/cpu/system.slice/ directory. + +2. Check the container instance ID using docker ps. + +3. Inside the above directory (in step 1), there will be a directory called docker-<Instance ID>.scope. For example, docker-4acae729e8659c6be696ee35b2237cc1fe4edd2672e9186434c5116e1a6fbed6.scope. Navigate to this directory. + +4. Find a file named cpu.shares. Execute cat cpu.shares. This will always show the CPU share value based on the system. Even if there are no CPU shares configured using -c or --cpu-shares argument in the docker run command, this file will have a value of 1024. + +By setting one containers CPU shares to 512, it will receive half of the CPU time compared to the other container. Take 1024 as 100 percent and derive the number that set for respective CPU shares. For example, use 512 to set 50 percent and 256 to set 25 percent.Ensure Resource Quotas and CPU priority is set for each namespace. + +When using Kubernetes orchestration: +Log in to the MKE web UI, navigate to Kubernetes >> Namespace, and then click on each defined Namespace. + +If the Namespace states "Quotas Nothing has been defined for this resource." or the limits.cpu or the limits.memory settings do not match the System Security Plan (SSP), this is a finding. + +When using Swarm orchestration: +1. Check Resource Quotas: + +Linux: As an administrator, execute the following command using a Universal Control Plane (MKE) client bundle: + +docker ps --quiet --filter """"label=com.docker.ucp.version"""" | xargs docker inspect --format '{{ .Name }}: Memory={{ .HostConfig.Memory }}' + +If the above command returns "0", it means the memory limits are not in place, and this is a finding. + +2. Check CPU Priority: +When using Swarm orchestration, to ensure CPU priority is set, use the CLI: + +Linux: As an MKE Admin, execute the following command using a Universal Control Plane (MKE) client bundle: + +docker ps --quiet --filter ""label=com.docker.ucp.version"" | xargs docker inspect --format '{{ .Name }}: CpuShares={{ .HostConfig.CpuShares }}' + +Compare the output against the SSP, if any containers are set to "0" or "1024", and they are not documented in the System Security Plan (SSP), this is a finding.SRG-APP-000141-CTR-000315<GroupDescription></GroupDescription>CNTR-MK-000600MKE must use a non-AUFS storage driver.<VulnDiscussion>The aufs storage driver is an old driver based on a Linux kernel patch-set that is unlikely to be merged into the main Linux kernel. aufs driver is also known to cause some serious kernel crashes. aufs only has legacy support from Docker. Most importantly, aufs is not a supported driver in many Linux distributions using latest Linux kernels.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000382Modify Storage Driver setting. + +Via CLI as a trusted user on the underlying host operating system: + +If the daemon.json file does not exist, it must be created. + +"/etc/docker/daemon.json" + +Edit the "/etc/docker/daemon.json" file and set the "storage-driver" property to a value that is not "aufs" or "btrfs". +{ + "storage-driver": "overlay2" +} + +Restart the Docker daemon by executing the following: + +sudo systemctl restart dockerThe default storage driver for MCR is overlay2. To confirm this has not been changed via CLI: + +As a trusted user on the underlying host operating system, execute the following command: + +docker info | grep -e "Storage Driver:" + +If the Storage Driver setting contains *aufs or *btrfs, then this is a finding. If the above command returns no values, this is not a finding.SRG-APP-000141-CTR-000320<GroupDescription></GroupDescription>CNTR-MK-000610MKE's self-signed certificates must be replaced with DOD trusted, signed certificates.<VulnDiscussion>Self-signed certificates pose security risks, as they are not issued by a trusted third party. DOD trusted, signed certificates have undergone a validation process by a trusted CA, reducing the risk of man-in-the-middle attacks and unauthorized access. MKE uses TLS to protect sessions. Using trusted certificates ensures that only trusted sources can access the MKE cluster.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381CCI-000185If Kubernetes ingress is being used, this is Not Applicable. + +Integrate MKE and MSR (if used) with a trusted certificate authority CA. + +Log in to the MKE web UI and navigate to admin >> Admin Settings >> Certificates. + +Either fill in the "CA Certificate" field with the contents of the external public CA certificate or upload a file. + +Either fill in the "Server Certificate" and "Private Key" fields with the contents of the public/private certificates or upload a file. + +The "Server Certificate" field must include both the MKE server certificate and any intermediate certificates. + +Click "Save".If Kubernetes ingress is being used, this is Not Applicable. + +Check that MKE has been integrated with a trusted certificate authority (CA). + +Log in to the MKE web UI and navigate to admin >> Admin Settings >> Certificates. + +Click "Download MKE Server CA Certificate". + +Verify that the contents of the downloaded "ca.pem" file match that of the trusted CA certificate. + +If the certificate chain does not match the chain as defined by the System Security Plan (SSP), then this is a finding.SRG-APP-000141-CTR-000320<GroupDescription></GroupDescription>CNTR-MK-000620The "Create repository on push" option in MSR must be disabled.<VulnDiscussion>Allowing repositories to be created on a push can override essential settings and must not be allowed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000381If MSR is not being utilized, this is Not Applicable. + +Verify the "Create repository on push" option is disabled in MSR: + +Log in to the MSR web UI as an administrator and navigate to System >> General Tab >>Repositories Section. + +Set the "Create repository on push" slider to off.If MSR is not being utilized, this is Not Applicable. + +Verify the "Create repository on push" option is disabled in MSR: + +Log in to the MSR web UI as an administrator and navigate to System >> General Tab >>Repositories Section. + +Verify the "Create repository on push" slider is turned off. If it is turned on, this is a finding.SRG-APP-000142-CTR-000330<GroupDescription></GroupDescription>CNTR-MK-000650Containers must not map to privileged ports.<VulnDiscussion>Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. MKE must stop containers that try to map to these ports directly. Allowing nonprivileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container. + +By default, if the user does not specifically declare the container port to host port mapping, MKE automatically and correctly maps the container port to one available in 49153-65535 block on the host. But, MKE allows a container port to be mapped to a privileged port on the host if the user explicitly declared it. This is because containers are executed with NET_BIND_SERVICE Linux kernel capability that does not restrict the privileged port mapping. The privileged ports receive and transmit various sensitive and privileged data. Allowing containers to use them can bring serious implications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000382To edit container ports, log in to the MKE web UI and navigate to Shared Resources >> Containers. + +- Locate the container with the incorrect port mapping. +- Click on the container name and stop the container by clicking the three dots in the upper right corner. +- Scroll down to Ports and check if ports have been manually assigned. +- Edit the port to a nonprivileged port.This check must be executed on all nodes in an MKE cluster. + +Verify no running containers are mapping host port numbers below 1024. + +Via CLI: +Linux: Execute the following command as a trusted user on the host operating system: + +docker ps --quiet --all | xargs docker inspect --format '{{ .Id }}: Ports={{ .NetworkSettings.Ports }}' + +Review the list and ensure container ports are not mapped to host port numbers below 1024. If they are, then this is a finding.SRG-APP-000148-CTR-000345<GroupDescription></GroupDescription>CNTR-MK-000680MKE must not permit users to create pods that share host process namespace.<VulnDiscussion>Controlling information flow between MKE components and container user services instantiated by MKE must enforce organization-defined information flow policies. Example methods for information flow control are: using labels for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume. Process ID (PID) namespaces isolate the PID number space, meaning that processes in different PID namespaces can have the same PID. This is process level isolation between containers and the host. + +PID namespace provides separation of processes and removes the view of the system processes, and allows process IDs to be reused including PID 1. If the host's PID namespace is shared with the container, it would allow processes within the container to view all of the processes on the host system. + +Container processes cannot view the processes on the host system. In certain cases, such as system-level containers, the container must share the host's process namespace. System-level containers have a defined label and this access must be documented. + +By default, all containers have the PID namespace enabled and the host's process namespace is not shared with the 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 Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000764When using Kubernetes orchestration, this check is Not Applicable. + +Using Swarm orchestration, review and remove nonsystem containers previously created by these users utilizing shared namespaces or with a PidMode=host using the following: + +docker container rm [container]When using Kubernetes orchestration, this check is Not Applicable. + +When using Swarm orchestration, to ensure the host's process namespace is not shared, log in via CLI: + +Execute the following using the MKE client bundle: + +container_ids=$(docker ps --quiet --filter=label=com.docker.ucp.version) +for container_id in $container_ids +do + container_name=$(docker inspect -f '{{.Name}}' $container_id | cut -c2-) + pid_mode=$(docker inspect -f '{{.HostConfig.PidMode}}' $container_id) + + echo "Container Name: $container_name, ID: $container_id, PidMode: $pid_mode" +done + +If PidMode = "host", this is a finding.SRG-APP-000158-CTR-000390<GroupDescription></GroupDescription>CNTR-MK-000770IPSec network encryption must be configured.<VulnDiscussion>IPsec encrypts the data traffic between nodes in a Kubernetes cluster, ensuring that the information exchanged is confidential and protected from unauthorized access. This is particularly important when sensitive or confidential data is transmitted over the network. IPsec not only provides encryption but also ensures the integrity of the transmitted data. Through the use of cryptographic mechanisms, IPsec can detect and prevent tampering or modification of data during transit. + +In a Kubernetes cluster managed by MKE, nodes communicate with each other for various purposes, such as pod networking, service discovery, and cluster coordination. IPsec helps secure these communications, reducing the risk of man-in-the-middle attacks and unauthorized interception.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000778To configure IPSec network encryption in Swarm orchestration, create an overlay network with --opt encrypted flag. + +Example: +docker network create --opt encrypted --driver overlay my-network + +To configure IPSec network encryption in Kubernetes orchestration, modify an existing MKE configuration. + +Working as an MKE admin, use the config-toml API from within the directory of your client certificate bundle to export the current MKE settings to a TOML file (mke-config.toml). + +1. Define the following environment variables: + +export MKE_USERNAME=<mke-username> +export MKE_PASSWORD=<mke-password> +export MKE_HOST=<mke-fqdm-or-ip-address> + +2. Obtain and define an AUTHTOKEN environment variable by executing the following: + +AUTHTOKEN=$(curl --silent --insecure --data '{"username":"'$MKE_USERNAME'","password":"'$MKE_PASSWORD'"}' https://$MKE_HOST/auth/login | jq --raw-output .auth_token) + +3. Download the current MKE configuration file by executing the following: + +curl --silent --insecure -X GET "https://$MKE_HOST/api/MKE/config-toml" -H "accept: application/toml" -H "Authorization: Bearer $AUTHTOKEN" > mke-config.toml + +4. Modify "secure_overlay" settings to "true". + +5. Upload the newly edited MKE configuration file by executing the following: + +curl --silent --insecure -X PUT -H "accept: application/toml" -H "Authorization: Bearer $AUTHTOKEN" --upload-file 'mke-config.toml' https://$MKE_HOST/api/MKE/config-toml + +Note: Users may need to reacquire AUTHTOKEN, if significant time has passed since it was first attained.Verify IPSec network encryption. + +For Swarm orchestration log in to the MKE web UI and navigate to Swarm >> Networks. + +If the "scope" is not local and the "driver" is not overlay, this is a finding. + +Kubernetes orchestration: +Note: The path may need to be edited. + +cat /etc/mke/config.toml | grep secure_overlay + +If the "secure_overlay" settings is not set to "true", this is a finding.SRG-APP-000226-CTR-000575<GroupDescription></GroupDescription>CNTR-MK-000980MKE must preserve any information necessary to determine the cause of the disruption or failure.<VulnDiscussion>When a failure occurs within MKE, preserving the state of MKE and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001665When using Swarm orchestration, this check is Not Applicable. + +This is a catastrophic error, contact Mirantis support.When using Swarm orchestration, this check is Not Applicable. + +Review the Kubernetes configuration to determine if information necessary to determine the cause of a disruption or failure is preserved. + +Notes: +- The ReadWriteOnce access mode in the PVC means the volume can be mounted as read-write by a single node. Ensure the storage backend supports this mode. +- Adjust the sleep duration in the writer pod as needed. +- Ensure that the namespace and PVC names match the setup. + +Steps to verify data durability: +1. Create a namespace to manage the testing: + +apiVersion: v1 +kind: Namespace +metadata: + name: stig + +2. PersistentVolumeClaim (PVC): +Ensure a PVC is created. If using a storage class like Longhorn, it would look similar to: + +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: stig-pvc + namespace: stig +spec: + accessModes: + - ReadWriteOnce + storageClassName: longhorn # Replace with your storage class if different, e.g. NFS + resources: + requests: + storage: 5Gi + +3. Deploying the Initial Pod: +Create a pod that writes data to the PVC. This pod will use a simple loop to write data (e.g., timestamps) to a file on the mounted PVC. Example: + +apiVersion: v1 +kind: Pod +metadata: + name: write-pod + namespace: stig +spec: + volumes: + - name: log-storage + persistentVolumeClaim: + claimName: stig-pvc + containers: + - name: writer + image: busybox + command: ["/bin/sh", "-c"] + args: ["while true; do date >> /data/logs.log; sleep 10; done"] + volumeMounts: + - name: log-storage + mountPath: /data + +4. Simulate Pod Failure: +After the pod has been writing data for some time, it can be deleted to simulate a failure by executing the following: + +kubectl delete pod write-pod -n stig + +5. Deploying a New Pod to Verify Data: +Deploy another pod that mounts the same PVC to verify that the data is still there. + +apiVersion: v1 +kind: Pod +metadata: + name: read-pod + namespace: stig +spec: + volumes: + - name: log-storage + persistentVolumeClaim: + claimName: stig-pvc + containers: + - name: reader + image: busybox + command: ["/bin/sh", "-c"] + args: ["sleep infinity"] + volumeMounts: + - name: log-storage + mountPath: /data + +6. Verify Data Persistence: +Check the contents of the log file in the new pod to ensure that the data written by the first pod is still there by executing the following: + +kubectl exec read-pod -n stig -- cat /data/logs.log + +If there is no log data, this is a finding.SRG-APP-000233-CTR-000585<GroupDescription></GroupDescription>CNTR-MK-000990MKE must enable kernel protection.<VulnDiscussion>System kernel is responsible for memory, disk, and task management. The kernel provides a gateway between the system hardware and software. Kubernetes requires kernel access to allocate resources to the Control Plane. Threat actors that penetrate the system kernel can inject malicious code or hijack the Kubernetes architecture. It is vital to implement protections through Kubernetes components to reduce the attack surface.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001084When using Kubernetes orchestration, edit the Kubernetes Kubelet file in the /etc/sysconfig directory on the Kubernetes Control Plane. Set the argument "--protect-kernel-defaults" to "true". + +Reset Kubelet service using the following command: + +service kubelet restart + +When using Swarm orchestration, review and remove nonsystem containers previously created by these users that allowed capabilities to be added or must be removed using: + +docker container rm [container]Verify kernel protection. + +When using Kubernetes orchestration, change to the /etc/sysconfig/ directory on the Kubernetes Control Plane using the command: + +grep -i protect-kernel-defaults kubelet + +If the setting "protect-kernel-defaults" is set to false or not set in the Kubernetes Kubelet, this is a finding. + +When using Swarm orchestration: + +Linux: Execute the following command as a trusted user on the host operating system: + +docker ps --quiet --all | xargs docker inspect --format '{{ .Name }}: CapAdd={{ .HostConfig.CapAdd }} CapDrop={{ .HostConfig.CapDrop }}' + +The command will output all Linux Kernel Capabilities. + +If Linux Kernel Capabilities exceed what is defined in the System Security Plan (SSP), this is a finding.SRG-APP-000243-CTR-000595<GroupDescription></GroupDescription>CNTR-MK-001010All containers must be restricted from acquiring additional privileges.<VulnDiscussion>To limit the attack surface of MKE, it is important that the nonessential services are not installed and access to the host system uses the concept of least privilege. + +Restrict the container from acquiring additional privileges via suid or sgid bits. + +A process can set the no_new_priv bit in the kernel. It persists across fork, clone, and execve. The no_new_priv bit ensures that the process or its children processes do not gain any additional privileges via suid or sgid bits. This way, many dangerous operations become a lot less dangerous because there is no possibility of subverting privileged binaries. + +no_new_priv prevents LSMs like SELinux from transitioning to process labels that have access not allowed to the current process.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001090CCI-002233Start the containers using the following: + +docker run --rm -it --security-opt=no-new-privileges <image> + +A reference for the Docker run command can be found at https://docs.docker.com/engine/reference/run/. + +no-new-privileges command information can be found here: https://docs.mirantis.com/mke/3.7/install/plan-deployment/mcr-considerations/no-new-privileges.html.This check must be executed on all nodes in an MKE cluster to ensure all containers are restricted from acquiring additional privileges. + +Via CLI: +Linux: As an MKE Admin, execute the following command using a Universal Control Plane (MKE) client bundle: + +docker ps --quiet --all | xargs -L 1 docker inspect --format '{{ .Id }}: SecurityOpt={{ .HostConfig.SecurityOpt }}' + +The above command returns the security options currently configured for the running containers. If the "SecurityOpt=" setting does not include the "no-new-privileges" flag, this is a finding.SRG-APP-000243-CTR-000600<GroupDescription></GroupDescription>CNTR-MK-001020Host IPC namespace must not be shared.<VulnDiscussion>IPC (POSIX/SysV IPC) namespace provides separation of named shared memory segments, semaphores, and message queues. IPC namespace on the host must not be shared with the containers and remain isolated unless required. + +If the host's IPC namespace is shared with the container, it would allow processes within the container to view all of the IPC on the host system. This breaks the benefit of IPC level isolation between the host and the containers. Having access to the container can eventually manipulate the host IPC. Do not share the host's IPC namespace with the containers. Only containers with the proper label will share IPC namespace and this access must be documented.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001090CCI-002530Modify IpcMode for a container by logging in to the MKE WebUI and navigating to admin >> Admin Settings >> Privileges. +- Uncheck hostIPC. +- Click "Save".Check if the "IpcMode" is set to "host" for a running or stopped container. + +Log in to the MKE WebUI and Navigate to admin >> Admin Settings >> Privileges. + +If hostIPC is checked for User account privileges or Service account privileges, consult the System Security Plan (SSP). + +If hostIPC is not allowed per the SSP, this is a finding.SRG-APP-000342-CTR-000775<GroupDescription></GroupDescription>CNTR-MK-001160All containers must be restricted to mounting the root filesystem as read only.<VulnDiscussion>The container's root filesystem must be treated as a "golden image" by using Docker run's --read-only option. This prevents any writes to the container's root filesystem at container runtime and enforces the principle of immutable infrastructure. + +Enabling this option forces containers at runtime to explicitly define their data writing strategy to persist or not persist their data. This also reduces security attack vectors since the container instance's filesystem cannot be tampered with or written to unless it has explicit read-write permissions on its filesystem folder and directories.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-002233When using Kubernetes orchestration, this check is Not Applicable. + +When using Swarm orchestration, review and remove nonsystem containers previously created by these users with read write permissions using: + +docker container rm [container] + +Add a --read-only flag at a container's runtime to enforce the container's root filesystem to be mounted as read only: + +docker run <Run arguments> --read-only <Container Image Name or ID> <Command> + +Enabling the --read-only option at a container's runtime must be used by administrators to force a container's executable processes to only write container data to explicit storage locations during the container's runtime. + +Examples of explicit storage locations during a container's runtime include, but are not limited to: + +1. Use the --tmpfs option to mount a temporary file system for nonpersistent data writes. Example: + +docker run --interactive --tty --read-only --tmpfs "/run" --tmpfs "/tmp" [image] [command] + +2. Enabling Docker rw mounts at a container's runtime to persist container data directly on the Docker host filesystem. Example: + +docker run --interactive --tty --read-only -v /opt/app/data:/run/app/data:rw [image] [command] + +3. Utilizing Docker shared-storage volume plugins for Docker data volume to persist container data. + +docker volume create -d convoy --opt o=size=20GB my-named-volume + +docker run --interactive --tty --read-only -v my-named-volume:/run/app/data [image] [command]When using Kubernetes orchestration, this check is Not Applicable. + +For Swarm orchestration, check via CLI: + +Linux: As an MKE Admin, execute the following command using a Universal Control Plane (MKE) client bundle: + +docker ps --quiet --all | xargs -L 1 docker inspect --format '{{ .Name }}: ReadonlyRootfs={{ .HostConfig.ReadonlyRootfs }}' + +If ReadonlyRootfs=false, it means the container's root filesystem is writable and this is a finding.SRG-APP-000342-CTR-000775<GroupDescription></GroupDescription>CNTR-MK-001170The default seccomp profile must not be disabled.<VulnDiscussion>Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The default seccomp profile works on a whitelist basis and allows 311 system calls, blocking all others. It must not be disabled unless it hinders the container application usage. The default seccomp profile blocks syscalls, regardless of --cap-add passed to the container. + +A large number of system calls are exposed to every user and process, with many of them going unused for the entire lifetime of the process. Most of the applications do not need all the system calls and thus benefit by having a reduced set of available system calls. The reduced set of system calls reduces the total kernel surface exposed to the application and thus improvises application security. + +When running a container, it uses the default profile unless it is overridden with the --security-opt option.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-002233When using Kubernetes orchestration, this check is Not Applicable. + +When using Swarm orchestration, do not pass unconfined flags to run a container without the default seccomp profile. Refer to seccomp documentation for details: https://docs.docker.com/engine/security/seccomp/.When using Kubernetes orchestration, this check is Not Applicable. + +For Swarm orchestration, to ensure the default seccomp profile is not disabled, log in to the CLI: + +Linux: As an MKE Admin, execute the following command using a Universal Control Plane (MKE) client bundle: + +docker ps --quiet --filter "label=com.docker.ucp.version" | xargs docker inspect --format '{{ .Id }}: SecurityOpt={{ .HostConfig.SecurityOpt }}' + +If seccomp:=unconfined, then the container is running without any seccomp profiles and this is a finding.SRG-APP-000342-CTR-000775<GroupDescription></GroupDescription>CNTR-MK-001180Docker CLI commands must be run with an MKE client trust bundle and without unnecessary permissions.<VulnDiscussion>Running docker CLI commands remotely with a client trust bundle ensures that authentication and role permissions are checked for the command. + +Using --privileged option or --user option in docker exec gives extended Linux capabilities to the command. Do not run docker exec with the --privileged or --user options, especially when running containers with dropped capabilities or with enhanced restrictions. By default, docker exec command runs without --privileged or --user options.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-002233CCI-001991Docker CLI command must only be run with a client bundle and must not use --privileged or --user option. + +Refer to https://docs.mirantis.com/mke/3.7/ops/access-cluster/client-bundle/configure-client-bundle.html?highlight=client%20bundle.The host OS must be locked down so that only authorized users with a client bundle can access docker commands. + +To ensure that no commands with privilege or user authorizations are present via CLI: + +Linux: As a trusted user on the host operating system, use the below command to filter out docker exec commands that used --privileged or --user option. + +sudo ausearch -k docker | grep exec | grep privileged | grep user + +If there are any in the output, then this is a finding.SRG-APP-000342-CTR-000775<GroupDescription></GroupDescription>CNTR-MK-001200MKE users must not have permissions to create containers or pods that share the host user namespace.<VulnDiscussion>To limit the attack surface of MKE, it is important that the nonessential services are not installed and access to the host system uses the concept of least privilege. + +User namespaces ensure that a root process inside the container will be mapped to a nonroot process outside the container. Sharing the user namespaces of the host with the container thus does not isolate users on the host with users on the containers. + +By default, the host user namespace is shared with the containers until user namespace support is enabled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-002233When using Kubernetes orchestration, this check is Not Applicable. + +When using Swarm orchestration, review and remove nonsystem containers previously created by these users without the runAsGroup using: + +docker container rm [container]When using Kubernetes orchestration, this check is Not Applicable. + +When using Swarm orchestration, ensure that the PIDs cgroup limit is used. + +Log in to the CLI as an MKE Admin and execute the following command using a Universal Control Plane (MKE) client bundle: + +docker ps --quiet --all | xargs docker inspect --format '{{ .Id }}: UsernsMode={{ .HostConfig.UsernsMode }}' + +Ensure it does not return any value for UsernsMode. If it returns a value of "host", that means the host user namespace is shared with the containers, and this is a finding.SRG-APP-000342-CTR-000775<GroupDescription></GroupDescription>CNTR-MK-001220Use of privileged Linux containers must be limited to system containers.<VulnDiscussion>Using the --privileged flag gives all Linux Kernel Capabilities to the container, thus overwriting the --cap-add and --cap-drop flags. The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller. Any container that requires this privilege must be documented and approved.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-002233When using Kubernetes orchestration, this check is Not Applicable. + +Review and remove nonsystem containers previously created by these users that allowed privileged execution using: + +docker container rm [container]When using Kubernetes orchestration, this check is Not Applicable. + +When using Swarm orchestration, execute the following command as a trusted user on the host operating system via CLI: + +docker ps --quiet --all | grep -iv "MKE\|kube\|dtr" | awk '{print $1}' | xargs docker inspect --format '{{ .Id }}: Privileged={{ .HostConfig.Privileged }}' + +Verify in the output that no containers are running with the --privileged flag. If there are, this is a finding.SRG-APP-000383-CTR-000910<GroupDescription></GroupDescription>CNTR-MK-001360The network ports on all running containers must be limited to required ports.<VulnDiscussion>To validate that the services are using only the approved ports and protocols, the organization must perform a periodic scan/review of MKE and disable functions, ports, protocols, and services deemed to be unneeded or nonsecure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001762Configuring an ingress controller is the preferred method to manage external ports. If an ingress controller is not used and unnecessary ports are in use, the container or pod network configurations must be updated. + +To update a pod's configuration, log in to the MKE UI as an administrator. + +Navigate to Kubernetes >> Pods and click the pod with an open port that is not allowed. + +Click the three dots in the upper right corner (edit). + +Modify the .yaml file to remove the port. Example: + +spec: + container: + - name: [pod name] + ports: + - containerPort: 80 [replace with 443] + +Click "Save". + +For a Swarm service, navigate to Swarm >> Services and click on the service with unauthorized port. + +Click the three dots in the top left corner. + +Select "Network" in the pop-up and remove the unauthorized port. + +Click "Save".Verify that only needed ports are open on all running containers. If an ingress controller is configured for the cluster, this check is not applicable. + +Via CLI: As a remote MKE admin, execute the following command using a client bundle: + +docker ps -q | xargs docker inspect --format '{{ .Id }}: Ports={{ .NetworkSettings.Ports }}' + +Review the list and ensure that the ports mapped are the ones really needed for the containers per the requirements set forth by the System Security Plan (SSP). + +If ports are not documented and approved in the SSP, this is a finding.SRG-APP-000386-CTR-000920<GroupDescription></GroupDescription>CNTR-MK-001380MKE must only run signed images.<VulnDiscussion>Controlling the sources where container images can be pulled from allows the organization to define what software can be run within MKE. Allowing any container image to be introduced and instantiated within MKE may introduce malicious code and vulnerabilities to the platform and the hosting system. + +MKE registry must deny all container images except for those signed by organizational-approved sources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001774CCI-001749On each node, enable Content Trust enforcement in MKE. + +1. Log in to the MKE web UI and navigate to admin >> Admin Settings >> Docker Content Trust. + +Under Content Trust Settings section, enable "Run only signed images". + +2. Log in to the MKE web UI and navigate to admin >> Admin Settings >> Docker Content Trust. + +Click "Add Team +" and set the appropriate Orgs and Teams that must sign images. Use the drop-down ("v") that follows to match the organizational policies. + +Remove any unwanted teams by clicking the minus symbol. + +Click "Save". + +3. Manually remove any unsigned images sitting on an MKE cluster by executing the following: + +docker rmi <IMAGE_ID>On each node, check that MKE is configured to only run images signed by applicable Orgs and Teams. + +1. Log in to the MKE web UI and navigate to admin >> Admin Settings >> Docker Content Trust. + +If Content Trust Settings "Run only signed images" is disabled, this is a finding. + +2. Verify that the Orgs and Teams that images must be signed by in the drop-down matches the organizational policies. + +If an Org or Team selected does not match organizational policies, this is a finding. + +3. Verify that all images sitting on an MKE cluster are signed. + +Via CLI: +Linux: As an MKE Admin, execute the following commands using a client bundle: + +docker trust inspect $(docker images | awk '{print $1 ":" $2}') + +Verify that all image tags in the output have valid signatures. If the images are not signed, this is a finding.SRG-APP-000414-CTR-001010<GroupDescription></GroupDescription>CNTR-MK-001490Vulnerability scanning must be enabled for all repositories in MSR.<VulnDiscussion>Enabling vulnerability scanning for all repositories in Mirantis Secure Registry (MSR) is a critical security practice that helps organizations identify and mitigate potential security risks associated with container images. + +Enabling scanning for all repositories in MSR helps identify and prioritize security issues that could pose risks to the containerized applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-001067CCI-002605CCI-000366If MSR is not being utilized, this is Not Applicable. + +Enable vulnerability scanning on the MSR UI by logging in to the MSR web UI and navigating to System >> Security Tab. + +Click the "Enable Scanning" slider to enable this capability. + +Sync (online) or upload (offline) the vulnerability database.If MSR is not being utilized, this is Not Applicable. + +Check image vulnerability scanning enabled for all repositories. + +Log in to the MSR web UI and navigate to System >> Security Tab. + +Verify that the "Enable Scanning" slider is turned on and the vulnerability database has been successfully synced (online) or uploaded (offline). + +If the "Enable Scanning" slider is tuned off, this is a finding. + +If the vulnerability database is not synced or uploaded, this is a finding.SRG-APP-000454-CTR-001110<GroupDescription></GroupDescription>CNTR-MK-001600Older Universal Control Plane (MKE) and Docker Trusted Registry (DTR) images must be removed from all cluster nodes upon upgrading.<VulnDiscussion>When upgrading either the UCP or DTR components of MKE, the newer images are pulled (or unpacked if offline) onto engine nodes in a cluster. Once the upgrade is complete, one must manually remove all old image version from the cluster nodes to meet the requirements of this control. + +When upgrading the Docker Engine - Enterprise component of MKE, the old package version is automatically replaced.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-002617Remove all outdated MKE and DTR container images from all nodes in the cluster: + +Via CLI: As an MKE admin, execute the following commands using a client bundle: + +docker rmi -f $(docker images --filter reference='mirantis/ucp*:[outdated_tags]' -q) +docker rmi -f $(docker images --filter reference='registry.mirantis.com/msr/[msr]*:[outdated_tags]' -q)Verify all outdated MKE and DTR container images have been removed from all nodes in the cluster. + +Via CLI: As an MKE admin, execute the following command using a client bundle: + +docker images --filter reference='mirantis/[ucp]*' +docker images --filter reference='registry.mirantis.com/msr/[msr]*' + +Verify there are no tags listed older than the currently installed versions of MKE and DTR. + +If any of the tags listed are older than the currently installed versions of MKE and DTR, then this is a finding. If no tags are listed, this is not a finding.SRG-APP-000456-CTR-001130<GroupDescription></GroupDescription>CNTR-MK-001630MKE must contain the latest updates.<VulnDiscussion>MKE must stay up to date with the latest patches, service packs, and hot fixes. Not updating MKE will expose the organization to vulnerabilities.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-002605Note: It is advisable to review the release notes to understand what changes and improvements come with the new version. + +Log in to the MKE WebUI and navigate to admin >> Admin Settings >> Upgrade. + +In the "Choose MKE Version" section, select the drop-down. Follow the on-screen instructions to start the upgrade.Check for updates by logging in to the MKE WebUI and Navigating to admin >> Admin Settings >> Upgrade. + +In the "Choose MKE Version" section, select the drop-down. The UI will provide a list of available versions. + +If an updated version is available in the list, this is a finding.SRG-APP-000068-CTR-000120<GroupDescription></GroupDescription>CNTR-MK-000170MKE must display the Standard Mandatory DOD Notice and Consent Banner before granting access to platform components.<VulnDiscussion>MKE has countless components where different access levels are needed. To control access, the user must first log in to MKE 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 Mirantis Kubernetes EngineDISADPMS TargetMirantis Kubernetes Engine5595CCI-000048Configure MKE to display the Standard Mandatory DOD Notice and Consent Banner before granting access to MKE: + +Modify the existing MKE configuration: +Working as an MKE admin, use the config-toml API from within the directory of the client certificate bundle to export the current MKE settings to a TOML file (mke-config.toml). + +1. Define the following environment variables: + +export MKE_USERNAME=<mke-username> +export MKE_PASSWORD=<mke-password> +export MKE_HOST=<mke-fqdm-or-ip-address> + +2. Obtain and define an AUTHTOKEN environment variable by executing the following: + +AUTHTOKEN=$(curl --silent --insecure --data '{"username":"'$MKE_USERNAME'","password":"'$MKE_PASSWORD'"}' https://$MKE_HOST/auth/login | jq --raw-output .auth_token) + +3. Download the current MKE configuration file by executing the following: + +curl --silent --insecure -X GET "https://$MKE_HOST/api/MKE/config-toml" -H "accept: application/toml" -H "Authorization: Bearer $AUTHTOKEN" > mke-config.toml + +4. Edit the MKE configuration (mke-config.toml) modify "pre_logon_message" settings to match the Standard Mandatory DOD Notice and Consent Banner. + +Example: + pre_logon_message = "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions :\n\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." + +5. Upload the edited MKE configuration file by executing the following: + +curl --silent --insecure -X PUT -H "accept: application/toml" -H "Authorization: Bearer $AUTHTOKEN" --upload-file 'mke-config.toml' https://$MKE_HOST/api/MKE/config-toml + +Note: Users may need to reacquire the AUTHTOKEN, if significant time has passed since it was first acquired. + +6. Log in to MKE and verify that the Standard Mandatory DOD Notice and Consent Banner is being displayed before granting access.Review the MKE configuration to determine if the Standard Mandatory DOD Notice and Consent Banner is configured to be displayed before granting access to platform components. + +Log in to MKE and verify that the Standard Mandatory DOD Notice and Consent Banner is being displayed before granting access. + +If the Standard Mandatory DOD Notice and Consent Banner is not configured or is not displayed before granting access to MKE, this is a finding. \ No newline at end of file diff --git a/stigs.json b/stigs.json index 40e39e052..99f999867 100644 --- a/stigs.json +++ b/stigs.json @@ -4760,18 +4760,26 @@ "url": "https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/scc-5.9_Windows_bundle.zip", "size": "94.37 MB" }, - { - "id": "6eee86e7-bd11-47db-914f-fd244a920bc2", - "name": "z/OS RACF Products - Ver 6, Rel 59", - "url": "https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_zOS_RACF_V6R59_Products.zip", - "size": "8.96 MB", - "version": "V6R59" - }, { "id": "0e45514c-bc35-4bac-ba1f-9c55057853b7", "name": "z/OS SRR Scripts - Ver 6, Rel 59", "url": "https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_zOS_V6R59_SRR.zip", "size": "1.89 MB", "version": "V6R59" + }, + { + "id": "Mirantis_Kubernetes_Engine_STIG", + "name": "Mirantis Kubernetes Engine - Ver 1, Rel 1", + "url": "https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_Mirantis_Kubernetes_Engine_V1R1_STIG.zip", + "size": "1.99 MB", + "version": "V1R1", + "file": "https://raw.githubusercontent.com/mitre/inspec-profile-update-action/main/benchmarks/DISA/U_Mirantis_Kubernetes_Engine_STIG_V1R1_Manual-xccdf.xml" + }, + { + "id": "659e1b89-5268-41bd-8ff7-85d398b3abcb", + "name": "z/OS ACF2 Products - Ver 6, Rel 59", + "url": "https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_zOS_ACF2_V6R59_Products.zip", + "size": "9.7 MB", + "version": "V6R59" } ] \ No newline at end of file