Docker 17.06 makes the Swarm certificate authority manageable

A cluster's certificate authority is a dependency with a longer lifetime than any individual container. Applications may be replaced repeatedly while the same authority continues to identify cluster participants. Docker 17.06 adds a management operation for that dependency, including inspection and rotation of the Swarm root certificate. The change makes a piece of cluster trust subject to an explicit lifecycle.

The 17.06.0-ce release notes date the release to 28 June. They include the new docker swarm ca command and an API for rotating the CA certificate. Client and API changes matter together because rotation is a cluster operation whose progress the client must represent, rather than a local file replacement.

I value Docker when it makes the inputs to a running environment understandable. That concern extends beyond the image filesystem. A service deployed across a cluster also depends on the cluster's identities and trust configuration, which deserve operations as explicit as those used for images or application services.

The command exposes the current root

Ying Li's client implementation proposal, merged in May, explains the command's purpose and shows its output. With no rotation option, docker swarm ca prints the current root certificate in PEM form. That gives administrators a direct view of the authority associated with the swarm.

Inspection and replacement are separate invocations. The basic inspection command does not request a new authority:

docker swarm ca

The proposal's help output lists paths for a root certificate and private key, external certificate signing endpoints and certificate validity settings. These options reveal that the command must accommodate more than one source of trust material. A swarm may use supplied material or ask Docker to generate new material during rotation.

Printing the public certificate also makes an important distinction visible. A certificate can be inspected without printing the corresponding private key. The command's output describes the authority, while the key remains a separate input when an administrator supplies replacement material. The interface gives those objects different roles rather than presenting them as interchangeable certificate files.

Rotation has continuing cluster work

The proposal specifies --rotate to initiate CA rotation. If no certificate or key is supplied, Docker generates replacements. The operation also has a detach flag whose description says it exits immediately instead of waiting for root rotation to converge. That wording establishes a practical difference between requesting rotation and completing its propagation.

A cluster has multiple participants, so changing its authority requires coordinated progress. The command's progress reporting is part of the interface for that work. A caller that chooses detached execution accepts responsibility for observing completion elsewhere. Waiting gives the command a role beyond merely confirming that an API request was accepted.

The proposal also records why a separate command was chosen. Li considered expressing rotation through docker swarm update, but found the syntax awkward when asking Docker to generate the certificate and key. The dedicated command gives inspection, supplied replacements and generated replacements one place in the client without requiring an empty certificate specification to mean generation.

This is a useful example of an interface decision following the lifecycle being managed. A root authority has inspectable state and a replacement process. The command groups those related operations, while the options distinguish the source of the replacement and whether the caller waits for convergence.

Cluster trust becomes easier to inspect elsewhere

The release notes also add TLS information to swarm and node information endpoints, along with client display of cluster and node TLS information. That complements the CA command. The authority's certificate is one object, while the information associated with a particular node is another view needed to understand the cluster.

These additions are useful because a person diagnosing cluster identity needs more than a statement that certificates exist. The client has to expose the information the engine already associates with nodes and the swarm. Otherwise the management operation and the observable state remain disconnected in ordinary tooling.

The same release fixes an issue that prevented an external CA from being accepted. That item should remain distinct from the new rotation API. One is a correction to accepting a configured authority, and the other adds a lifecycle operation. Their presence in the same release does not make every external signing configuration equivalent to Docker-generated material.

I prefer this treatment of trust as part of cluster state. A reusable application image cannot explain which authority admitted the machines executing it. Exposing that information alongside a dedicated management command gives the operational environment a representation outside the application's build description.

Stack files gain more host and service controls

Docker 17.06 also expands the deployment description accepted by stack operations. The release notes include nameservers and search domains, placement preferences and read-only service support. These are concrete inputs to how an application runs after its image has been built. They belong in deployment configuration because the same image can need different settings in different environments.

Placement now takes the platform into account as well. That reflects another property an image name alone cannot settle. A distributed deployment must relate the requested workload to the capabilities of the machine selected to execute it. The runtime artifact and the placement decision have connected but different responsibilities.

Services can also carry arbitrary configuration objects, and secrets gain configurable locations inside a container. These additions make more runtime inputs representable without embedding them into an image. Windows secrets support broadens that model to another host platform. The useful effect is to keep configuration and credential delivery associated with the running service.

The release's networking changes include a separate interface selection for application data traffic through --data-path-addr. Control traffic and application data need not use the same interface. That separation is another reminder that a cluster's operational topology includes choices outside the filesystem described by a Dockerfile.

Registry compatibility changes independently

Legacy registry v1 communication is disabled by default in this release. The notes supply a daemon option to restore interaction where it is still required. This is a default change affecting image acquisition, separate from whether a swarm's own node identities and certificate rotation work correctly.

A deployment can therefore depend on two different trust and compatibility relationships. The cluster has its own authority and participants. Images arrive through registry interactions governed by registry configuration and protocol support. A failure to obtain an image should not automatically be interpreted as a failure in Swarm's certificate authority.

Docker 17.06 makes several of these dependencies explicit at their owning interfaces. The CA command manages cluster authority, stack fields describe service runtime requirements, and registry settings govern image transport compatibility. For an operator, the immediate improvement is the ability to inspect the current root and request its rotation through a command that can wait for the cluster operation to converge.