Shulou(Shulou.com)06/02 Report--

The Docker platform and containers have become the standard for packaging, deploying, and managing applications. In order to coordinate containers across nodes within a cluster, there must be a key capability: a container choreographer.

Container orchestrator

The choreographer plays an important role in key clustering and planned tasks, such as:

Manage container planning and resource allocation.

Support service discovery and seamless application deployment.

Allocate the resources necessary for the application to run.

Unfortunately, in this environment, the distributed nature of the choreographer and the transient nature of resources make it a challenging task to ensure the security of the choreographer. In this article, we will discuss the important details of this aspect that are not taken into account in the container choreographer security model, and how the built-in orchestration performance and Swarm pattern can be used in Docker Enterprise Edition to overcome these problems.

Inducement and threat model

One of the main goals of Docker Enterprise Edition using the swarm pattern is to provide a choreographer with built-in security features. To achieve this goal, we deployed the first container choreographer that we thought was designed with the principle of minimum permissions.

In computer science, the minimum privilege principle required by a distributed system is that each participant in the system can only access the information and resources it needs for legitimate purposes. Not more, not less.

"A process must have access only to the information and resources it needs for its legitimate purposes."

Principle of minimum authority

The role assigned by each node in an Docker Enterprise Edition cluster: neither manager nor worker. These roles define a coarse-grained permission level for the node: management and task execution, respectively. However, regardless of its role, encryption is used to ensure that a node has only the information and resources needed to perform its tasks. As a result, it becomes easier to secure the cluster, even preventing most experienced attacker patterns: attackers take control of the underlying communication network, or even capture cluster nodes.

Kernel default security

This is an old security maximization state: if it is not the default, no one uses it. The Docker Swarm pattern incorporates the concept of default security at its core and uses this mechanism to address three difficult and important parts of the choreographer life cycle:

1. Trusted boot and node introduction.

two。 Node identity publishing and management.

3. Storage and dissemination of authenticated, authorized and encrypted information.

Let's take a look at these three parts separately:

Trusted Boot and Node introduction

The first step in ensuring cluster security is, among other things, strict control of membership and identity. Administrators cannot rely on the identity of their nodes and enforce absolute load isolation between nodes. This means that unauthorized nodes are not allowed to join the cluster, and nodes that are already part of the cluster cannot change their identity and suddenly pretend to be another node.

To address this situation, a robust and immutable identity is maintained through the nodes managed by the Docker Enterprise Swarm pattern. The desired feature is to ensure encryption by using two key building blocks:

1. Use a secure join token (Secure join token) for cluster members.

two。 A certificate with an embedded unique identity issued from a centralized certification body.

Join Swarm

To join the Swarm, the node needs a copy of the secure join token. The token for each operational role in the cluster is unique-there are now two types of nodes: workers and managers. Because of this distinction, nodes with a worker token will not be allowed to join the cluster in the role of manager. The only way to get this special token is to request one from the cluster manager through swarm's management API.

Tokens are secure and randomly generated, and it has a special syntax that makes token leaks easier to detect: a special prefix that can be easily monitored in your log and repository. Fortunately, tokens can be easily updated even if a leak is found, and it is recommended that you update them frequently-especially if your cluster does not expand for a while.

Docker Swarm

Guide trust

As part of its identity creation, a new node will request any network manager to publish a new identity. However, in our threat model below, all communications can be intercepted by a third party. The problem with this request is: how does a node know that the other person it is talking to is a legitimate manager?

Docker Security

Fortunately, Docker has a built-in mechanism to avoid this. This join token is used by the host to join the Swarm and contains a hash string of the root CA certificate. Therefore, the host can use an one-way TLS and use this hash string to verify that it joined the correct Swarm: if the certificate held by the administrator is not signed by the correct CA hash string, the node knows that it cannot be trusted.

Node identity publishing and management

In an Swarm, the identity is embedded in an x509 certificate held separately by each node. In a manifestation of the least privilege principle, the private key of the certificate is absolutely limited to the original location of the host. In particular, the manager cannot access any private key other than its own.

Identity publishing

To receive their certificates without sharing their private keys, the new host starts by issuing a certificate signing request (CSR), which is converted to a certificate after the administrator receives the certificate signing request. This certificate becomes the identity of the new host, making the node a fully qualified member of Swarm!

When used with a secure boot mechanism, the mechanism for issuing identities to join nodes is secure by default: all communication parts are authenticated and authorized, and non-sensitive information is never exchanged in clear text.

Identity extension

Still, safely adding nodes to a Swarm is only part of the story. To reduce the impact of certificate disclosure or theft, and to remove the complexity of managing CRL lists, the Swarm pattern uses certificates with a shorter lifetime for identity identification. These certificates expire by default in three months, but they can also be configured to expire immediately in an hour!

Docker secrets

A short certificate expiration time means that certificate updates cannot be handled manually, so a PKI system is usually used. For Swarm, all certificates are automatically updated in an uninterrupted manner. The process is simple: using a mutually authenticated TLS connection to prove the owner of a particular identity, a Swarm node periodically generates a new public / private key pair and signs it with the associated CSR, creating a complete new certificate that maintains the same identity.

Storage and dissemination of authenticated, authorized, and encrypted information.

In a normal Swarm operation, information about the task is sent to the worker (worker) node that is running. This contains not only information about the container that will be run by a node; it also contains all the information about the resources necessary for that container to run, including sensitive confidential information, such as private keys, passwords, and API tokens.

Transmission security

In fact, each node participating in Swarm has a unique certificate in X509 format, so there is no problem with the security of communication between nodes: nodes use their own certificates to authenticate each other with another connecting party, inherit confidentiality, authenticity, and TLS integrity.

Swarm Mode

An interesting detail about the Swarm pattern is that it essentially uses a push mode: only managers are allowed to send messages to workers (workers)-significantly reducing the attack surface of manager nodes exposed to low-privileged worker nodes.

Strictly isolate the load into the security zone

One of the responsibilities of the manager node is to decide what tasks are sent to each worker (worker) node. The manager node uses a variety of strategies to make this decision; according to the characteristics of each node and each load, load is arranged across the Swarm.

In Docker Enterprise Edition, which uses the Swarm pattern, the manager node affects these scheduling decisions by using security labels attached to each individual node identity. These tags allow managers to connect node groups to different security zones to limit exposure to sensitive loads and to make related confidential information more secure.

Docker Swarm Security

Secure distribution of secrets

In addition to speeding up the identity publishing process, the manager node has the task of storing and distributing any resources needed by the worker node. Confidential information is handled like any other type of resource and is pushed from the manager to the worker node based on a secure mTLS connection.

Docker Secrets

On the host, Docker Enterprise Edition ensures that secrets are provided only to the containers they specify. Other containers on the same host cannot access them. Docker exposes secrets to a container as a temporary file system, ensuring that secrets are always kept in memory and never written to disk. This approach is safer than other competing alternatives, such as storing them in environment variables. Once this task is completed, the secret will disappear forever.

Store secrets

Secrets on the manager's mainframe are always kept encrypted. By default, the keys that encrypt these secrets (known as data encryption keys, DEK) are stored on the hard disk in clear text. This makes it easy for those with low security requirements to use the Docker Swarm mode.

However, if you are running a production cluster, we recommend that you enable automatic locking mode. When automatic locking mode is enabled, a newly updated DEK is encrypted by the key (KEK) of a separate encryption key. This key is never stored in the cluster; it is the manager's responsibility to store it in a secure and reliable place and to provide it when the cluster starts. This is called "unlocking" Swarm.

According to the Raft fault tolerance consistency algorithm, the Swarm mode supports multiple managers. In this scenario, the security of secret storage is seamlessly extended. Each manager host has a unique disk encryption key in addition to the shared key. Fortunately, Raft logs are also encrypted on disk and, in auto-lock mode, are also inaccessible without KEK.

What happens when a node is captured?

Docker Secrets

In the traditional choreographer, retrieving a captured host is a slow and complex process. Using Swarm mode, restoring it is as easy as running a rm command for a Docker node. This removes an affected node from the cluster, while Docker handles the rest, that is, rebalancing the load and ensuring that other hosts already know and do not communicate with the affected node.

As we have seen, thanks to the least privileged choreographer, even if the attacker continues to be active on the host, they will be cut off from the rest of the network. The certificate of the host-its identity-is blacklisted, so managers cannot effectively access it.

Conclusion

Using the Docker Enterprise Edition of the Swarm pattern, all key areas of the choreographer are secured by default:

Join the cluster. Prevent malicious nodes from joining the cluster.

Group hosts into security zones. Prevent the horizontal movement of the attacker.

Schedule a mission. Tasks will only be delegated to allowed nodes.

Allocate resources. Malicious nodes cannot "steal" other loads or resources.

Store secrets. It is never saved in plain text and never written to the disk of the worker node.

Communication with worker nodes. Use mutually authenticated TLS encryption.

Because of the continuous improvement of the Swarm model, the Docker team is working to further the principle of minimum access. One of the tasks we are dealing with is: if a manager is captured, how to ensure the security of the remaining nodes? A roadmap is already in place, and some of these features are already available, such as the whitelist feature, which allows only specific Docker images to prevent managers from running loads at will. This is achieved through Docker trusted content.

Via: https://blog.docker.com/2017/10/least-privilege-container-orchestration/

Author: Diogo M ó nica translator: qhwdw proofread: wxy

This article was originally compiled by LCTT and honored by Linux China.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.