The next few sections will look at a few of the technologies that help reduce the risk of elevation of privilege attacks against Pods and containers. We’ll look at the following:

• Preventing processes from running as root
• Dropping capabilities
• Filtering syscalls
• Preventing privilege escalation

As we proceed through the following sections, it’s important to remember that a Pod is just an execution environment for one or more containers – application code runs in containers, which, in turn, run inside of Pods. Some of the terminology used will refer to Pods and containers, interchangeably, but usually, we will mean container.

Do not run processes as root

The root user is the most powerful user on a Linux system and is always User ID 0 (UID 0). Therefore, running application processes as root is almost always a bad idea as it grants the application process full access to the container. This is made even worse by the fact that the root user of the container often has unrestricted root access on the node as well. If that doesn’t make you afraid, it should!

Fortunately, Kubernetes lets you force container processes to run as unprivileged non-root users.

The following Pod manifest configures all containers that are part of this Pod to run processes as UID 1000. If the Pod has multiple containers, all processes in all containers will run as UID 1000.s