External Traffic Policy is a Kubernetes service setting that controls whether incoming traffic is routed only to node-local pods or to pods on any node. It changes how load balancers and NodePorts forward requests, affecting source IP preservation, routing behaviour and where traffic can be delivered.
What External Traffic Policy Controls
External Traffic Policy is a Kubernetes service-level routing choice, so the key idea is not just where packets go, but which backend pods are eligible to receive them. That makes it a traffic-shaping and exposure-setting decision, with direct effects on load balancer behaviour, NodePort forwarding, and whether source IP information is preserved for downstream policy or logging.
Why Routing Scope Matters
When a Service uses the broader routing mode, kube-proxy or the cloud load balancer can distribute traffic across pods on any node, which can improve balancing and resilience. When the policy is narrowed to node-local delivery, traffic is only sent to pods running on the node that received the request, which changes failover behaviour and can make some nodes appear empty even when the Service still has healthy endpoints elsewhere.
This distinction matters because a Kubernetes Service is not only a discovery object, it is also part of the data path. A policy change can alter latency, locality, and the operational picture seen by ingress or edge components, so it should be treated as a workload-routing decision rather than a cosmetic Service setting.
Source IP Preservation and Observability
One of the most practical effects of External Traffic Policy is source IP preservation. With local-only routing, the original client address is more likely to remain visible to the pod, which helps with application logs, rate limiting, geofencing, abuse correlation, and any control that depends on the real caller rather than the node address.
That same behaviour can also expose assumptions in application design. If an app expects every request to arrive through a stable internal proxy path, changing the policy may affect access logic, telemetry, or allowlists. For traffic policy analysis in Kubernetes environments, the MITRE D3FEND Guide is useful for mapping traffic mediation and routing controls to defensive techniques.
Operational Trade-Offs in Kubernetes Services
External Traffic Policy is often chosen to balance two competing needs: preserving client context versus spreading traffic as widely as possible. Local-only delivery can reduce hop count and retain source information, but it also depends on enough ready pods existing on each receiving node. Broader delivery is more tolerant of uneven pod placement, but it can hide the original client source unless another layer preserves it.
For teams running edge-facing Services, this is a design-time decision that should match the purpose of the workload. A public ingress path, a telemetry-sensitive API, and an internal service mesh gateway may all justify different routing expectations even if they share the same Kubernetes primitives. The External Secrets Operator security guide is a useful adjacent reference because it shows how Kubernetes control choices and policy settings affect real service behaviour.
Where traffic classification is a concern at the perimeter, the Bot vs AI Agent Traffic Management Guide also illustrates how edge policy depends on what the caller looks like and what metadata remains visible in transit.
When to Review or Change the Policy
Review the setting when you are troubleshooting asymmetric routing, unexpected source NAT behaviour, uneven request distribution, or missing client IPs in application logs. It is also worth revisiting after topology changes, node pool scaling, or ingress redesigns, because the right answer depends on where pods run and how the front door is constructed.
In practice, the safest approach is to treat this as a service-specific control, document why the chosen mode exists, and verify it after changes to cluster networking, load balancer configuration, or pod placement strategy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | External traffic policy directly shapes ingress routing and boundary mediation. |
| AC-4 — Information Flow Enforcement | The setting enforces which endpoints may receive incoming traffic and how it flows. | |
| Recommendation — Apply SC-7 to control and inspect external request paths before they reach pods. Use AC-4 to constrain traffic paths to the intended backend scope. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Kubernetes service routing is part of managed network infrastructure and traffic control. |
| Recommendation — Document and review service routing choices under CIS-12 as part of network oversight. | ||
Related resources from NHI Mgmt Group
- What breaks when policy is enforced only after traffic leaves the device?
- Who is accountable when AI hackathon traffic exceeds budget or violates policy?
- Who is accountable when AI policy decisions need to satisfy both internal controls and external frameworks?
- Who is accountable for MFA policy governance when an external authentication method is used in Entra ID?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org