Re: Knox SSO feature branch PRs: a quick demo

[larry mccay]

Hi Simon -

I like how you walk through those various PRs and describe what is done at
each step.
Please feel free sure to bring any suggestions that you may have for
improvements in Knox and KnoxSSO to the community.
The public cert issue is a pain for sure - we do have a knoxcli command for
exporting it but you need to be on the Knox machine to do that.
I've been considering add an API to the admin API for retrieving it as well
- but of course it will need to be up and running for that.

thanks,

--larry


On Wed, Aug 1, 2018 at 11:34 PM, Simon Elliston Ball <
si...@simonellistonball.com> wrote:

> I've recently put in a number of PRs on the Knox feature branch, and
> thought it might be useful to post a quick 'sprint demo' style explanation
> of what the various PRs and functionality entails:
> https://youtu.be/9OJz6hg0N1I
>
> Hope this helps with review process. There are a couple of areas where that
> need a little follow on improvement (Ambari mpack cosmetic oddness mainly).
> Any thoughts and assistance on that would be very greatly appreciated.
>
> Simon
>

Re: Security Feature Branch?

[larry mccay]

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  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 
> 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 
> >> 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 
> 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
> >>>
> >>
>

Re: Security Feature Branch?

[larry mccay]

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  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 
> 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  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
> >
>

Re: [DISCUSS] Community Meetings

[larry mccay]

Not sure about posting the recordings - you will need to check and make
sure that doesn't violate anything.

Just a friendly reminder...
It is important that meetings have notes and a summary that is sent out
describing topics to be decided on the mailing list.
No decisions can be made in the community meeting itself - this gives
others in other timezones and commitments review and voice in the decisions.

If it didn't happen on the mailing lists then it didn't happen. :)


On Tue, Dec 12, 2017 at 1:39 PM, Simon Elliston Ball <
si...@simonellistonball.com> wrote:

> Yes, I do.
>
> I suspect the best bet will be to post recordings somewhere on the
> apache.org  metron site.
>
> Simon
>
> > On 12 Dec 2017, at 18:36, Otto Fowler  wrote:
> >
> > Excellent, do you have the > 40 min + record option?
> >
> >
> > On December 12, 2017 at 13:19:55, Simon Elliston Ball (
> > si...@simonellistonball.com) wrote:
> >
> > Happy to volunteer a zoom room. That seems to have worked for most in the
> > past.
> >
> > Simon
> >
> >> On 12 Dec 2017, at 18:09, Otto Fowler  wrote:
> >>
> >> Thanks! I think I’d like something hosted though.
> >>
> >>
> >> On December 12, 2017 at 11:18:52, Ahmed Shah (
> ahmeds...@cmail.carleton.ca)
> >
> >> wrote:
> >>
> >> Hello,
> >>
> >> wrt "- How are we going to host it"...
> >>
> >> I've used BigBlueButton as an end user at our University.
> >>
> >> It is LGPL open source.
> >>
> >> https://bigbluebutton.org/
> >> https://bigbluebutton.org/developers/
> >>
> >>
> >> -Ahmed
> >>
> >> ___
> >> Ahmed Shah (PMP, M. Eng.)
> >> Cybersecurity Analyst & Developer
> >> GCR - Cybersecurity Operations Center
> >> Carleton University - cugcr.com
> >>
> >>
> >> 
> >> From: Otto Fowler 
> >> Sent: December 11, 2017 4:41 PM
> >> To: dev@metron.apache.org
> >> Subject: [DISCUSS] Community Meetings
> >>
> >> I think that we all want to have regular community meetings. We may be
> >> better able to keep to a regular schedule with these meetings if we
> > spread
> >> out the responsibility for them from James and Casey, both of whom have
> a
> >> lot on their plate already.
> >>
> >> I would be willing to coordinate and run the meetings, and would welcome
> >> anyone else who wants to help when they can.
> >>
> >> The only issue for me is I do not have a web-ex account that I can use
> to
> >> hold the meeting. So I’ll need some recommendations for a suitable
> >> alternative. I have not been able to find an Apache Friendly
> alternative,
> >> in the same way that Atlassian is apache friendly.
> >>
> >>
> >> So - from what I can see we need to:
> >>
> >> - Talk through who is going to do it
> >> - How are we going to host it
> >> - When are we going to do it
> >>
> >> Anything else?
> >>
> >> ottO
>
>

Re: [APACHE COMMITER QUESTION] PR’s from organization’s as opposed to ‘people’

[larry mccay]

Interesting question.
I share your concern there and think it would be reasonable to ask for it
to be re-contributed by an individual.
Preferably, such that an Apache account can have it assigned to them.

However, I haven't switched Apache Knox to accepting PR's yet and not sure
what others do here.

On Thu, Nov 2, 2017 at 9:50 AM, Otto Fowler  wrote:

> I have reviewed and approved https://github.com/apache/metron/pull/822,
> but
> I’m not sure about committing it.
> The submitter is an organizational github account, not a ‘person’.  There
> is no way to verify the submitter, no email etc at the moment.
>
> How should this be handled?
>

Re: So we graduated...

[larry mccay]

Wonderful news and well deserved!
This community has embraced and committed to the Apache way so quickly.


On Thu, Apr 20, 2017 at 5:39 PM, Kyle Richardson 
wrote:

> That's awesome! Congratulations everyone. Looking forward to the official
> announcement on Monday.
>
> -Kyle
>
> > On Apr 20, 2017, at 5:15 PM, David Lyle  wrote:
> >
> > Outstanding! Great work everyone. Building a TLP worthy community is
> > difficult and worthy work, congratulations all!
> >
> > -D...
> >
> >> On Thu, Apr 20, 2017 at 5:12 PM, Casey Stella 
> wrote:
> >>
> >> For anyone paying attention to incubator-general, it will come as no
> >> surprise that we graduated as of last night's board meeting.  We have a
> >> press released queued up and planned for monday along with a PR
> (METRON-687
> >> at https://github.com/apache/incubator-metron/pull/539).
> >>
> >> It escaped my notice that the graduation was talked about on
> >> incubator-general; otherwise I'd have sent this email earlier and been
> less
> >> cagey in 687's description.  Even so, I'd like to ask that everyone
> keep it
> >> to themselves until monday morning after the press release gets out the
> >> door.  I know the cat is out of the bag, but it'd be nice to have a bit
> of
> >> an embargo.
> >>
> >> Thanks!
> >>
> >> Casey
> >>
>