Security in Docker

According to Docker documentation, there are 4 areas we should focus on in the context of Docker security:

• Security of the kernel (features like namespaces and cgroups):

  • Containers should be isolated from each other and from the host.
  • Namespaces provide isolation of processes running in one container from processes running in other containers and the host system.
  • Cgroups limit container access to resources, which play a role in preventing containers from exhausting resources, which can be used in DDoS attacks.

• Docker daemon (and possible attacks on it):

  • The Docker daemon requires root user access (unless run in Rootless mode), which has strong security implications.
  • A potential attacker can start a container which will modify the host filesystem.
  • When using the API to interact with the Docker daemon, we need to be aware of these risks.

• Container configuration (loopholes caused by misconfigurations or default behaviors).

• Interaction of the kernel with containers.

Best practises

In order to maintain a stable and secure environment, it is crucial to understand and apply the best practices and security patterns during development, deployment, and operation of containers.

Image Security Best Practices

• All changes in images should be reflected in the version control system.
• We should only use images from trusted sources. Docker Engine has an option to allow running only signed images. It can be found in the daemon.json file. We should also always sign our images using DCT (Docker Content Trust) to make sure that no one modified our images without our knowledge.
• Any change in a container should come by deploying a new container from an updated image.
• Each image consists of many dependencies which should be regularly scanned to catch potential risks as fast as possible. Tools that make this process easier include Clair or Anchore.
• When building our own images, we should base them on secure base images and make sure to keep them up to date with the latest security patches. These secure base images contain only essential components, minimizing the attack surface. An example of such an image is the Alpine Linux distribution:
  • Official images can be found here: https://hub.docker.com/explore/

Runtime Security Best Practices

• The Docker daemon has extensive privileges, and only trusted users should have access to it.
• The rule of least privilege also applies to containers, which should be run with minimal permissions required by the application.
  • Use a non-root user when possible.
  • Strip away unnecessary privileges and permissions.
• Access to containers should be managed by RBAC (Role-Based Access Control).
• Data at rest and in transit should be encrypted to provide security in case of a data breach.
• To prevent attackers from modifying critical data in containers, we can set the entire filesystem as read-only using the --read-only flag when starting containers.
• It is crucial to maintain logs from container activity to be able to verify what really happened in case of an incident and how to prevent them in the future.

These are only basic rules that we should follow to provide security in Docker, and there are many different ways to harden Docker hosts and containers.