Place access control in a service mesh

System and boundaries

A service mesh supplies common communication functions to workloads. A control plane manages identity, discovery, policy, and proxy configuration. A data plane intercepts traffic and applies transport, routing, and policy at gateways or workload-adjacent enforcement points.

A sidecar proxy runs beside each workload instance. An ambient or node-level design can secure transport outside the Pod and add workload-specific layer 7 policy at another proxy such as a waypoint. Ingress and egress gateways handle traffic that crosses the mesh boundary. Product names vary. Draw the actual interception and identity path.

The workload remains a trust boundary. A proxy can authenticate a peer and allow a route. The application owns object and business-action authorization.

Request and decision flow

1. A workload receives a short-lived identity from an approved workload-identity system.
2. The control plane distributes trust bundles, service discovery, and policy to the applicable data-plane components.
3. The source-side component captures an outbound connection and authenticates the destination.
4. The destination-side component authenticates the source workload, validates transport, and applies policy with the available protocol and identity context.
5. A layer 7 enforcement point can apply service, method, path, or protocol policy. A transport-only point can apply connection-level identity policy.
6. The destination application applies local object and action authorization.
7. Data-plane evidence records identities, policy version, route, decision, and result.

For boundary traffic, the ingress gateway must preserve or establish the identity context that downstream policy uses. The egress gateway must authenticate the external destination and prevent workloads from using another outbound path.

Failure domains

• Traffic avoids interception through host networking, alternate interfaces, direct addresses, unsupported protocols, or misconfigured exclusions.
• The proxy authenticates a workload identity but policy grants every identity in the trust domain.
• The mesh enforces mutual TLS but no application authorization.
• Sidecar injection or ambient enrollment is missing for one workload.
• Stale configuration remains active after control-plane loss.
• A control-plane compromise distributes hostile policy or trust.
• Layer 7 rules do not apply to opaque, upgraded, or misclassified traffic.
• An egress gateway exists, but direct outbound networking remains open.
• A gateway strips, accepts, or forges identity headers incorrectly.

Use packet and process-level tests to prove interception. Do not infer it from desired configuration. Test new workloads, failed injection, node restart, control-plane partition, and unsupported protocol paths.

Design tradeoffs and residual risk

Sidecars give a workload-local enforcement point and clear per-Pod lifecycle. They add resources, injection, version skew, and a local bypass surface. Shared node or ambient proxies reduce per-Pod overhead and change isolation and failure domains. Layer 7 waypoints add precise policy and another hop.

Central policy improves consistency. It can also create a large control-plane blast radius. Local cached policy improves availability while increasing stale-state risk. Mutual TLS protects and authenticates a channel. It does not prove software integrity or user intent.

Residual risk includes compromised nodes, workload-to-proxy local attacks, policy lag, identity misissuance, parser differences, and direct paths. Keep network reachability, mesh identity policy, and application authorization as explicit layers.

Pomerium boundary

Pomerium can protect user and service access at application gateways and documented routes. A service mesh can own workload-to-workload identity and policy behind or beside that boundary. Operators must define where Pomerium identity ends, where mesh workload identity begins, and how the application receives both when needed. Do not assume Pomerium and a mesh share policy or identity automatically.

Exercise

Trace one request from an external user through Pomerium, a mesh ingress, two services, and a database. Mark every TLS endpoint, user identity, workload identity, policy decision, enforcement point, and application action.

Disable or bypass one sidecar or ambient enrollment in staging. Attempt the same request through a direct service address and alternate protocol. Partition the mesh control plane. Confirm the intended fail behavior and identify the exact policy version each proxy uses.

Evaluation checklist

• Is every traffic class intercepted by the intended data-plane component?
• Can each service authenticate the source workload and intended destination?
• Are transport, route, and application permissions separate?
• Is stale-policy behavior defined during control-plane loss?
• Can sidecar, ambient, gateway, egress, and direct-path failures be reproduced?