Security Feature Branch?

[Simon Elliston Ball <si...@simonellistonball.com>]

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

Re: Security Feature Branch?

[Casey Stella <ce...@gmail.com>]

+1 to use-cases involving knox audit event analysis!

On Thu, Jul 12, 2018 at 11:03 PM larry mccay <lm...@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 <
> simon@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 <lm...@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 <ce...@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 <ottobackwards@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 (
> > >>> simon@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 <ot...@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 (
> > >>>> simon@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 <lm...@apache.org>]

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 <
simon@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 <lm...@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 <ce...@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 <ot...@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 (
> >>> simon@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 <ot...@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 (
> >>>> simon@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?

[Simon Elliston Ball <si...@simonellistonball.com>]

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 <lm...@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 <ce...@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 <ot...@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 (
>>> simon@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 <ot...@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 (
>>>> simon@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 <lm...@apache.org>]

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 <ce...@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 <ot...@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 (
> > simon@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 <ot...@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 (
> > > simon@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?

[Casey Stella <ce...@gmail.com>]

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 <ot...@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 (
> simon@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 <ot...@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 (
> > simon@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?

[Otto Fowler <ot...@gmail.com>]

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 (
simon@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 <ot...@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 (
> simon@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?

[Simon Elliston Ball <si...@simonellistonball.com>]

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 <ot...@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 (
> simon@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?

[Otto Fowler <ot...@gmail.com>]

A discussion thread on what you have come up with, the choices you made
would be warranted as well.


On July 12, 2018 at 11:00:47, Otto Fowler (ottobackwards@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 (
simon@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

Re: Security Feature Branch?

[Otto Fowler <ot...@gmail.com>]

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 (
simon@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

Re: Security Feature Branch?

[Justin Leet <ju...@gmail.com>]

+1 to feature branch. I agree it's probably a fairly hefty contribution
that would benefit from being in a feature branch.

On Thu, Jul 12, 2018 at 10:56 AM Casey Stella <ce...@gmail.com> wrote:

> I would support this being a feature branch.  It sounds like a valuable but
> large contribution.
>
> On Thu, Jul 12, 2018 at 10:51 AM Simon Elliston Ball <
> simon@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
> >
>

Re: Security Feature Branch?

[Casey Stella <ce...@gmail.com>]

I would support this being a feature branch.  It sounds like a valuable but
large contribution.

On Thu, Jul 12, 2018 at 10:51 AM Simon Elliston Ball <
simon@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
>