Apply zero trust to cloud-native systems

System and boundaries

A cloud-native access path can include a user or workload, cloud identity, external and internal gateways, API server, service mesh, sidecar or node proxy, workload identity system, service, application object, policy controllers, secret and certificate systems, observability, and several cloud or cluster control planes.

Draw identities and trust domains before products. Human identity, workload identity, node identity, cloud role, Kubernetes ServiceAccount, agent identity, and application account are not interchangeable. Mark where one becomes another and whether the original actor or delegation survives.

Request and decision flow

1. A human or workload obtains identity from an accountable issuer.
2. The client requests one named API, service, or infrastructure action.
3. An ingress or access gateway authenticates and authorizes the external path.
4. A workload identity mechanism establishes the calling workload for internal hops.
5. Mesh, platform, cloud, or Kubernetes policy controls service and infrastructure actions.
6. The application authorizes the final object or business action.
7. Evidence preserves subject, actor, workload, delegation, resource, action, policy, and result across hops.

Avoid blindly forwarding a broad user or cloud token. Exchange or derive narrow, audience-bound authority when the downstream design supports it.

Failure domains

Cloud-native failures include compromised control-plane credentials, broad cloud roles, node credential theft, Kubernetes privilege escalation, mesh bypass, sidecar omission, metadata-service credential theft, cross-cluster trust, stale policy replicas, shared certificate authorities, direct load balancers, and application actions outside gateway knowledge.

Test another namespace, ServiceAccount, node, cluster, cloud account, audience, route, and direct service address. Verify behavior during identity issuer, policy controller, mesh, certificate, DNS, and gateway failure.

Design tradeoffs and residual risk

Central gateways simplify user access and do not mediate all internal traffic. Sidecars provide local enforcement and expand the trusted code and configuration base. Shared workload trust eases federation and increases cross-environment impact. Short credentials reduce replay and add renewal dependency.

Several policy layers add defense and can disagree. Define ownership and which deny wins. Residual risk includes compromised control planes, workload use of valid authority, node or kernel compromise, hidden cloud paths, and application object authorization defects.

Pomerium boundary

Pomerium can protect named human and non-human access routes to cloud-native services, including supported Kubernetes and non-HTTP paths. It does not replace cloud IAM, Kubernetes authorization and admission, workload identity, service-mesh policy, node security, metadata protection, or application authorization. Operators must close direct paths and preserve identity across each layer.

Exercise

Trace one human administrative request and one service request across gateway, cloud, cluster, mesh, workload, and application boundaries. Record identity, credential, audience, resource, action, decision, and evidence at each hop.

Test another tenant, cluster, namespace, ServiceAccount, audience, node path, internal load balancer, direct service address, and application object. Disable one policy controller and one identity issuer. Verify bounded failure and recovery without broad static-credential fallback.

Evaluation checklist

• Are human, workload, node, cloud, cluster, agent, and application identities distinct?
• Does each hop receive only the authority and audience it needs?
• Are gateway, mesh, platform, cloud, and application decisions assigned clear resource scopes?
• Do direct, cross-cloud, node, metadata, and control-plane paths have explicit controls?
• Can evidence and recovery preserve the complete identity and decision chain?