Home Explore Blog CI



docker

5th chunk of `content/manuals/engine/security/_index.md`
54884cc15b41c72fa2757e05eac979d72a9eeb116bbd4d880000000100000daa
Docker Engine can be configured to only run signed images. The Docker Content 
Trust signature verification feature is built directly into the `dockerd` binary.  
This is configured in the Dockerd configuration file. 

To enable this feature, trustpinning can be configured in `daemon.json`, whereby 
only repositories signed with a user-specified root key can be pulled and run.
  
This feature provides more insight to administrators than previously available with
the CLI for enforcing and performing image signature verification. 

For more information on configuring Docker Content Trust Signature Verification, go to 
[Content trust in Docker](trust/_index.md).

## Other kernel security features

Capabilities are just one of the many security features provided by
modern Linux kernels. It is also possible to leverage existing,
well-known systems like TOMOYO, AppArmor, SELinux, GRSEC, etc. with
Docker.

While Docker currently only enables capabilities, it doesn't interfere
with the other systems. This means that there are many different ways to
harden a Docker host. Here are a few examples.

 - You can run a kernel with GRSEC and PAX. This adds many safety
   checks, both at compile-time and run-time; it also defeats many
   exploits, thanks to techniques like address randomization. It doesn't
   require Docker-specific configuration, since those security features
   apply system-wide, independent of containers.
 - If your distribution comes with security model templates for
   Docker containers, you can use them out of the box. For instance, we
   ship a template that works with AppArmor and Red Hat comes with SELinux
   policies for Docker. These templates provide an extra safety net (even
   though it overlaps greatly with capabilities).
 - You can define your own policies using your favorite access control
   mechanism.

Just as you can use third-party tools to augment Docker containers, including
special network topologies or shared filesystems, tools exist to harden Docker
containers without the need to modify Docker itself.

As of Docker 1.10 User Namespaces are supported directly by the docker
daemon. This feature allows for the root user in a container to be mapped
to a non uid-0 user outside the container, which can help to mitigate the
risks of container breakout. This facility is available but not enabled
by default.

Refer to the [daemon command](/reference/cli/dockerd.md#daemon-user-namespace-options)
in the command line reference for more information on this feature.
Additional information on the implementation of User Namespaces in Docker
can be found in
[this blog post](https://integratedcode.us/2015/10/13/user-namespaces-have-arrived-in-docker/).

## Conclusions

Docker containers are, by default, quite secure; especially if you
run your processes as non-privileged users inside the container.

You can add an extra layer of safety by enabling AppArmor, SELinux,
GRSEC, or another appropriate hardening system.

If you think of ways to make docker more secure, we welcome feature requests,
pull requests, or comments on the Docker community forums.

## Related information

* [Use trusted images](trust/_index.md)
* [Seccomp security profiles for Docker](seccomp.md)
* [AppArmor security profiles for Docker](apparmor.md)
* [On the Security of Containers (2014)](https://medium.com/@ewindisch/on-the-security-of-containers-2c60ffe25a9e)
* [Docker swarm mode overlay network security model](/manuals/engine/network/drivers/overlay.md)

Title: Enhancing Docker Security: Kernel Features, User Namespaces, and Best Practices
Summary
Docker can be configured to run only signed images through Docker Content Trust, enhancing security. Docker also supports kernel security features like TOMOYO, AppArmor, and SELinux, which can be used to harden the host independently of containers. User Namespaces, supported since Docker 1.10, map the container's root user to a non-root user outside the container, mitigating breakout risks. Docker containers are secure by default, especially when running processes as non-privileged users, and can be further hardened with AppArmor, SELinux, or other systems. The document concludes with links to related resources for trusted images, Seccomp, AppArmor, and more.