Closed f1ko closed 2 years ago
szuecs
commented
2 years ago Which features are obsolete by changing to a l4 load balancer in front of skipper? We run >95% of all the ingress/RouteGroup with a shared nlb in front. If you refer to Source* predicates then the next to use would be ClientIp in case you have ip preservation enabled at your l4 loadbalancer.
f1ko
commented
2 years ago Thanks for the quick response @szuecs .
Yes I was indeed referring to Source predicates. Another use-case may also be for a backend application to log the original source IP.
It seems as if I misunderstood the default setting of AWS NLB, sorry about that. Apparently by default it preserves the client IP which then obviously works as expected. However, if a client was to send a request through a proxy before reaching the NLB the above mentioned issue would still occur, correct? Other than that, using an L4 LB other than AWS NLB (e.g. HAProxy) would also cause the same problem as it does not have the client IP preservation setting that NLB has.
I guess both of these issues could be solved using proxy protocol which is currently not supported. Is there something else in place to work around those issues?
Sorry for the questionnaire, just wanted to make sure I fully understand skippers capabilities for different architectural patterns.
szuecs
commented
2 years ago Yes I was indeed referring to Source predicates. Another use-case may also be for a backend application to log the original source IP.
It seems as if I misunderstood the default setting of AWS NLB, sorry about that. Apparently by default it preserves the client IP which then obviously works as expected. However, if a client was to send a request through a proxy before reaching the NLB the above mentioned issue would still occur, correct?
Yes, you would see the proxy IP in skipper as connecting client. If you know there is a proxy, then either this is good to limit access through this proxy or it's bad because you don't see the client IP. On the other hand if you have a proxy, it will write XFF headers and then you can use Source/SourceFromLast predicates, depending on where the proxy write the connecting client IP to it.
Other than that, using an L4 LB other than AWS NLB (e.g. HAProxy) would also cause the same problem as it does not have the client IP preservation setting that NLB has.
In case haproxy does not write XFF headers yes. If it writes XFF headers you can use Source().
I guess both of these issues could be solved using proxy protocol which is currently not supported. Is there something else in place to work around those issues?
Proxy protocol would do an e2e connectivity, so we can't execute our routing nor our filters. It's possible to implement but I am not sure if it fits the idea.
Sorry for the questionnaire, just wanted to make sure I fully understand skippers capabilities for different architectural patterns.
Always welcome to ask!
Is your feature request related to a problem? Please describe. Due to a variety of reasons companies may have to use a layer 4 load balancer instead of a layer 7 in front of their Kubernetes cluster. Many of those will overwrite the original source IP with their own effectively making some of skippers features obsolete.
Describe the solution you would like This issue is more of a question then proposing a possible solution as different LBs have different features of avoiding this issue. One possibility (probably the most obvious one) would be to support proxy protocol as described in https://github.com/zalando/skipper/issues/1068 .
As I looked for similar issues I saw on several occasions that Zalando is planning on migrating from AWS ALB (layer 7) to NLB (layer 4) resulting in the above mentioned restriction. Will you simply not use the source IP functionality anymore or have ALB and NLB running in parallel for their distinctive usages?