Describe the bug
Starting from the default configurations, there seems to have no way to activate the proxy protocol feature in order to pass the real client IPs in headers to the application server.
To Reproduce
apiVersion: v1
data:
use-proxy-protocol: "true"
kind: ConfigMap
metadata:
name: quickstart-nginx-ingress
kubectl annotate service quickstart-nginx-ingress service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol=true
Expected behavior
Doing curl --header "Host: client.mytesthostname.com" http://[load-balancer-ip]/ should resolve the request and provide real IP in HTTP headers.
Your environment
Latest
1.18.6
Digital Ocean
NGINX
Additional context
Note that using the same procedure, BUT with the following repo works successfully:
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm install nginx-ingress stable/nginx-ingress
Is there a certain configuration which needs to be changed when using helm repo add nginx-stable https://helm.nginx.com/stable, or is there a certain issue I am missing?
Thanks
Hi @martinlevesque
Firstly, just because it's a common confusion.
Please note that:
helm install nginx-ingress stable/nginx-ingress installs https://github.com/kubernetes/ingress-nginxhelm install quickstart nginx-stable/nginx-ingress installs https://github.com/nginxinc/kubernetes-ingressThese are two different implementation of an ingress controller. The supported annotations and configmap entries differ.
The equivalent configmap entry to use-proxy-protocol seems to be proxy-protocol.
See the following example for more details:
https://github.com/nginxinc/kubernetes-ingress/tree/v1.8.0/examples/proxy-protocol
Oh wow, thanks for pointing out this distinction. I understand they are different implementation, but it would have been great the have the same API/variables. Or perhaps, if you enter an invalid config variable, it would have been great to throw an explicit error in my opinion - in this case I would have been notified clearly that use-proxy-protocol is not correct.
it would have been great to throw an explicit error in my opinion - in this case I would have been notified clearly that use-proxy-protocol is not correct.
@martinlevesque I'm not sure why we haven't gotten around to adding a feature like that, I think it would be useful and it's a common misunderstanding.