CIS Docker Benchmark v1.7.0

7.1 Ensure that the minimum number of manager nodes have been created in a swarm (Manual)
Profile Applicability:
Level 1 - Docker Swarm
Description:
You should ensure that the minimum number of required manager nodes is created in a swarm.
Rationale:
Manager nodes within a swarm have control over the swarm and can change its configuration, including modifying security parameters. Having excessive manager nodes could render the swarm more susceptible to compromise. If fault tolerance is not required in the manager nodes, a single node should be elected as a manger. If fault tolerance is required then the smallest odd number to achieve the appropriate level of tolerance should be configured. This should always be an odd number in order to ensure that a quorum is reached.
Impact:
None
Audit:
Run docker info and verify the number of managers. 

docker info --format '{{ .Swarm.Managers }}' 

Alternatively run the below command. 

docker node ls | grep 'Leader' 

Remediation: 
If an excessive number of managers is configured, the excess nodes can be demoted to workers using the following command: 

docker node demote <ID> 

Where  is the node ID value of the manager to be demoted.
Default Value:
Only a single manager is required to start a given cluster. 

7.2 Ensure that swarm services are bound to a specific host interface (Manual)
Profile Applicability:
Level 1 - Docker Swarm
Description:
By default, Docker swarm services will listen on all interfaces on the host. This may not be necessary for the operation of the swarm where the host has multiple network interfaces.
Rationale:
When a swarm is initialized the default value for the --listen-addr flag is 0.0.0.0:2377 which means that swarm services will listen on all interfaces on the host. If a host has multiple network interfaces this may be undesirable as it could expose swarm services to networks which are not involved with the operation of the swarm.
By passing a specific IP address to the --listen-addr, a specific network interface can be specified, limiting this exposure.
Impact:
None
Audit:
You should check the network listener on port 2377 (the default for docker swarm) and 7946 (container network discovery), and confirm that it is only listening on specific interfaces. 
For example, in this could be done using the following command: 

ss -lp | grep -iE ':2377|:7946' 

Remediation:
Resolving this issues requires re-initialization of the swarm, specifying a specific interface for the --listen-addr parameter.
Default Value:
By default, Docker swarm services listen on all available host interfaces.

7.3 Ensure that all Docker swarm overlay networks are encrypted (Manual)
Profile Applicability:
Level 1 - Docker Swarm
Description:
Ensure that all Docker swarm overlay networks are encrypted.
Rationale:
By default, data exchanged between containers on nodes on the overlay network is not encrypted. This could potentially expose traffic between containers.
Impact:
None
Audit:
You should run the command below to ensure that each overlay network has been encrypted. 

docker network ls --filter driver=overlay --quiet | xargs docker network inspect --format '{{.Name}} {{ .Options }}' 

Remediation:
You should create overlay networks the with --opt encrypted flag.
Default Value:
By default, data exchanged in overlay networks in Docker swarm mode is not encrypted.

7.4 Ensure that Docker's secret management commands are used for managing secrets in a swarm cluster (Manual)
Profile Applicability:
Level 1 - Docker Swarm
Description:
You should use Docker's in-built secret management command for control of secrets.
Rationale:
Docker has various commands for managing secrets in a swarm cluster.
Impact:
None
Audit:
On a swarm manager node, you should run the command below and ensure docker secret management is used in your environment where this is in line with your IT security policy. 

docker secret ls 

Remediation:
You should follow the docker secret documentation and use it to manage secrets effectively.
Default Value:
Not Applicable

7.5 Ensure that swarm manager is run in auto-lock mode (Manual)
Profile Applicability:
Level 1 - Docker Swarm
Description:
You should review whether you wish to run Docker swarm manager in auto-lock mode.
Rationale:
When Docker restarts, both the TLS key used to encrypt communication among swarm nodes, and the key used to encrypt and decrypt Raft logs on disk, are loaded into each manager node's memory. You could protect the mutual TLS encryption key and the key used to encrypt and decrypt Raft logs at rest. This protection could be enabled by initializing the swarm with the --autolock flag.
With --autolock enabled, when Docker restarts, you must unlock the swarm first, using a key encryption key generated by Docker when the swarm was initialized.
This has benefits in a high security environment, however these should be balanced against the support issues caused by the swarm not starting automatically if, for example the host were to experience an outage.
Impact:
A swarm in auto-lock mode will not recover from a restart without manual intervention from an administrator to enter the unlock key. This may not always be desirable, and should be reviewed at a policy level.
Audit:
You should run the command below 

docker info --format 'Swarm Autolock: {{ 
.Swarm.Cluster.Spec.EncryptionConfig.AutoLockManagers }}' 

If the result is true, auto-lock mode is enable. You could also run the command below. If a key value is returned, it means that the swarm was initialized with the --autolock flag. If the output is no unlock key is set, it means that swarm was NOT initialized with the --autolock flag. This should be reviewed in line with the organization's IT Security policy. 

docker swarm unlock-key 

Remediation:
If you are initializing a swarm, use the command below. 

docker swarm init --autolock 

If you want to set --autolock on an existing swarm manager node, use the following command. 

docker swarm update --autolock 

Default Value:
By default, the swarm manager does not run in auto-lock mode. 

7.6 Ensure that the swarm manager auto-lock key is rotated periodically (Manual)
Profile Applicability:
Level 1 - Docker Swarm
Description:
You should rotate the swarm manager auto-lock key periodically.
Rationale:
The swarm manager auto-lock key is not automatically rotated. Good security practice is to rotate keys.
Impact:
None
Audit:
Currently, there is no mechanism to find out when the key was last rotated on a swarm manager node. You should check with the system administrator to see if there is a key rotation process, and how often the key is rotated.
Remediation:
You should run the command below to rotate the keys. 

docker swarm unlock-key --rotate 

Additionally, to facilitate auditing of this recommendation, you should maintain key rotation records and ensure that you establish a pre-defined frequency for key rotation.
Default Value:
By default, keys are not rotated automatically. 

7.7 Ensure that node certificates are rotated as appropriate (Manual)
Profile Applicability:
Level 1 - Docker Swarm
Description:
You should rotate swarm node certificates in line with your organizational security policy.
Rationale:
Docker Swarm uses TLS for clustering operations between its nodes. Certificate rotation ensures that in an event such as a compromised node or key, it is difficult to impersonate a node. By default, node certificates are rotated every 90 days, but you should rotate them more often or as appropriate in your environment.
Impact:
None
Audit:
Run one of the commands below and ensure that the node certificate Expiry Duration is set as appropriate. 

docker info | grep "Expiry Duration" 
docker info --format 'NodeCertExpiry: {{ 
.Swarm.Cluster.Spec.CAConfig.NodeCertExpiry }}' 

Remediation:
You should run the command to set the desired expiry time on the node certificate. For example: 

docker swarm update --cert-expiry 48h 

Default Value:
By default, node certificates are rotated automatically every 90 days.

7.8 Ensure that CA certificates are rotated as appropriate (Manual)
Profile Applicability:
Level 1 - Docker Swarm
Description:
You should rotate root CA certificates as appropriate.
Rationale:
Docker Swarm uses TLS for clustering operations between its nodes. Certificate rotation ensures that in an event such as a compromised node or key, it is difficult to impersonate a node. Node certificates depend upon root CA certificates. For operational security, it is important to rotate these frequently. Currently, root CA certificates are not rotated automatically and you should therefore establish a process for rotating them in line with your organizational security policy.
Impact:
None
Audit:
You should check the time stamp on the root CA certificate file. 
For example:

ls -l /var/lib/docker/swarm/certificates/swarm-root-ca.crt 

The certificate should show a time stamp in line with the organizational rotation policy.
Remediation:
You should run the command below to rotate a certificate. 

docker swarm ca --rotate 

Default Value:
By default, root CA certificates are not rotated.

7.9 Ensure that management plane traffic is separated from data plane traffic (Manual)
Profile Applicability:
Level 1 - Docker Swarm Description: You should separate management plane traffic from data plane traffic.
Rationale:
Separating management plane traffic from data plane traffic ensures that these types of traffic are segregated from each other. These traffic flows can then be individually monitored and tied to different traffic control policies and monitoring. This also ensures that the management plane is always reachable even if there is a great deal of traffic on the data plane. Impact: This requires two network interfaces per node.
Audit:
You should run the command below on each swarm node and ensure that the management plane address is different from the data plane address. 

docker node inspect --format '{{ .Status.Addr }}' self 

Remediation:
You should initialize the swarm with dedicated interfaces for management and data planes respectively. 
For example, 

docker swarm init --advertise-addr=192.168.0.1 --data-path-addr=17.1.0.3 

Default Value:
By default, data plane traffic is not separated from management plane traffic.