Topic starter
25/10/2026 11:03 am
TL;DR: Trusting the wrong source IP can let an attacker forge identity-bearing headers and skew allow or block decisions, Codenotary shows. Ingress controls need tightly bounded upstream sources so client provenance stays reliable.
Editorial analysis by NHI Mgmt Group, based on content published by Codenotary: “Traefik, k3s and the proxy protocol”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Proxy protocol can preserve client provenance through ingress layers, but only if the receiver trusts a tightly bounded set of upstream sources.
Glossary terms: PROXY Protocol, Trusted IP Allowlist, ExternalTrafficPolicy Local
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:16 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Trusted IP boundaries decide whether Traefik proxy protocol works
This post was modified 7 days ago by NHI Mgmt Group