V-260930

Discussion

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.

Check Content

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.