Title

MKE host network namespace must not be shared. (Cat II impact)

Discussion

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.

Check Content

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.

Fix Text

When 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]

Additional Identifiers

Rule ID: SV-260913r966096_rule

Vulnerability ID: V-260913

Group Title: SRG-APP-000039-CTR-000110

Expert Comments

CCIs tied to check.

Controls tied to check. These are derived from the CCIs shown above.