+1 to use-cases involving knox audit event analysis! On Thu, Jul 12, 2018 at 11:03 PM larry mccay <lmc...@apache.org> wrote:
> We may not know the original authentication account for all usecases. > Especially in cloud deployments where authentication events can be > federated in various ways. > > Yes, cross project work in the security space can bring some interesting > synergies. > > > On Thu, Jul 12, 2018, 3:39 PM Simon Elliston Ball < > si...@simonellistonball.com> wrote: > > > 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 > > >>> > > >> > > >
