-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Only proxy whitelisted request headers to ES server upstream #6896
Conversation
I checked this out, it works, everything looks good, except for 1 thing. I think we need to be using a header whitelist instead of a blacklist like this is done currently. Additionally, that whitelist should be modifiable via the kibana.yml file, and then this PR can also close #6221 Seems like everyone else is in agreement on that, so I'm going to ask you to update this PR. As for passing in a default whitelist, the theory goes that the only header that we might need to forward is |
@w33ble I've updated the PR to use a whitelist approach as we discussed on Zoom and you summarized in your comment above. Using the default whitelist (no headers), here's what I see with Wireshark, going from the Kibana server to Elasticsearch: I've also confirmed that the issue in #6484 goes away (because |
With the configurable request header whitelist in place, this PR probably also resolves #6221, pending discussion on whether the default whitelist should be empty (as currently implemented by this PR) or contain certain headers (like |
return header.trim().toLowerCase(); | ||
}); | ||
|
||
return _.pick(originalHeaders, headersToKeepNormalized); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if originalHeaders
will always come back lower-case or not. I think it's probably best to normalize them as well when filtering the list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Fixing.
Security doesn't work without the Setting the config value makes it all work though:
|
@@ -61,6 +61,11 @@ | |||
# must be a positive integer. | |||
# elasticsearch.requestTimeout: 30000 | |||
|
|||
# List of Kibana client-side headers to send to Elasticsearch. To send *no* client-side | |||
# headers, set this value to nothing/blank (i.e. elasticsearch.requestHeadersWhitelist: ) | |||
# or the empty list (i.e. elasticsearch.requestHeadersWhitelist: []) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's give only one option for this: empty array []
. Is there any situation where offering an alternative would be beneficial?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not particularly. I think as a user its intuitive for blank values to mean nothing (in addition to []
also meaning list with nothing in it) so I documented the alternative. I'm happy to only document the []
option (even though the blank would still work but might be less confusing to the user if we don't actually document it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If nothing else, for consistency sake I think we should stick to []
. I'm sure there are other configurations in kibana.yml that technically would allow an empty value, but we don't advertise it as such. Your call though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me. I'll document only []
here.
@epixa I've made the changes you suggested and this is ready for review again. Thanks! |
LGTM |
Labeling this as a breaking change because, after this change, we pass (by default) fewer headers upstream to Elasticsearch. So if there's an HTTP intermediary between Kibana and Elasticsearch relying on certain headers, they might break. |
`eui@83.0.0` ⏩ `83.1.0` --- ## [`83.1.0`](https://github.com/elastic/eui/tree/v83.1.0) - Added `placeholder` prop to `EuiInlineEdit` ([#6883](elastic/eui#6883)) - Added `sparkles` glyph to `EuiIcon` ([#6898](elastic/eui#6898)) **Bug fixes** - Fixed Safari-only bug for single-line row `EuiDataGrid`s, where cell actions on hover would overlap instead of pushing content to the left ([#6881](elastic/eui#6881)) - Fixed `EuiButton` not correctly merging in passed `className`s with its base `.euiButton` class ([#6887](elastic/eui#6887)) - Fixed `EuiIcon` not correctly passing the `style` prop custom `img` icons ([#6888](elastic/eui#6888)) - Fixed multiple components with child props (e.g. `buttonProps`, `iconProps`, etc.) unsetting EUI's Emotion styling if custom `css` was passed to the child props object ([#6896](elastic/eui#6896)) **CSS-in-JS conversions** - Converted `EuiHeader` and `EuiHeaderLogo` to Emotion ([#6878](elastic/eui#6878)) - Removed Sass variables `$euiHeaderDarkBackgroundColor`, `$euiHeaderBorderColor`, and `$euiHeaderBreadcrumbColor` ([#6878](elastic/eui#6878)) - Removed Sass mixin `@euiHeaderDarkTheme` ([#6878](elastic/eui#6878))
Fixes #6484.
Besides the unit test included in this PR, I've tested this fix functionally in a couple of different ways:
http.cors.enabled: true
in the Elasticsearch config via esvm. Kibana loads up as expected.Origin
header in the request that is sent to Elasticsearch: