Protecting Pods

Learn how to reduce privilege escalation risks by using non-root users, dropping capabilities, filtering syscalls, and preventing privilege escalation.

In this lesson, we will look at a few 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 these sections, it’s important to remember that a Pod is just an execution environment for one or more containers. 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). This means 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 a container sometimes has unrestricted root access to the host system as well. If that doesn’t make us afraid, nothing will!

Fortunately, Kubernetes allows us to 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 container processes will run as UID 1000.

Get hands-on with 1400+ tech skills courses.