Once a node has been added to a swarm, it is a candidate for container workloads to be scheduled. Many production deployments use constraints to ensure that applications are run on the correct type of node, and Docker will try to match the requested constraints to labels on the nodes.

In a regulated environment, you may have requirements to ensure that applications run only on those servers that have met required audit levels, like PCI compliance for credit card processing. You can identify compliant nodes with labels and use constraints to ensure that the applications only run on those nodes. Swarm mode helps ensure that these constraints are properly enforced.

There are two types of labels in swarm mode: engine labels and node labels. Engine labels are set by the machine in the Docker service configuration, so, if a worker was compromised, an attacker could add labels and make a machine they own appear to be compliant. Node labels are set by the swarm, so they can only be created by a user with access to a swarm manager. Node labels mean you don't have to rely on claims made by individual nodes, so, if they are compromised, the impact can be limited.

Node labels are also useful in segregating access to applications. You may have Docker hosts that are accessible only on your internal network and others that have access to the public internet. With labels, you can explicitly record it as a distinction and run containers with constraints based on the labels. You could have a content management system in a container that is only available internally but a web proxy that is available publicly.