Combine segmentation with identity policy

Protection need

Limit which systems can exchange traffic and ensure that each protected request has the correct subject, resource, action, and context. A network compromise must not expose every service. A valid network path must not grant application authority.

Segmentation groups systems and filters traffic between boundaries. Microsegmentation applies narrower workload or application-level reachability rules. Identity policy evaluates authenticated principals and context. Application policy evaluates objects and business actions. Use these controls together without making one pretend to be another.

Security objectives and requirements

• Only approved enforcement points can reach protected service listeners.
• Workloads can reach only required destinations and ports.
• Network location does not establish a user, workload, tenant, or application permission.
• Each route authenticates the caller and destination at the needed layer.
• Each application authorizes its own object and action.
• Changes to segment and identity policy have owners, review, tests, versions, and rollback.
• Denied and bypass attempts produce useful evidence without recording credentials.

Start from resource flows, not from existing subnets. Name the client, enforcement point, upstream, protocol, identity, and action. Then derive the smallest useful reachability graph.

Security invariants and evidence

An upstream accepts traffic only from the approved gateway or authenticated workload path. A caller from an allowed segment still needs identity authorization. An identity-allowed caller cannot use a direct network path around enforcement. A workload cannot reach an unrelated management or metadata endpoint.

Evidence includes effective firewall or NetworkPolicy state, route inventory, gateway policy version, caller and workload identities, application decision, direct-origin test, and flow logs. Correlate them for one request. Flow logs prove observed connections, not the absence of an unmonitored path.

Failure cases

• A broad shared segment lets one compromised workload scan and reach peers.
• An internal address or VPN presence is treated as user authorization.
• A gateway policy is correct, but the upstream remains reachable through another load balancer.
• Identity rules permit a route while a firewall silently blocks required dependency traffic, causing unsafe emergency bypass.
• Segment rules use mutable addresses for dynamic workloads and drift from current ownership.
• A microsegmentation agent fails open or applies a stale policy during control-plane loss.
• Egress is unrestricted, so a compromised workload steals metadata credentials or exfiltrates data.

Test a compromised workload in each meaningful zone. Attempt direct application access, peer movement, management access, metadata access, and unauthorized egress. Then test a valid identity from the wrong network path and an invalid identity from an allowed network path.

Design tradeoffs and residual risk

Coarse segments are easier to understand and operate but contain more lateral reachability. Fine microsegments reduce reach but increase rule count, identity dependencies, rollout risk, and troubleshooting work. Identity-aware gateways improve named-resource policy but do not filter every workload connection.

Use redundant controls for different failure modes, not duplicate controls with unclear owners. A network rule limits exposure if an application is vulnerable. Identity policy prevents an allowed address from becoming authority. Application policy protects internal objects after route access.

Residual risk includes compromised trusted enforcement points, policy propagation delay, unclassified flows, shared infrastructure, and emergency exceptions. Measure the reachable graph and exception lifetime.

Pomerium boundary

Pomerium can authenticate users or services and apply policy at configured routes. Network firewalls, cloud security groups, Kubernetes NetworkPolicy, and service-mesh controls remain separate owners for reachability. Operators must restrict direct upstream paths. Applications keep object authorization.

Exercise

Model one production application as a graph of client, gateway, upstream, database, identity provider, control plane, metadata service, and logging service. Mark each required edge and control owner. Remove every edge that exists only because the current network is broad.

Run four tests: valid identity through the gateway, invalid identity from an allowed segment, valid identity to the direct origin, and compromised upstream to an unrelated destination. Record which independent control denies each invalid path.

Evaluation checklist

• Does the design separate reachability, route authorization, and object authorization?
• Is the direct upstream reachable only from an approved enforcement path?
• Do dynamic workload rules use stable identity or controlled selectors instead of stale addresses?
• Are egress and management paths included in the graph?
• Can evidence and negative tests show which control denied each invalid path?