Label-based policy

Labels, not addresses

Workloads carry labels, such as role=db or env=prod, and rules are written between label sets. IP addresses are an output of rendering, never an input to policy.

What you author

• Rulesets select the workloads they protect by label and hold the rules.
• Services name a protocol and port, such as tcp:5432.
• Address groups name CIDRs, for peers that are not enrolled workloads.

This ruleset, from the deployment guide, applies to workloads labeled role=db. It admits inbound connections to the postgres service from workloads labeled role=web and from the corp address group:

{"name": "web-to-db", "scope": {"role": ["db"]},
 "rules": [{"direction": "inbound",
            "peers": [{"workloads": {"role": ["web"]}}, {"address_group": "corp"}],
            "services": ["postgres"]}]}

Rulesets, services and address groups are edited live, with no draft. Each write is conditioned on the version its author read. A dry run shows what a hypothetical policy would install on each workload before anything is written.

Inbound only in this release

Only inbound rules are admitted (ADR-0010): each workload’s ruleset constrains what may reach it. A rule with the outbound direction is rejected at admission (ADR-0015). Outbound policy is planned as a layered model, recorded in ADR-0010 and on the roadmap.

Rendering

On every change, the control plane renders the policy of every workload (ADR-0018). Label selectors resolve to the matching workloads and their current addresses, address groups to their CIDRs, and services to one rule per protocol, with the authored rule id kept for provenance.

A workload’s version advances only when its rendered policy changed, so the effect of an edit follows what the edit changed. Agents receive the rendered policy on their stream, as a snapshot on every new stream and as deltas within it (ADR-0015). Each agent acknowledges the version it applied, so desired against applied version is a fact you can query.