Kubernetes Security

Chapter 6. Running Containers Securely

Now that you know how to build container images in a secure manner from Chapter 5, we move on to the topic of running those images as containers in Kubernetes. In order to run containers securely in Kubernetes, we aim to do the following:

• Use least privilege to carry out the task at hand.

• Do only the minimal host mounts necessary.

• Limit communication between applications, and to and from the outside world, to a defined and deterministic set of connections.

Before we discuss the security boundaries in Kubernetes and the features that you have at your disposal to enforce policies, let’s have a quick look at two topics essential for you to appreciate the rest of the chapter: why you should not run containers as root (unless you have to) and how the API server deals with enforcing policies.

Say No to Root

As “Mr. SELinux” Dan Walsh pointed out in “Just Say No to Root (in Containers),” there’s little need to run containers as root. Some exceptions are as follows:

• Your container needs to modify the host system; for example, modifying the kernel’s configuration.

• The container needs to bind to privileged ports on the node (below 1024—for example, nginx serving on port 80). In practice, this can be by-and-large avoided through port mappings and the service abstraction in Kubernetes.

• Installing software into a container at runtime: traditional package management systems might require root to function or store files in a certain location ...