To enable process namespace sharing, simply set shareProcessNamespace=true
in the Pod definition. The following example shows the effect of two containers sharing a process namespace in a Pod. The contents of the share-process-namespace.yaml configuration file are as follows.
The main container is a service provided by nginx, and the other container is an error checking tool provided by busybox, named “shell”. The CAP_SYS_PTRACE capability has been added to the shell’s container’s securityContext.capabilities to provide process tracking capabilities.
Use the kubectl create
command to create this Pod.
View container in Pod.
Go to the shell’s container environment and use the ps
command to see all the processes of nginx and your own container.
|
|
Because the shell container is CAP_SYS_PTRACE capable, it can also send operating system signals to other processes, such as the SIGHUP signal to process 6 of nginx to restart the nginx program.
The original worker process of nginx (PIDs 35 and 36) is restarted and a new worker process with PIDs 48 and 49 is started.
A Pod environment with two containers sharing a process namespace has the following characteristics.
- The process IDs (PIDs) of each container are mixed in an environment where neither has a startup process with process number PID=1 anymore, and process number 1 is used by the Pod’s Pause container. For some containers that must have process number 1 as the PID of the startup process, it will not be possible to start, such as containers with systemd as the start command.
- Process information is visible across multiple containers. This includes all information in the /proc directory, which may have environment variables containing sensitive information such as passwords, which can only be controlled by UNIX file permissions, and requires setting the running user or group within a container.
- A container’s filesystem exists in the /proc/$pid/root directory, so different containers can also access the contents of other containers’ filesystems, which is useful for debug checking, but also means that there is no container-level security isolation, and access control can only be done through UNIX file permissions, which requires setting the running user or group within the container.
For example, the contents of the nginx container’s configuration file can be viewed from within the shell container.
|
|