Chapter 7. Container Security Practices

Kernel capabilities can be dropped from the CLI of Docker and in the .json file of Kubernetes. Start with nothing and add what you need — this is the safest method of determining which kernel capabilities you need.

Never have long-running containers running as root, with the exception of systemd. There are a couple of approaches for doing this: if you don’t need systemd, you can use exec to become root and drop your user privileges. Or you can use systemd to launch the application you want inside the container with a unit file, and the unit file can be used to designate the desired services as non-root.

Unless your container needs access to the host’s hardware, you should not use --privileged.

Sticky-bit content (sticky UID content). This is a word-to-the-wise-type note. It is possible to make use of suid content without a privileged container, but it is not easy to create suid content without a privileged container because marking something as suid is a privileged operation.

A tmpfile is a file that gets created in /tmp. This section refers to tmpfile attacks. Containers are susceptible to the same race conditions and attacks that non-container tmpfiles are susceptible to. Make sure that tmpfile content ownership is properly restricted.

Binding the docker service to a TCP port allows non-root users to gain root access on the host. Hence, anyone with access to that port can then run arbitrary code as the root user.

To prevent this type of vulnerability, do not expose docker through a TCP port. Keep the default binding.