Container Security

Chapter 9. Breaking Container Isolation

In Chapter 4, you saw how a container is constructed and how it gets a limited view of the machine it is running on. In this chapter, you’ll see how easy it is to configure containers to run in such a way that this isolation is effectively broken.

Sometimes you will want to do this deliberately, to achieve something specific such as off-loading networking functionality to a sidecar container. In other circumstances, the ideas discussed in this chapter could be seriously compromising the security of your applications!

To start with, let’s talk about what is arguably the most insecure-by-default behavior in the container world: running as root.

Containers Run as Root by Default

Unless your container image specifies a non-root user or you specify a non-default user when you run a container, by default the container will run as root. And it’s easy to confirm that (unless you are set up with user namespaces) this is not just root inside the container but also root on the host machine.

Note

This example assumes that you are using the docker command provided by Docker. If you have installed podman, you may have followed the advice to alias docker so that it actually runs podman instead. The behavior of podman is quite different with regard to root users. I’ll come to the differences later in this chapter, but for now be aware that the following example won’t work with podman.

As a non-root user, run a shell inside an Alpine container using