Microsegmentation and Policy at the Workload Boundary

Perimeter models assume most interesting traffic crosses a boundary that has a firewall on it. In a segmented network the traffic that matters increasingly does not: a service calling another service inside the same segment, or two containers on the same host, or two virtual machines on the same hypervisor whose packets never leave the physical machine. Policy that exists only in a switch or an appliance cannot see those flows at all. Microsegmentation is the name for moving the enforcement point to the workload, so that the policy applies regardless of where the workload sits or where its packets go.

Why the address is the wrong key

An address-based rule names the endpoints by a value that changes. In a virtualised or containerised environment a workload is scheduled onto a host, receives an address from a pool, and later moves or is replaced by a new instance with a new address. Rules that name addresses must be updated when the topology changes, and the update has a window during which the policy is wrong: either too permissive, because the old rule still matches a different tenant’s workload that inherited the address, or too restrictive, because the new address is not yet covered.

Identity-based policy names the workload by a stable property: a service account, a label set, a cryptographic identity, or an attribute asserted at attestation time. The mapping from identity to current address is then environment state maintained by a control plane, not part of the rule. That distinction matters because address reuse produces a specific failure in shared pools: a rule referring to an address silently applies to whatever workload next receives it, which is an authorisation decision the policy author never made.

Mutual TLS is the identity mechanism that requires no trust in the network layer at all. Each workload has a certificate whose subject or extension encodes its identity, and each side validates the other’s certificate chain against a private authority. The policy then constrains which identities may speak to which, and the check is performed by the endpoints rather than by any device in between. The cost is real: a certificate per workload with a lifetime short enough that revocation is mostly unnecessary, a private authority whose signing keys are the highest-value secret in the system, and per-connection handshake work that rises with the proportion of short-lived connections. Certificate profiles are specified in RFC 5280, and the identity naming convention is what the SPIFFE specifications standardise.

Where enforcement physically happens

Policy can be evaluated at several points, and the choice determines what the policy can express.

In the guest or container network namespace, the ordinary host packet filter is used: rules that match on the local process’s traffic, with the connection-tracking semantics of How a Stateful Firewall Matches a Packet. This is well understood and auditable, and its weakness is that the enforcement is inside the thing being protected. A compromised workload with sufficient privilege can change its own rules.

At the hypervisor or the host kernel, enforcement sits outside the guest. On Linux this is commonly done with a packet-processing hook in the kernel’s networking path plus a control plane that translates identities into rules. The advantage is that the guest cannot alter the policy, and that the enforcement sees traffic between two local workloads that never reaches a physical interface. The disadvantage is that the policy engine is now a privileged kernel component whose bugs are host-wide failures.

In a sidecar process beside the workload, enforcement is a user-space proxy that terminates and re-originates connections, the same termination model as Application Proxy Firewalls and Parser Differentials, applied per pod instead of per network. This is where mutual TLS enforcement is cheapest to place, because the sidecar already holds the certificate. The cost is a process and two sockets per workload, plus a redirect rule to steer traffic into the proxy in the first place.

Writing a policy requires seeing the traffic

A microsegmentation policy is a statement about which identity pairs may communicate. That statement cannot be derived from the intended architecture, because real traffic includes things no diagram shows: telemetry exporters, licence checks, database connection pools reaching replicas directly, administrators connecting from jump hosts, and monitoring probes. The practical method is to observe first and enforce second.

Observation is available from the enforcement point itself if the platform supports a monitor-only mode, or from flow export at the network layer. Flow records are the subject of Flow Records and Traffic Baselining, and their key property here is that they describe who talked to whom and on which port, without payload. That is exactly the input a policy needs, and exactly what is missing when the only available telemetry is host-local logs that a workload can suppress.

The scale problem is the second constraint. If a policy is expressed pairwise over n identities it has up to n²/2 potential rules, and the set of rules actually needed is usually sparse. Practical systems therefore express policy as defaults plus exceptions grouped by selectors, and rely on a directory that resolves a label set to current members. The failure mode of a grouped rule is over-grant: a label applied more broadly than intended silently authorises traffic that no one wrote a rule for.

Failure modes that differ from perimeter firewalls

Fail-open control planes. If the policy distribution mechanism is unavailable, a workload cannot receive updates. The two options are to keep the last known policy, which drifts from reality as workloads move, or to drop the enforcement and pass traffic. The latter converts an availability incident into a security incident. There is no configuration that avoids the choice; it can only be made explicit, and the “last known policy” branch needs an expiry so that a workload does not run an arbitrarily old rule set indefinitely.

Policy gaps for existing flows. Connection tracking is stateful, so revoking a rule mid-connection does not necessarily terminate an established session. Whether it does depends on whether the enforcement point re-evaluates existing state. Environments that expect immediate revocation get behaviour closer to “revoked at the next connection”.

Asymmetric enforcement. When a rule permits A to B but B has no rule permitting A, connection setup still succeeds because B’s acceptance is driven by the reply state, while B’s own connection attempts to A are denied. The resulting policy reads as symmetric when written in the intent language and is not symmetric in effect, which produces confusing test results during rollout.

The observation blind spot. Anything the workload encrypts at the application layer, inside its own process, is invisible to every enforcement point outside it. Identity from mutual TLS still authenticates the endpoints, but the content of the flow is unchecked. The inspection ceiling is therefore the same one described for proxy deployments: terminate at the proxy, or do not inspect.

What microsegmentation is worth

The measurable gain is coverage. A rule set expressed over workload identities applies to every path between them, including intra-host paths that no network appliance observes, and it follows a workload that is rescheduled. The measurable cost is the control plane: it becomes a system whose unavailability stops deployments, whose misconfiguration changes connectivity network-wide, and whose credentials, meaning the signing authority, are the most consequential secret in the environment. That concentration is the honest trade. What it replaces is a set of address-based rules whose correctness depends on the address plan never being reused, which is not a property most environments can maintain.