It certainly might make for an interesting automated response if metron sent alerts to Knox to block IPs for example, or users in the case of strange behavior (though I wonder if that would generally be done upstream in the authentication source, e.g. blocking an AD account).
Pushing Knox audit events to Metron would also provide an interesting data source for things like brute force detection, or strange access patterns. I’ve seen people doing similar things with Ranger. So far the only real issue I’ve seen with Knox itself is replacing certificates. I was hoping to do that by providing a blueprint setting in Ambari with a proper cert, but that’s probably a question for dev@ambari. Great to see so many projects working together! Simon > On 12 Jul 2018, at 17:10, larry mccay <lmc...@apache.org> wrote: > > Glad to see this work being done! > Please feel free to reach out to Knox dev@ list for any assistance and > potentially review. > > Only sort of related, I have been thinking about another integration > between Knox and Metron wherein possible threat details can be communicated > to Knox to take action on at authentication/authorization time. > Knox could also potentially push interesting events like possible brute > force login attempts to Metron. > Some bi-directional pub-sub model? > > Thoughts? > >> On Thu, Jul 12, 2018 at 11:57 AM, Casey Stella <ceste...@gmail.com> wrote: >> >> I added the feature branch: feature/METRON-1663-knoxsso >> >> https://git-wip-us.apache.org/repos/asf?p=metron.git;a= >> shortlog;h=refs/heads/feature/METRON-1663-knoxsso >> >> On Thu, Jul 12, 2018 at 11:13 AM Otto Fowler <ottobackwa...@gmail.com> >> wrote: >> >>> I think I understand what you are saying very very very well Simon. I am >>> not sure what would be different about your submittal from other >> submittals >>> where that argument failed. >>> >>> On July 12, 2018 at 11:07:02, Simon Elliston Ball ( >>> si...@simonellistonball.com) wrote: >>> >>> Agreed Otto, the challenge is that essentially each change cuts across >>> dependencies in every component. I could break it down into the changes >> for >>> making SSO work, and the changes for making it install, and the changes >> for >>> making full-dev work, but that would mean violating our policy that >> testing >>> should be done for each PR on full dev, hence the one PR one unit >> approach. >>> Does that work, or do we want to review on the basis of a series of >>> untestable bits, and then a final working build PR that pulls it >> together? >>> >>> Simon >>> >>>> On 12 July 2018 at 16:00, Otto Fowler <ottobackwa...@gmail.com> wrote: >>>> >>>> Our policy in the past on such things is to require that they are >> broken >>>> into small reviewable chunks on a feature branch, even if the end to >> end >>>> working version was more ‘usable’. >>>> >>>> >>>> >>>> On July 12, 2018 at 10:51:30, Simon Elliston Ball ( >>>> si...@simonellistonball.com) wrote: >>>> >>>> I've been doing some work on getting the Metron UIs and REST layers to >>> work >>>> with Apache KnoxSSO, and LDAP authentication, to remove the need to >> store >>>> passwords in MySQL, allow AD integration, secure up our authentication >>>> points. I'm also working in a Knox service to allow the gateway to >>> provide >>>> full SSL for the interfaces and avoid all the proxying and CORS things >> we >>>> have to worry about. >>>> >>>> This has ended up being a pretty chunky piece of work which involves >> very >>>> significant changes to the UIs, REST layer, and introduces Knox to the >>>> blueprint, as well as messing with the full-dev build scripts, and >> adding >>>> ansible roles. >>>> >>>> As such, in-order to make it a bit more reviewable, would it be better >> to >>>> contribute it to a feature branch? It could arguably be broken into a >>>> series of PRs, but at least some parts of full dev would be broken >>> between >>>> most of the logical steps, since it's all kinda co-dependent, so it's >>>> easier to look at as a unit. >>>> >>>> Simon >>>> >>>> >>> >>> >>> -- >>> -- >>> simon elliston ball >>> @sireb >>> >>
