Docker Security

Introduction

Security is a major challenge when running applications in a virtual environment. Therefore, securing docker containers is vital. It requires securing everywhere, from the host to the network.

Docker containers lay out a more safe environment for your systems than traditional virtual machines. They provide a way to split up applications into smaller components.

Docker security is a complex topic, but there are four main areas to keep in mind: the security of the Linux kernel itself, the attack surface of the Docker daemon, container configuration security, and the hardening features of the Linux kernel.

In this article, we will discuss docker security.

Network Drivers

Docker supports different types of network drivers, each fit for certain use cases. Docker handles communication between containers by creating a default bridge network, so you often don't have to deal with networking and can instead focus on creating and running containers. This default bridge network works in most cases, but it's not the only option you have.

Docker allows you to create three different types of network drivers out-of-the-box: bridge, host, and none.

Network Driver Summary

Docker supports multiple network drivers for different use cases, allowing users to select the best driver for their needs.

By default, Docker creates a bridge network to manage communication between containers, but it also supports host and none network drivers. Each network driver is suitable for specific use cases.

Advantages of Docker Security

Having better docker security would mean that your applications running inside the docker engine, as well as the data that those applications deal with, would be safe.

How Does Docker Security Work?

Securing Docker means securing the operating system which is running the docker engine. To do this, you need to create a system with tight access controls and detailed auditing.

Operating System

Container security must be taken care of at the infrastructure level - if this layer is strong, then the container will be strong. If attackers were to compromise the host operating system (OS), they could potentially compromise all processes on that OS, including the container runtime. To have the most secure infrastructure, you should design the base OS only to run the container engine - this way, there are no other processes that could be compromised.

Updates

It's important to standardize best practices and tooling for package and component validation once you've chosen your operating system. This will help ensure compatibility and avoid any potential issues down the road.

Auditing & Access control

You should always audit and log all authentication directly to the OS. This way, you can ensure that only the appropriate users have access and that keys are used for remote logins. Also, be sure to implement firewalls and only allow access from trusted networks.

Securing Docker Images

Incorporating the mechanisms to conduct static analysis on your container images provides insight into any potentially vulnerable OS and non-OS packages. You can use an automated tool like Anchore to control whether you would like to promote non-compliant images into trusted registries through policy checks within a secure container build pipeline.

Container Network Model

Understanding the network model will help understand the docker networking model clearly. Let's discuss the components of the container network model in detail -

Network Sandbox

When a user requests to generate an endpoint on the network, a network sandbox is created. This isolated sandbox contains the network configuration for containers.

Endpoints

An endpoint establishes the connectivity for container services within a network with other services.

Docker Engine

It is the engine running on your host machine to build and run containers using docker components and services whose task is to manage the network with multiple drivers.

The above are the important components of the 'Container Network Model' - so be sure to understand them clearly.

How Do Containers Communicate with Each Other?

For containers to communicate with each other, they must be on the same network. By default, Docker creates a virtual network called the bridge and connects your containers to it. In the network, each container is assigned an IP address, which it can use to communicate with other containers.

How Do Containers Communicate with the Outside World?

For containers to communicate with outside applications, their requests are intercepted by the docker network running on the host inside the docker engine. This network passes the request to a network address translator, NAT, on the host that replaces the source address with the IP of the host. The host then sends the packet to the internet with its IP address as the origin.

Network Drivers

Different types of networks are supported by Docker, each being suitable for specific use cases. Docker allows you to create three different types of network drivers out-of-the-box: bridge, host, and none.

The Bridge Driver

It's a docker networking driver that is perfect for when you need your containers to be able to connect and communicate with each other while still running in isolation. The bridge network lets containers running in the same network communicate with each other, and Docker uses iptables to stop any access from outside of the bridge.

Overlay Networks

It's a docker networking driver that is for multi-host network communication, making it perfect for use with Docker Swarm or Kubernetes. With this driver, containers across different hosts can communicate with each other without needing to worry about the initial setup.

Macvlan Networks

It's a docker networking driver that lets us connect Docker containers directly to the physical host network. It's the best option for legacy applications that need to be containerized and run on the cloud because they may need to be attached to a physical host network for various reasons like performance.

Basic Docker Security Practices

• Don't expose the Docker daemon socket.
• Never run containers in a privileged mode.
• Omit "--cgroup-parent "flag on Docker cgroups to prevent the risk of a DoS attack
• Use a separate User ID namespace
• Never include sensitive information in plaintext for env vars