I am migrating an existing Vault server from behind an existing L7 proxy to a kubernetes setup with Traefik set up as a level-4 ingress route for Vault.
In the old setup, I’d used the x-forwarded-for features with a list of authorized addresses from my L7 proxy, and things worked fine.
Now, however, I still have the same set of known IPs for my L7 proxy, but because I have a L4 proxy in between, I can’t authorize the addresses (because as far as Vault is concerned, the final hop is coming from Traefik, at whatever IP address the pod may have).
While I could rig some scripting magic to learn the IPs of the Traefik pods and continually update the vault config for the x_forwarded_for authorized address list, I really got to thinking about what I’d be accomplishing by doing so?
It’s a given that there’s no way from outside the cluster to get to the Vault pod except via Traefik (on the networking level). It’s a given that Vault has no way of knowing if the previous hop came from the L7 proxy (it only sees the L4 proxy socket). It’s a probability that any attack from inside the cluster would not gain anything by spoofing an IP via the X-Forwarded-For header (not definitely, but probably).
In this case, is there really any reason not to just set
x_forwarded_for_reject_not_authorized to false? Am I missing something?