Skip to content

Conversation

@spinscale
Copy link
Contributor

@spinscale spinscale commented Dec 19, 2018

This adds a configurable whitelist to the HTTP client in watcher. By
default it allows everything is does not, but there is a dynamically
configurable setting named "xpack.http.hosts.whitelist" that allows to
configure an array of urls, which can also contain simple regexes.

TODO:

  • fix the code TODO and cast properly, this was a two hour prototype so might more serve as a discussion base instead of being merged
  • Is a blacklist needed on top of a whitelist? No
  • Should we block certain things by default as mentioned in the issue? Not for now
  • Should we always whitelist slack/hipchat/pagerduty or allow to block this as well and tell the user he should whitelist it manually?
  • Add documentation

Closes #29937

This adds a configurable whitelist to the HTTP client in watcher. By
default it allows everything is does not, but there is a dynamically
configurable setting named "xpack.http.hosts.whitelist" that allows to
configure an array of hosts, which can also contain simple regexes.

TODO:
- Should we match against a host list or really against URLs? Right now
you cannot filter http vs https which might be quite the feature
- fix the code TODO and cast properly
- Is a blacklist needed on top of a whitelist?
- Should we block certain things by default as mentioned in the issue?

Closes elastic#29937
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@jakelandis
Copy link
Contributor

Should we match against a host list or really against URLs? Right now
you cannot filter http vs https which might be quite the feature

I think we should support the full URI and not just the host. Some large organizations do path based routing over dns for operational reasons (shared wildcard certs, SSO, etc), and they may to limit access to specific paths within a company's host. I think we should also support a URL with our with the http(s)://, for usability. w/r/t http vs. https allowance, I think this should be a standalone setting allow_insecure_http (or the like) and work towards making false the default.

Is a blacklist needed on top of a whitelist?

I don't think so. More of a personal opinion then anything ... but I have found when having both it is harder to understand which one to configure and how the precedence works for anything but the trivial case.

Should we block certain things by default as mentioned in the issue?

I think this gets tricky to get right and can lead to a false sense of increased security by providing these defaults. However, I think it may help, but the real answer is to require a white list.

@spinscale
Copy link
Contributor Author

I changed the setting to be an URL like https://hooks.slack.com/messages*, this also simplified the code. There are a few todo's left, which I'd work on if the rest makes sense.. (plus documentation)

@spinscale
Copy link
Contributor Author

spinscale commented Jan 9, 2019

Removed the always whitelisting feature for slack/PD/pagerduty. If someone is using this feature, they could easily add the respective endpoints themselves. Documentation was added. TODOs were removed.

I think this is ready for a first review.

Jake: I intentionally did not introduce another allow_insecure_http parameter, as this can all be solved with the existing one. And if someone wants to add http based URLs, so be it.

@spinscale spinscale removed the WIP label Jan 9, 2019
Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

}
}

public void testToStringDoesNotContainAuthorizationheader() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice fix right here :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++

Copy link
Contributor

@jakelandis jakelandis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a question and a couple nit picks, but LGTM as-is

}
}

public void testToStringDoesNotContainAuthorizationheader() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++

@spinscale
Copy link
Contributor Author

@elasticmachine retest this please

@spinscale
Copy link
Contributor Author

applied all the requests changes. I also changed the setting from xpack.http.hosts.whitelist to xpack.http.whitelist as we are no longer whitelisting hosts. There is also no need to introduce this hierarchy.

@jakelandis
Copy link
Contributor

still LGTM

@hub-cap
Copy link
Contributor

hub-cap commented Jan 10, 2019

still LGTM

same

@spinscale spinscale merged commit bbd0930 into elastic:master Jan 11, 2019
@jimczi jimczi added v7.0.0-beta1 and removed v7.0.0 labels Feb 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Watcher: Add URL whitelist

5 participants