A traditional gateway proxy model routes traffic through a central control point, while a workload identity approach assigns access at the workload level and supports more granular policy enforcement. In practice, the difference matters because gateway-centric designs often require more explicit endpoint and namespace setup, whereas workload identity can align access controls more closely with individual application needs.
Why the architecture shifts from proxy-centric to workload-centric
A traditional gateway proxy model concentrates routing and policy at a central chokepoint. That makes sense when the main goal is to mediate traffic between zones, but it also means access decisions often depend on gateway topology, namespace plumbing, and policy expressed around paths rather than the application itself. A workload identity approach, by contrast, binds trust and access to the workload, so the policy follows the thing that is actually doing the work. In Kubernetes networking, that usually means tighter alignment between service-to-service access and the application’s real trust boundary.
For practitioners, the practical difference is that proxy-centric designs optimise traffic control, while workload identity optimises identity-aware access control. The newer model is especially useful when the cluster has many microservices, short-lived workloads, or frequent deployment changes, because policy can be expressed closer to the workload lifecycle instead of being rebuilt around a central proxy tier. That said, the control plane does not disappear, it just moves from “route everything through one place” to “prove who the workload is, then authorise it accordingly.” In practice, teams often discover the weakness of proxy-centric design only after lateral movement or policy sprawl has already accumulated.
How the two models behave in Kubernetes
In a gateway proxy model, traffic typically reaches a central intermediary first, and that intermediary decides whether to forward, inspect, or deny the request. This can simplify coarse-grained enforcement, but it also creates a heavier dependency on network paths, endpoint registration, and central policy configuration. If the gateway becomes the primary control point, the design tends to be strongest for north-south traffic and weaker for fine-grained east-west identity binding.
Workload identity changes the enforcement model. Instead of trusting a destination because it sits behind a proxy path, the cluster evaluates the identity of the calling and receiving workloads and applies access rules to that relationship. SPIFFE is the clearest public specification for this pattern, because it defines workload identities and attestation in a way that can be used to establish service-to-service trust rather than just network reachability. The result is less dependence on brittle network location and more reliance on cryptographically verifiable workload identity.
Practically, that difference shows up in policy design:
- Gateway proxy: central routing and inspection, with policy attached to a shared ingress or egress path.
- Workload identity: per-workload trust and authorization, with policy attached to service identity and runtime context.
- Gateway proxy: easier to reason about for simple perimeter mediation.
- Workload identity: better suited to least-privilege service communication in highly dynamic clusters.
This model is reinforced by the fact that machine identity management is already a scale problem, with one report noting that 66% of respondents say their current tooling is not adequate to manage the scale of machine identities they now have. These controls tend to break down when teams try to layer workload identity on top of vague service ownership, because the identity model cannot stay precise if the owning service, trust anchor, or certificate lifecycle is unclear.
Where each approach breaks down
Tighter workload-level control often increases operational overhead, so teams have to balance precision against the cost of running identity infrastructure well. Gateway proxies remain useful when the environment needs a simple choke point for inspection, legacy integration, or coarse traffic governance. They are also easier to understand when the primary concern is connection mediation rather than service-to-service trust.
Workload identity is more demanding when environments lack mature service inventory, automated issuance, or clear ownership. If identities are not lifecycle-managed, the benefit of fine-grained policy can be offset by certificate sprawl, stale credentials, or inconsistent attestation. It is also common for organisations to overstate how much a central proxy can protect east-west traffic, when the real control issue is whether the application can prove its own identity before a request is accepted.
For Kubernetes operators, the main edge case is mixed estates. Legacy services may still rely on proxy-mediated paths, while newer services can use workload identity directly. In those environments, current guidance suggests treating the gateway as a transition and aggregation layer, not as the long-term substitute for workload-bound trust. The practical boundary is simple: if policy needs to follow the service as it scales, restarts, or migrates, workload identity is the better fit; if the main requirement is broad perimeter mediation, the gateway proxy remains viable.
Risk and Threat Considerations
The main risk difference is trust concentration versus trust distribution. A gateway proxy concentrates enforcement, so a misconfiguration or bypass there can expose multiple services at once. Workload identity distributes trust more narrowly, which reduces blast radius, but it also increases dependence on correct attestation, certificate handling, and policy alignment across many workloads.
Failure mechanism: In proxy-centric models, attackers and misconfigurations benefit from the fact that one central path often becomes the easiest place to over-permit traffic, miss an endpoint, or create an exception that applies too broadly. In workload identity designs, the risk shifts to identity lifecycle failures, such as stale credentials, weak attestation, or policy drift between the workload’s actual runtime identity and the access rules attached to it.
Impact: A weak gateway model can widen lateral movement opportunities and make segmentation look stronger than it really is. A weak workload identity model can create fine-grained controls on paper while still allowing unauthorised service-to-service access in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Workload and Machine Identity Governance | Covers workload identity trust, lifecycle and overprivilege in Kubernetes networking. |
| NHI-04 — Secrets and Credential Lifecycle | Applies because workload identity depends on credential issuance, rotation and revocation. | |
| NHI-06 — Third-Party and Cross-Boundary Trust | Relevant where gateway and workload identity mediate trust between services and clusters. | |
| Recommendation — Bind service access to workload identity and enforce least privilege for each service account. Automate credential rotation and revoke stale workload credentials promptly. Constrain cross-boundary trust paths and review every exception that expands service-to-service access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Directly fits the shift from network-path trust to identity-bound access decisions. |
| Recommendation — Apply identity-based access decisions instead of trusting network location or proxy placement. | ||
| CIS Controls v8 | 6 — Access Control Management | Supports least-privilege service access and controlled revocation in Kubernetes environments. |
| Recommendation — Review and remove unnecessary service access paths on a regular schedule. | ||
Practitioner Guidance
What to prioritise: Decide whether the cluster problem is traffic mediation or service trust. If the real need is least-privilege service communication, make workload identity the control anchor and treat the gateway as an auxiliary policy layer.
What to verify: Confirm that every workload can be uniquely and consistently identified, that identity issuance is automated, and that the policy engine is using current runtime identity rather than static network location. Also verify ownership, because workload identity fails quickly when no one can prove who is responsible for rotation and revocation.
Decision rule: If a service can be restarted, rescheduled, or scaled without losing its trust relationship, the model is closer to workload identity. If the security design still depends on one shared choke point for meaningfully enforcing access, the architecture remains proxy-centric.
Practitioner takeaway: The upgrade is not simply from “proxy” to “identity”, it is from controlling where traffic passes to controlling which workload is trusted to act at all.
Related resources from NHI Mgmt Group
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between workload identity and traditional IAM?
- What is the difference between workload identity and traditional network based trust in a service mesh?
- What is the difference between a graph-based security model and a traditional linear list approach?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
