I am using a Nginx Ingress Controller in a Kubernetes Cluster. I've got an application within the cluster, which was available over the internet. Now I'm using the Ingress Controller to access the application, with the intent of showing some custom errors.
If i access the application (which is not written by myself, therefore I can't change things there), it receives the IP address of the nginx-ingress-controller-pod. The logs of the nginx-ingress-controller-pod indicate that the remote address is a different one.
I've already tried things like use-proxy-protocol, then I would be able to use $remote_addr and get the right IP. But as I mentioned I am not able to change my application, so I have to "trick" the ingress controller to use the $remote_addr as his own.
How can i configure the ingress, so the application will get the request from the remote IP and not from the nginx-ingress-controller-pod IP? Is there a way to do this?
Edit: I'm using a bare metal kubernetes installation with kubernetes v1.19.2 and the nginx chart ingress-nginx-3.29.0.
It could not achievable by using layer 7 ingress controller.
If Ingress preserves the source IP then response will got directly from the app pod to the client, so the client will get a response from a IP:port different from what he connected to. Or even worse - client's NAT drops the response completely because it doesn't match the existing connections.
You can take a look at this similar question on stackoverflow with accepted answer:
As ingress is above-layer-4 proxy. There is no way you can preserve SRC IP in layer 3 IP protocol. The best is and I think Nginx Ingress already been set by default that they put the "X-Forwarded-For" header in any HTTP forward. Your app supposes to log the X-Forwarded-For header
You can try to workaround by following this article. It could help you to preserve your IP.
I also recommend this very good article about load balancing and proxying. You will also learn a bit about load balancing on L7:
L7 load balancing and the OSI model As I said above in the section on L4 load balancing, using the OSI model for describing load balancing features is problematic. The reason is that L7, at least as described by the OSI model, itself encompasses multiple discrete layers of load balancing abstraction. e.g., for HTTP traffic consider the following sublayers:
- Optional Transport Layer Security (TLS). Note that networking people argue about which OSI layer TLS falls into. For the sake of this discussion we will consider TLS L7.
- Physical HTTP protocol (HTTP/1 or HTTP/2).
- Logical HTTP protocol (headers, body data, and trailers).
- Messaging protocol (gRPC, REST, etc.).