Show HN: Kuberentes – The client source IP preservation dilemma
1–8 of 8 posts
Re: Show HN: Kuberentes – The client source IP preservation dilemma
#2I'm assuming this is not an HTTP setup then? In the HTTP world, setting X-Forwarded-For is usually enough.
Re: Show HN: Kuberentes – The client source IP preservation dilemma
#3I'm assuming this is not an HTTP setup then? In the HTTP world, setting X-Forwarded-For is usually enough.
Relying on X-Forward-For for... pretty much anything is not a security best practice. The user can easily manipulate this header.
Re: Show HN: Kuberentes – The client source IP preservation dilemma
#4I'm assuming this is not an HTTP setup then? In the HTTP world, setting X-Forwarded-For is usually enough.
Relying on X-Forward-For for... pretty much anything is not a security best practice. The user can easily manipulate this header.
Not only that but XFF only works with L7, the standard LB deployed via service type LB in Kubernetes is L4
Re: Show HN: Kuberentes – The client source IP preservation dilemma
#5I'm assuming this is not an HTTP setup then? In the HTTP world, setting X-Forwarded-For is usually enough.
Relying on X-Forward-For for... pretty much anything is not a security best practice. The user can easily manipulate this header.
AFAIK the common issue is software written or configured to read the header but deployed without a reverse proxy. If the load balancer is configured to set it, are there still security issues?
Re: Show HN: Kuberentes – The client source IP preservation dilemma
#6Earlier quoted context omitted.
Relying on X-Forward-For for... pretty much anything is not a security best practice. The user can easily manipulate this header.
AFAIK the common issue is software written or configured to read the header but deployed without a reverse proxy. If the load balancer is configured to set it, are there still security issues?
Depends, some load balancers may think they are behind another load balancer, and forward the header. This is default behavior iirc.
Re: Show HN: Kuberentes – The client source IP preservation dilemma
#7Earlier quoted context omitted.
Relying on X-Forward-For for... pretty much anything is not a security best practice. The user can easily manipulate this header.
AFAIK the common issue is software written or configured to read the header but deployed without a reverse proxy. If the load balancer is configured to set it, are there still security issues?
It isn't unknown for software to have problems in the OTHER direction with the Proxy header. Guzzle had this, where you could set a Proxy request header and all the curl requests would try to use the address you sent for it's calls.
Any header the user can set is always suspect.
We 'use' it when the ALB sets it for real-client-ip in nginx (while understanding that if something looks weird we should look at the full header). However a better solution is if your edge service sets (and protects, that's important) a header with the client IP to use that.
Cloudflare does this. Fastly does this as well, and I know Fastly protects it because I tested this specifically.
Cloudflare actually can set it in two different ways, however one of the ways is an upsell (only because it names it Real-Client-Ip which is apparently something set by other products, including Fastly). I was very amused when I got the Cloudflare rep to admit that.
Re: Show HN: Kuberentes – The client source IP preservation dilemma
#8Earlier quoted context omitted.
AFAIK the common issue is software written or configured to read the header but deployed without a reverse proxy. If the load balancer is configured to set it, are there still security issues?
Depends, some load balancers may think they are behind another load balancer, and forward the header. This is default behavior iirc.
A well behaving reverse proxy or load balancer would not cause security issues. The header contains both 'for' and 'by' parameters. If they are properly filled by the proxies, then it's not a security issue.
source: author of django-forwarded middleware, finds client IP from XFF header.