TL;DR: Proxy protocol support in Traefik for k3s preserves the originating client IP across load balancers, but Codenotary shows that trusting the wrong source IP can let an attacker forge identity-bearing headers and skew allow or block decisions. The control boundary is not the header itself but the tightly constrained set of IPs allowed to assert it.
At a glance
What this is: This is a configuration guide for preserving client IPs through Traefik in k3s using proxy protocol and trusted IP allowlists, with the key warning that untrusted assertion sources can falsify the originating address.
Why it matters: It matters because access decisions, logging, and IP-based controls are only as reliable as the trust boundary around forwarded metadata, which can affect both infrastructure security and any identity workflow that depends on source IP.
Context
In Kubernetes ingress paths, the original client IP often disappears once traffic passes through a load balancer or intermediate proxy. Proxy protocol restores that metadata by carrying the source address in a preamble, but the design only works when the receiving proxy trusts a tightly bounded set of upstream senders.
For identity and access decisions, that trust boundary matters more than the syntax of the configuration. If a proxy accepts forged origin data, downstream controls can make decisions on attacker-supplied metadata instead of observed network provenance.
Key questions
Q: How should teams prevent forged client IPs in proxy protocol setups?
A: Treat the proxy path as a trust boundary and allow only known upstream addresses to assert source IP metadata. Pair that with routing that preserves client provenance and never let downstream allowlists rely on headers or preambles that any direct client could spoof.
Q: Why do source IP controls fail when traffic passes through ingress proxies?
A: They fail when the system trusts asserted origin metadata without validating who was allowed to assert it. Load balancers and ingress controllers can preserve the address, but if the receiver accepts claims from the wrong source, allowlists and logging become unreliable.
Q: What signs show that ingress provenance handling is misconfigured?
A: Look for inconsistent client IPs in logs, allow or block decisions that change after topology changes, and proxies that accept forwarded origin data from more than the expected load balancer range. Those signals usually mean the trust boundary is too broad.
Q: Should organisations trust client IP metadata for security decisions?
A: Only when the full path that asserts the address is tightly controlled and the metadata is validated against a narrow list of expected sources. Source IP is useful for policy, but it is not strong identity unless the assertion layer is itself governed.
Technical breakdown
How proxy protocol preserves the original client IP
Proxy protocol adds a small preamble to the connection that tells the next hop which client IP originally initiated the session. The application then reads that asserted address instead of the socket peer address, which is necessary when traffic traverses load balancers or reverse proxies. In k3s with Traefik, this is what allows request logging and IP-aware routing to reflect the external client rather than the internal hop. The security model depends on the fact that only trusted intermediaries are allowed to emit that preamble; otherwise any direct client could impersonate another source address. Practical implication: treat proxy protocol as a trust mechanism, not a convenience feature, and restrict who can speak it. See the Federation and Trust Relationships Guide.
Practical implication: Restrict proxy protocol acceptance to known upstream addresses and review every path that can inject source IP metadata.
Why externalTrafficPolicy local matters for ingress provenance
When Kubernetes services forward traffic across nodes, the cluster may rewrite or hide packet source information as it routes to the correct pod. Setting externalTrafficPolicy to Local preserves client source information by keeping traffic on nodes that directly host the service endpoint, reducing the chance that provenance data is lost before Traefik can process it. This does not authenticate the source by itself, but it prevents the platform from erasing the network evidence you need for trust decisions. In practice, provenance preservation and provenance validation are separate controls. Practical implication: keep local traffic handling aligned with ingress design when client IP is part of a security control.
Practical implication: Enable local traffic handling where client IP fidelity is required and verify that routing does not strip provenance before policy evaluation.
How trusted IP allowlists stop forged proxy assertions
Trusted IPs are the enforcement layer that decides which upstream addresses are allowed to assert proxy protocol metadata. Without that list, a hostile client that can reach the proxy directly could inject a false origin address and cause downstream components to treat it as authentic. That creates a control failure when allowlists, deny lists, rate limits, or audit logic depend on the originating IP. The article’s key point is that the metadata is only safe if the network path is already constrained and the accepted source list is kept small and accurate. Practical implication: bind proxy protocol acceptance to specific load balancer addresses and review them whenever the ingress path changes.
Practical implication: Maintain a narrow trusted IP list for every proxy protocol listener and update it whenever load balancers or network paths change.
NHI Mgmt Group analysis
Proxy protocol creates a provenance problem, not just a transport problem: the technical risk is not whether Traefik can preserve the client IP, but whether the cluster can prove who is allowed to assert that IP. Once downstream controls consume asserted origin data, the proxy path becomes part of the trust boundary. Practitioners should treat source-IP metadata as security-sensitive identity evidence, not as passive logging detail.
The named concept here is source-IP assertion trust: a system only gets a reliable originating address if the asserting hop is both expected and tightly constrained. That is why the trusted IP list is central, and why a misrouted ingress or an exposed proxy listener becomes a governance failure, not just an operational defect. The practitioner conclusion is to govern provenance assertions with the same discipline used for privileged trust relationships.
Ingress configuration now intersects with identity policy in subtle ways: many teams use source IP as a surrogate signal for access decisions, fraud checks, or administrative allowlists. If proxy protocol metadata can be forged, those identity-adjacent controls inherit the same weakness. The right posture is to separate network provenance validation from the business decision that consumes it.
This pattern is a reminder that Kubernetes networking and identity governance increasingly overlap: a proxy that can rewrite who appears to be calling is effectively mediating an identity claim. That makes trusted IP management a control problem, not a convenience setting. Practitioners should review where source IP is used as an authorization input and tighten those paths first.
Lateral movement is not the only concern in proxy misuse: if an attacker can present a trusted-looking network identity, they can often move from ingress manipulation into broader policy evasion. The broader lesson is that metadata trust must be explicit, narrow, and observable. Practitioners should audit every control that assumes the network layer is telling the truth.
What this signals
Source-IP assertion trust: the most useful way to read this article is as a governance model for metadata that looks authoritative but is only as trustworthy as the network hop that asserts it. That framing matters because many teams still use client IP as an access signal without separately validating the assertion path. The safer programme design is to treat provenance as a controlled claim, not a default fact.
Where identity-adjacent controls consume network metadata, the issue is less about Kubernetes and more about evidentiary integrity. A forged origin address can distort logging, policy enforcement, and investigation timelines, so teams need to decide which controls may use source IP and which controls must use stronger authentication signals.
For practitioners
- Lock proxy protocol to trusted upstream addresses Configure Traefik so only the known load balancer IPs can assert proxy protocol metadata, and remove any broad or temporary ranges once the deployment stabilises.
- Preserve source IP across ingress routing Set externalTrafficPolicy to Local where the originating client IP is required for security decisions, then verify that requests still reach the correct pods without losing provenance.
- Audit all IP-based access controls Find allow lists, deny lists, rate limits, and alerting rules that depend on client IP and confirm they use trusted ingress metadata rather than directly trusted request headers.
- Revalidate configuration after every k3s upgrade Check the deployed Helm values after Traefik or k3s version changes, because the accepted configuration keys and runtime parameters can change across releases.
Key takeaways
- Proxy protocol can preserve client provenance through ingress layers, but only if the receiver trusts a tightly bounded set of upstream sources.
- The main failure mode is forged source-IP assertions, which can distort logging and any access control that depends on origin address.
- Practitioners should narrow trusted IP lists, preserve routing provenance, and review every IP-based control that consumes ingress metadata.
Related NHI Mgmt Group resources: Federation and Trust Relationships Guide · SSRF Prevention Guide · Lateral Movement Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | IP-based allowlists are access decisions driven by asserted provenance in this article. |
| Recommendation — Restrict access decisions to trusted ingress paths and validate asserted source metadata before enforcing policy. | ||
| MITRE ATT&CK | TA0001 — Initial Access | A forged proxy source can enable unauthorized ingress as an initial access path. |
| Recommendation — Map exposed proxy listeners to TA0001 and remove any direct paths that accept untrusted provenance claims. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s trusted IP list is a governed access boundary that needs lifecycle control. |
| Recommendation — Review and recertify trusted IP sources as controlled access entries tied to ingress management. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Only specific upstream addresses should be able to assert proxy metadata. |
| Recommendation — Limit who can assert proxy protocol metadata to the minimum set of approved ingress sources. | ||
Key terms
- PROXY Protocol: PROXY Protocol is a connection metadata format that preserves original client and transport information when traffic passes through a proxy or relay. It allows downstream services to see source details that would otherwise be hidden, which supports logging, policy enforcement, and troubleshooting in layered network paths.
- Trusted IP Allowlist: A trusted IP allowlist is a controlled set of source addresses permitted to perform a sensitive action, such as asserting proxy metadata or reaching an administrative endpoint. Its security value depends on keeping the list narrow, current, and tied to the real network path rather than to convenience.
- ExternalTrafficPolicy Local: ExternalTrafficPolicy Local is a Kubernetes service setting that helps preserve client source information by keeping traffic on nodes that directly host the service endpoint. It does not authenticate the caller, but it reduces source-address rewriting that would otherwise weaken provenance-based controls.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a practitioner-focused format. It helps security and identity teams build the governance discipline needed for trusted access decisions across modern environments.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org