Learn Kubernetes: A Deep Dive/

...

/

Protecting Pods

Protecting Pods

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

We'll cover the following...

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.

Press + to interact
apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  securityContext:      <<==== Applies to all containers in this Pod
    runAsUser: 1000     <<==== Non-root user
  containers:
  - name: demo
    image: example.io/simple:1.0

The runAsUser property is one of many settings that fall under the category of PodSecurityContext (spec.securityContext).

It’s possible for two or more Pods to be configured with the same runAsUser UID. When this happens, the containers from both Pods will run with the same security context and potentially have access to the same resources. This might be fine if they are replicas of the same Pod. However, there’s a high chance this will cause problems if they’re not replicas. For example, two different containers with R/W access to the same volume can cause data corruption (both writing to the same ...

Access this course and 1400+ top-rated courses and projects.