The first important step to guarantee security is deciding on how to use CA. When you form a cluster with the first node, it will automatically create a self-signed CA for the whole cluster. After spinning up, it creates CA, signs the certificate itself, adds the certificate for the manager, which is itself, and becomes the ready-to-operate 1-node cluster. When a new node joins, it gets the certificate by providing the correct token. Every node has its own identity which is cryptographically signed. Also, the system has a certificate for each rule, worker, or manager. The role is inside the identity information to tell who a node is. In the case that a manager leaks the root CA, the whole cluster is compromised. Docker Swarm mode supports external CAs to maintain the manager's identity. The manager can simply forward the CSR to the external CA so it does not need to maintain its own CA. Please note that the only protocol supported at this moment is`cfssl`. The following command is to init the cluster with the external CA.

$ docker swarm init --external-ca   
    protocol=cfssl,url=https://ca.example.com

Every single endpoint communication on the network control plane must have a mutual TLS and is encrypted and authorized by default. This means that a worker cannot fake to be a manager and no external attacker can connect to an endpoint and successfully complete the TLS handshake because the attacker does not have the keys to mutually authenticate itself. This means that each node must provide a valid CA-signed certificate, which has the OU field that matches each rule of the cluster. If a worker connects to the manager endpoint, it will be denied access.

The Certificate rotation is done automatically by Swarm. You can have the certificate rotation as short as one hour in SwarmKit and also Docker Swarm mode. The following is the command to adjust the certificate expiry time.

$ docker swarm update --cert-expiry 1h

Each token, used by nodes to join the cluster, has the following four components:

The following is an example of token:

SWMTKN-1-11lo1xx5bau6nmv5jox26rc5mr7l1mj5wi7b84w27v774frtko-e82x3ti068m9eec9w7q2zp9fe

To access the cluster, it is necessary to send a token as proof. It is like the cluster password.

The good news is that in case of token compromising, the token can be simply rotated using one of the following commands.

$ docker swarm join-token --rotate worker
$ docker swarm join-token --rotate manager

Another good practice is provisioning all manager nodes with Docker Machine to set up an extra layer of TLS, automatically, so that each manager can be accessed by remote Docker clients in a secure manner. This can simply be done using the following command, similar to how we did in the previous chapter:

    $ docker-machine create 
      --driver generic 
      --generic-ip-address=<IP> 
    mg0

Form a cluster on a private network

If forming a hybrid cluster is not a requirement, one of the best practices is that we should form a cluster with all the nodes being on a local private network. With this, the data of overlay network will not need to be encrypted and the performance of cluster will be fast.

When forming this kind of cluster, the Routing Mesh allows us to expose any worker, not necessarily a manager, to the public-network interface. The following figure shows the cluster configuration. You can see that with this configuration and a Docker service published port 80 on the Ingress network. The routing mesh forms a star-like mesh but we simplified it and showed only one-side from the Big W node connecting IPVS load-balancing to others. The Big W node has two network interfaces. Its public interface allows the node to act as a front-end node of the whole cluster. With this architecture, we can achieve a certain level of security by not exposing any manager node to the public network.