Use network controls in zero trust

Protection need

Zero trust removes implicit authorization from network location. It does not remove the need to deliver traffic, close unused paths, protect transport, contain compromise, absorb failure, and keep enforcement reachable. Routing, DNS, load balancers, firewalls, segmentation, private addressing, and transport security still provide these properties.

Separate three questions. Can the requester reach an endpoint? Is the transport bound to the intended endpoints and protected in transit? Can the authenticated subject perform this action on this resource? One control rarely answers all three.

Security objectives and requirements

• Publish only required entry points and protocols.
• Route protected traffic through the intended enforcement point.
• Restrict upstream listeners so direct clients cannot bypass policy.
• Segment control planes, data planes, workloads, evidence, and recovery by required flows.
• Authenticate transport endpoints and protect traffic where the threat model requires it.
• Limit lateral movement and shared failure domains after one workload or identity is compromised.
• Maintain name, route, load-balancer, and denial-of-service resilience for critical access.

Network rules should name flows and owners. They must not grant application authority only because a source is internal.

Security invariants and evidence

The public or client-facing name reaches the intended enforcement point. Only that enforcement identity and required operational services reach the upstream. Control-plane administration uses a separate protected path. Every alternate address, port, load balancer, cluster service, and recovery endpoint has an explicit result.

Use configuration evidence, active network tests, flow records, DNS and certificate validation, route inventories, firewall change history, and direct-origin negative tests. Test IPv4, IPv6, internal and external DNS, private networks, secondary regions, and failover paths where used.

Failure cases

• A private address is treated as proof of identity or permission.
• The gateway is protected while the upstream has another public or internal route.
• A broad client tunnel restores subnet-level access.
• Segmentation blocks normal traffic and opens a permanent emergency allow.
• DNS or load-balancer failover points to an unprotected origin.
• Encrypted traffic is accepted from any endpoint without identity-aware policy.
• Identity-service failure causes a fallback to location-only trust.

Design tradeoffs and residual risk

Fine segmentation limits movement and increases rule count, dependency mapping, and operational failure. Central ingress reduces exposed entry points and concentrates availability and attack pressure. Private networks reduce public exposure and retain insider and workload threats.

Fail-closed network policy protects sensitive services and can block recovery. Cached identity-aware decisions improve continuity and retain stale authority. Define critical-service degraded modes without creating a general trusted zone.

Residual risk includes unknown paths, compromised enforcement hosts, shared network administrators, application actions after route allow, and denial of service against required identity or gateway components.

Pomerium boundary

Pomerium applies identity-aware policy at named application routes. It needs correct DNS, TLS, load balancing, network reachability, and upstream isolation. Pomerium does not replace general routing, firewall, segmentation, transport, endpoint, or availability controls. Operators must ensure direct and failover paths cannot bypass it.

Exercise

Trace one protected service from public and internal names through DNS, load balancers, Pomerium, firewall rules, private routing, and the upstream. Add administrative, health, failover, and recovery paths.

Prove the expected route works. Test direct public, private, alternate port, internal DNS, IPv6, failover, and another workload path. Simulate identity-service and gateway failure and verify the system does not fall back to location-only trust.

Evaluation checklist

• Are reachability, transport protection, and resource authorization distinct?
• Does every required path pass through its intended enforcement point?
• Can only named enforcement and operational identities reach the upstream?
• Do failover and degraded modes preserve the protection objective?
• Do network controls limit paths and impact without treating location as authority?