trusted_ips

[Luiz Omori]

I'm looking into how Kong handles the X-Forwarded-For header and its impact on hardware load balancers, like F5. I saw that 0.11.0rc1 has a new configuration, trusted_ips, which is supposed to control who can be trusted as providers of X-Forwarded-For.

I've executed the following call from my laptop:

curl -v https://<server>/httpbin/get?show_env=1 -H "X-Forwarded-For: 10.85.66.18"

...and got

    "X-Forwarded-For": "10.85.66.18, 172.17.0.1, 152.16.191.116",

My trusted_ips is empty and Kong is running inside a Docker container

10.85.66.18 -> coming from the original request. That happens to be my true local IP, but I tried putting anything in there with the same results.

172.17.0.1 -> Docker bridge?

152.16.191.116 -> my external IP

A couple of questions:

1. With an empty trusted_ips configuration, shouldn't Kong have ignored the incoming X-Forwarded-For header?

2. How did Kong figured out there was another bridge, in this case Docker, in front of it? It makes sense, but what is the general logic here?

Regards,

Luiz

[rpap...@fearnothingproductions.net]

Hi,

On Thursday, June 29, 2017 at 12:37:58 PM UTC-7, Luiz Omori wrote:

I'm looking into how Kong handles the X-Forwarded-For header and its impact on hardware load balancers, like F5. I saw that 0.11.0rc1 has a new configuration, trusted_ips, which is supposed to control who can be trusted as providers of X-Forwarded-For. 

...

A couple of questions:

1. With an empty trusted_ips configuration, shouldn't Kong have ignored the incoming X-Forwarded-For header?

The trusted_ips directive  defines how Kong uses the Nginx `set_real_ip_from` directive. This doesn't mean that Kong ignores the X-Forwarded-For header (this is simply an HTTP header that Kong will pass through as a reverse proxy); it means that Kong will not treat the value of the X-Forwarded-For header as the connecting client IP (used by the `$remote_addr` and friends variables).

The idea of 'trust' here is that Kong should not assume that the value in the X-Forwarded-For header is a legitimate value (never trust clients, remember? ;) ). This is why the Nginx `set_real_ip_from` directives exist (which is what the Kong trusted_ips directive wraps), so that the underlying Nginx module can know when it should use the value of X-Forwarded-For, and when it should be ignored. This doesn't have any impact on the _value_ of the X-Forwarded-For header, but rather, it only changes whether or not Kong respects it as useful information.

 

2. How did Kong figured out there was another bridge, in this case Docker, in front of it? It makes sense, but what is the general logic here?

Kong will pass along an X-Forwarded-For header to the upstream in a few possible ways:

- If the downstream connection contains an X-Forwarded-For header, Kong will append the client's IP to the comma-separated list of IPs in this header based on the value of the `$realip_remote_addr` (see http://nginx.org/en/docs/http/ngx_http_realip_module.html#variables for a definition)

- If no X-Forwarded-For request header is seen, Kong will define the request X-Forwarded-For header as the value of `$realip_remote_addr`.

In your case, your docker bridge likely appended the IP that was connecting to it to the existing X-F-F header, just as Kong does.

HTH