Chapter 7. Container Security Practices
This chapter describes measures that you can take to protect the security of your containers.
7.1. Dropping Kernel Capabilities
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.
7.2. Dropping Root
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.
7.3. Exercise care in using the --privileged flag.
Unless your container needs access to the host’s hardware, you should not use --privileged.
7.4. suid Content
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.
7.5. tmpfile
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.
7.6. Do not bind the docker service to a TCP port
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.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.