Docker Swarm is a container orchestration tool that manages a cluster of Docker Engines, which in turn runs a group of Docker containers. Because containers are lightweight, they give you the flexibility to create and manage numerous instances on a single node. Typically, containerized apps span multiple nodes, and hundreds, if not thousands of containers. Needless to say, managing such a large number of instances—creating them, configuring them, and ensuring they’re secure enough to be shipped into production—is no mean feat. This is why you need a container orchestrator like Kubernetes, or Docker’s very own Swarm.
Docker Swarm, launched mid-last year, has kicked the container revolution into high gear. Joining the orchestration party after Kubernetes, Docker has been making up for the lost time in bolstering Swarm with frequent updates. In this post, we look at both the underlying security features of Docker Swarm, and recent updates that make it a more production-friendly tool for running containerized applications.
OS-level security
Docker Engine comes with core Linux kernel security features as follows:
-
Namespaces: They isolate containers and restrict containers from seeing processes running in neighboring containers.
-
Cgroups: They restrict the amount of system resources any single container can consume.
-
Apparmor: A collection of security policies that are applied to containers that protect the OS and application from threats.
-
Seccomp: This profile restricts the actions a container can take and is applied to every newly created container.
These are the core security features of the Docker platform, and they operate at a lower level than Swarm. However, since they play a critical role in securing every single container that Swarm manages, it’s imperative to be aware of them.
Overlay network security
Swarm uses an overlay network to let containers talk to each other within Docker Swarm. Each node encrypts data before it is shared with neighboring nodes using a gossip protocol. The encryption keys for the shared data are stored in master nodes within Swarm, which means that only containers within that swarm can access the keys. By default, data is not encrypted in transit, and is something that needs to be configured. This ensures data stays secure as it is transferred within Swarm.
Container image security
The images you download from Docker Hub or a similar container registry are critical to the security of your Docker system. Fortunately, Docker provides many tools to ensure the images downloaded and used in your system are trusted. Docker Content Trust checks the source of any image downloaded, and only allows those images with a signature to be pulled from the registry. If you use a third-party registry like Quay, these too have built-in image scanning features. A container registry is like a bridge between your stack and the external world, and it’s important to secure this bridge using a feature like Content Trust.
Secrets management
As services and containers talk to each other, they’re bound to store sensitive information like passwords, tokens, and keys. This data needs to be handled safely for your system to be secure. This is where secrets management comes in. All secrets in Swarm are encrypted and stored as Raft data. Once encrypted, you can grant each service access to the secrets, or revoke access at any time. Swarm’s secret management is able to secure sensitive information in transit and at rest. And thanks to automatic data replication, your secrets enjoy the same high availability as the rest of your data in Swarm.
Public Key Interface (PKI)
Swarm uses a protocol called PKI to enable nodes to communicate with each other securely. According to this model, the master node in a swarm generates a Certificate Authority (CA), and a pair of tokens—a worker token and manager token. Each time a new node joins the Swarm, the CA and tokens are used to start and authenticate communication between the master node and new nodes. If the master node is compromised or needs to be replaced for some reason, the CA can be passed on to another master node easily. This switch happens seamlessly without disruption to regular communication between the nodes.
Threat detection at runtime
All the above points are efforts Docker takes to secure Swarm. While these efforts are great for securing the platform, what’s missing for Swarm to be truly production-ready is a monitoring tool that can scan the system end-to-end during runtime, and detect and respond to threats. With all the different layers and sub-layers in a container stack—runtime, registry, orchestration, and the layers within them—there are too many moving parts. This makes Swarm security a moving target. Despite assigning the right policies, setting up scanning tools, and encrypting secret data, there is bound to be some part of the system that gets overlooked, or that becomes vulnerable when something changes. During these times, it’s important to have a monitoring tool that deeply understands how the different parts of the Docker stack work together, and where there are most likely to be security loopholes.
Twistlock is one such tool that specializes in threat detection for containers during runtime. It takes into account every layer of the stack, and has the ability to scan all the data within the system without draining the system itself. Twistlock uses machine learning to predict threats in advance, and can initiate automatic fixes to common issues. In this way, it secures Docker Swarm over and above the default security features provided by Docker.
As you scale your usage of containers, security is a top priority. You need to secure every part of the Docker stack, including the kernel, registry, runtime, orchestration, networking, and storage. Docker has unique solutions designed for each of these parts. But apart from Docker’s default security solutions, you need a tool that performs threat detection during runtime. Twistlock provides this level of security, and lets you confidently take your containers to production using Docker Swarm.
