New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow configuring Forwarded/X-Forwarded-* headers #134
Allow configuring Forwarded/X-Forwarded-* headers #134
Conversation
Forwarded
/X-Forwarded-*
headers/
X-Forwarded-* headers
/
X-Forwarded-* headersImplement the ROUTER_SET_FORWARDED_HEADERS environment variable and haproxy.router.openshift.io/set-forwarded-headers route annotation. The annotation takes precedence over the environment variable. The environment variable and annotation may specify any of the following values to control when HAProxy sets the Forwarded and X-Forwarded-* headers: * "append" to append to existing headers. * "replace" to replace existing headers. * "if-none" to set the headers if they are absent. * "never" to never set headers. The default setting is "append". This commit is related to NE-343. https://issues.redhat.com/browse/NE-343 * images/router/haproxy/conf/haproxy-config.template: Add a new variable, setForwardedHeadersPattern, with a regular expression that matches the values listed above. Add a new variable, setForwardedHeadersAnnotation, with the new annotation. Add a new variable, setForwardedHeadersDefaultValue, with value of ROUTER_SET_FORWARDED_HEADERS if specified or else the default value "append". Use these variables to control when the Forwarded and X-Forwarded-* headers are set for the backend.
Delete the "Add x-forwarded-for header." comment that was added in <openshift/origin@d74ebe6>. * images/router/haproxy/conf/haproxy-config.template: Delete comment.
be00278
to
447fe9f
Compare
🚀 |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Miciah, sgreene570 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Please review the full test history for this PR and help us cut down flakes. |
8 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
@Miciah: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
@Miciah, I'm curious about this implementation behavior for X-Forwarded-Host/Port/Proto and Since append doesn't make sense for these headers (they can only have one value), Wouldn't it be better if |
I'm not sure that's true: Why couldn't an intermediate proxy could modify the host, port, or protocol?
Could you provide an example scenario where appending would be the wrong thing to do? Unfortunately the |
These headers are meant to preserve the values that are sent from the client's originating request. There may be layers of load balancers between a client and the downstream server that handles a request, and this server relies on these headers to know the values sent by the client. References:
So imagine the following:
When receiving requests, this app wants to know what protocol/port a client uses to connect to this endpoint. It can know this by looking at the X-Forwarded-Proto/Port headers passed to it from upstream systems, but this is only true if all upstream systems preserve these values passed by the client. In this router implementation, the load balancer will pass "X-Forwarded-Proto: https, X-Forwarded-Port: 443", but the router will overwrite these headers with "X-Forwarded-Proto: http, X-Forwarded-Port: 80", losing the real values passed by the originating client to the public-facing endpoint, so the application won't know if the client is actually connecting over HTTP or HTTPS. Instead, if the router preserved these headers, the app would receive "X-Forwarded-Proto: https, X-Forwarded-Port: 443" and know that the client connected to the public-facing endpoint via HTTPS:443. You might say that we should use the mode |
These references contradict each other in various small ways, which reinforces my point that these headers are non-standard and that implementations are inconsistent. MDN mentions several variants of
The router only replaces the header values if the policy is set to "replace". Granted, in your example, the server would need to use the first value of each header; it wouldn't work properly with the "append" policy if the server used the last value. Is that the concern?
What would be a reasonable way to approach this? Change the behavior of "append" to append only |
Great points. MDN calls these headers "de-facto standard", i.e. not an official standard but a common practice. The official standard
This is true for
Great question. First off, are we in agreement that "append" doesn't apply to X-Forwarded-Host/Port/Proto? Specifically it applies to So "append" currently means:
I think a better and less surprising behavior would be:
I may be short-sighted here, but I don't think anyone will want the current If you really don't want to change the current behavior, though, could we perhaps split "append" into 2 policies?
|
Hey @Miciah , any thoughts on the changes I suggested above? |
Allow configuring
Forwarded
/X-Forwarded-*
headersImplement the
ROUTER_SET_FORWARDED_HEADERS
environment variable andhaproxy.router.openshift.io/set-forwarded-headers
route annotation. The annotation takes precedence over the environment variable. The environment variable and annotation may specify any of the following values to control when HAProxy sets theForwarded
andX-Forwarded-*
headers:append
to append to existing headers.replace
to replace existing headers.if-none
to set the headers if they are absent.never
to never set headers.The default setting is
append
.images/router/haproxy/conf/haproxy-config.template
: Add a new variable,setForwardedHeadersPattern
, with a regular expression that matches the values listed above. Add a new variable,setForwardedHeadersDefaultValue
, with value ofROUTER_SET_FORWARDED_HEADERS
if specified or else the default valueappend
. Use these variables to control when theForwarded
andX-Forwarded-*
headers are set for the backend.This change is related to NE-343.
Delete stray comment in
haproxy-config.template
Delete the "Add x-forwarded-for header." comment that was added in openshift/origin@d74ebe6.
images/router/haproxy/conf/haproxy-config.template
: Delete comment.