| Finding ID |
Severity |
Title |
Description |
|
V-260908
|
High |
FIPS mode must be enabled. |
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... |
|
V-260907
|
High |
Only required ports must be open on containers in MKE. |
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... |
|
V-260906
|
High |
Least privilege access and need to know must be required to access MKE runtime and instantiate container images. |
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... |
|
V-260945
|
Medium |
MKE must contain the latest updates. |
MKE must stay up to date with the latest patches, service packs, and hot fixes. Not updating MKE will expose the organization to vulnerabilities. |
|
V-260944
|
Medium |
Older Universal Control Plane (MKE) and Docker Trusted Registry (DTR) images must be removed from all cluster nodes upon upgrading. |
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... |
|
V-260943
|
Medium |
Vulnerability scanning must be enabled for all repositories in MSR. |
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. |
|
V-260942
|
Medium |
MKE must only run signed images. |
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... |
|
V-260941
|
Medium |
The network ports on all running containers must be limited to required ports. |
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. |
|
V-260940
|
Medium |
Use of privileged Linux containers must be limited to system containers. |
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... |
|
V-260939
|
Medium |
MKE users must not have permissions to create containers or pods that share the host user namespace. |
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... |
|
V-260938
|
Medium |
Docker CLI commands must be run with an MKE client trust bundle and without unnecessary permissions. |
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... |
|
V-260937
|
Medium |
The default seccomp profile must not be disabled. |
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... |
|
V-260936
|
Medium |
All containers must be restricted to mounting the root filesystem as read only. |
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... |
|
V-260935
|
Medium |
Host IPC namespace must not be shared. |
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... |
|
V-260934
|
Medium |
All containers must be restricted from acquiring additional privileges. |
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... |
|
V-260933
|
Medium |
MKE must enable kernel protection. |
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... |
|
V-260932
|
Medium |
MKE must preserve any information necessary to determine the cause of the disruption or failure. |
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... |
|
V-260931
|
Medium |
IPSec network encryption must be configured. |
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... |
|
V-260930
|
Medium |
MKE must not permit users to create pods that share host process namespace. |
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... |
|
V-260929
|
Medium |
Containers must not map to privileged ports. |
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... |
|
V-260928
|
Medium |
The "Create repository on push" option in MSR must be disabled. |
Allowing repositories to be created on a push can override essential settings and must not be allowed. |
|
V-260927
|
Medium |
MKE's self-signed certificates must be replaced with DOD trusted, signed certificates. |
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... |
|
V-260926
|
Medium |
MKE must use a non-AUFS storage driver. |
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... |
|
V-260925
|
Medium |
CPU priority must be set appropriately on all containers. |
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... |
|
V-260924
|
Medium |
Incoming container traffic must be bound to a specific host interface. |
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... |
|
V-260923
|
Medium |
Linux Kernel capabilities must be restricted within containers. |
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.... |
|
V-260922
|
Medium |
The Docker socket must not be mounted inside any containers. |
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... |
|
V-260921
|
Medium |
If MKE is deployed on a Red Hat or CentOS system, SELinux security must be enabled. |
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... |
|
V-260920
|
Medium |
For MKE's deployed on an Ubuntu host operating system, the AppArmor profile must be enabled. |
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... |
|
V-260919
|
Medium |
MSR telemetry must be disabled. |
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. |
|
V-260918
|
Medium |
MKE telemetry must be disabled. |
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. |
|
V-260917
|
Medium |
Allowing users and administrators to schedule containers on all nodes must be disabled. |
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. |
|
V-260916
|
Medium |
MSR's self-signed certificates must be replaced with DOD trusted, signed certificates. |
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... |
|
V-260915
|
Medium |
MKE must be configured to send audit data to a centralized log server. |
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. |
|
V-260914
|
Medium |
Audit logging must be enabled on MKE. |
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... |
|
V-260913
|
Medium |
MKE host network namespace must not be shared. |
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... |
|
V-260912
|
Medium |
MKE must have Grants created to control authorization to cluster resources. |
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. |
|
V-260911
|
Medium |
Swarm Secrets or Kubernetes Secrets must be used. |
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... |
|
V-260910
|
Medium |
SSH must not run within Linux containers. |
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.... |
|
V-260909
|
Medium |
MKE must be configured to integrate with an Enterprise Identity Provider. |
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. |
|
V-260905
|
Medium |
User-managed resources must be created in dedicated namespaces. |
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... |
|
V-260904
|
Medium |
In an MSR organization, user permissions and repositories must be configured. |
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. |
|
V-260903
|
Medium |
The Lifetime Minutes and Renewal Threshold Minutes Login Session Controls on MKE must be set. |
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... |
|
V-260946
|
Low |
MKE must display the Standard Mandatory DOD Notice and Consent Banner before granting access to platform components. |
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... |