Docker containers run with the following capabilities by default:
|Allow a process to change it’s own capabilities set (within the set it is already allowed). Should not be dangerous in practice.
|Allows creation of special devices. Almost all containers will receive the devices they need automatically, so this is almost never needed.
|Allow the container to write records to the underlying kernel auditing log. This is generally used for things like ssh login. It is a better practice to keep all container logs within the container and drain them, rather than allow the container to write to the host log files.
|Allow the container process to change file permissions. This should generally never be needed in production.
|Allows RAW and PACKET sockets, which can be used to spy on networks or create nasty packets. Some applications may need this, but most won’t.
|Allows the root user to bypass normal file permission checks. No container should ever need this.
|Bypass permission checks on operations that normally require the UID of the process to match the UID of the file.
|Don’t clear set-user-ID and set-group-ID permission bits when a file is modified. This should only be needed by installations, so generally not in production. Allowing this can let a user modify privileged programs.
|Allow the root user to send kill signals to non-root processes. Not generally needed if keeping one container per process, but not too dangerous in general.
|Allows running of setuid binaries, which allows a process to change it’s effective user id. This is required for some processes that require privileged ports (less than 1024) and by some processes like Apache to start. It should only be given to containers that need it.
|Just like setuid above, but for group ids.
|Bind to ports less than 1024. Enable this if your container runs a service that listens in the this port range only.
|Allows use of the chroot command. Enable only if your process actively uses chroot to change the root directory.
|Allows the container to set file capabilities. Sometimes this is needed during a software install, but generally should not be needed by a running container in production.
It’s best to drop all of these and only selectively add the specific capabilities needed. This takes a little more management overhead, because you may have to work with the application team to determine what is really needed.
# docker run --cap-drop=all my_container
More information here