Organizations are deploying a growing number of containers in their environments.
In the 2019 iteration of its annual survey, the Cloud Native Computing Foundation (CNCF) found that the percentage of organizations running at least 250 containers had grown by 28% and crossed the 50% threshold for the first time. Simultaneously, in the 2020 edition of the State of Enterprise Open Source report, 56% of surveyed IT leaders told Red Hat that they expected their organizations’ use of containers would increase over the next 12 months.
These findings highlight the need for organizations to manage their growing number of containers. In response, many are turning to container orchestration and management. Kubernetes is one of the most popular examples of these solutions. This open-source platform facilitates both declarative configuration and automation for the purpose of helping organizations manage their containerized workloads and services. StackRox explains that Kubernetes also helps organizations to streamline their container security efforts:
As the de facto standard for container orchestration, Kubernetes plays a pivotal role in ensuring your applications are secure. To effectively secure containerized applications, you must leverage the contextual information from Kubernetes as well as its native policy enforcement capabilities. For example, Kubernetes has several built-in security features that make it easier to operationalize full life cycle container security, including Kubernetes RBAC, Network Policies, and Admission Controllers.
Notwithstanding its appeal, Kubernetes isn’t the only container management tool to which organizations are turning. There’s also Docker Swarm. This blog post will provide a high-level overview of Docker Swarm and how it works. It will then discuss some of its security features that administrators should keep in mind.
What Is Docker Swarm?
According to Docker’s documentation, Docker Swarm is a suite of cluster management and orchestration features that’s available in Docker Engine 1.12. These features rely on “SwarmKit,” a toolkit for orchestrating distributed systems. SwarmKit enables admins to group machines running SwarmKit together into a swarm and to coordinate tasks across the machines.
When a machine joins a swarm, it’s called a node. But not all nodes are created equally. There are two types of node. The first kind of node, known as “manager nodes,” help to maintain the state of the swarm by administering cluster management tasks. These manager nodes make it possible for admins to have worker nodes, or instances of Docker Engine that are responsible for executing containers. (All manager nodes are also worker nodes, by default.)
So, how do manager nodes and worker nodes function together?
It all begins with what’s known as a service, or an abstraction that enables an admin to declare the desired state of a group of tasks as well as how to execute and update them. Manager nodes subsequently accept that definition as the desired state for the service and use tasks to schedule it on nodes within the swarm. Those tasks then run independently of one another within the swarm with the help of the worker nodes.
This type of model comes with several benefits. First, scaling isn’t an issue. The swarm manager adapts by adjusting the number of tasks that are necessary for maintaining the desired state as the organization scales up or down. The manager node also comes equipped with the ability to reconcile drift in the baseline configuration of the cluster state as well as to control the process of incrementally rolling out updates to sets of nodes.
How to Secure Docker Swarm?
There are two key security features available in Docker Swarm. First, Docker comes with a built-in swarm mode Public Key Infrastructure (PKI) system that enables admins to securely deploy a container orchestration system. Docker designates itself as a manager node whenever an admin creates a swarm by running “docker swarm init.” It’s then that the manager node generates a new root Certificate Authority (CA) along with a key pair for encrypting the communications with other nodes that join the swarm using Transport Layer Security. Admins have the option of specifying an externally generated root CA as well as rotating the swarm root CA in the event that a cluster CA key or manager node suffers a compromise.
Second, Docker Swarm encrypts the Raft logs used by the managers on disk in order to shield configuration information and data from attackers. Both the TLS key used to encrypt swarm node communications as well as the key for the Raft logs come loaded in each manager node’s memory. Admins can choose to protect those keys by activating autolock, a feature which requires that managers be manually unlocked with a key encryption key generated by Docker. This feature thereby helps to prevent those encryption keys from falling into the wrong hands.
Security: Just One Area of Consideration for Docker Swarm
Security is just one area of consideration that administrators can use to optimize their Docker Swarm and, by extension, their nodes and containers. For more information on this container orchestration suite, click here.
About the Author
David Bisson is an information security writer and security junkie. He’s a contributing editor to IBM’s Security Intelligence, Tripwire’s The State of Security Blog, and a contributing writer to Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.
Featured image: ©byrdyak
