[discuss] How to make nifi secure - or at least not insecure by default

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[discuss] How to make nifi secure - or at least not insecure by default

Joe Witt
Hello

Received a note today about this tweet:

https://twitter.com/silascutler/status/566983203232428033

It is a great reminder about our responsibility to provide secure software.

Out of the box NiFi starts up in a non-secure mode that is an HTTP
port to which anyone that can access it can command and control nifi
as an anonymous user.

We do provide configuration options for setting up proper HTTPS with
2-way SSL where the client's browser can establish trust in the
server, the server can establish trust in the client, the server can
establish the client identity by pulling the DN from the cert, and the
server can authorize the user for various roles based on a pluggable
authorization scheme.

The basic dilemma is how can we best balance out of the box usability
and approach-ability with security.

Ideas I'd propose:
1) In the UI provide a constant (and annoying in nature) reminder of a
non-secure config
2) Emphasize documentation, tooling, etc.. that makes it easy as
possible for users to establish secure configurations.
3) Add support for other identity mechanisms (like what?)

If folks have ideas on what the right balance is please share.  What
we have now doesn't seem like the right answer and feels irresponsible
knowing that folks will not secure their instances properly.

Thanks
Joe
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] How to make nifi secure - or at least not insecure by default

Mike Drob-2
Inline.

On Sun, Feb 15, 2015 at 12:10 PM, Joe Witt <[hidden email]> wrote:

> Hello
>
> Received a note today about this tweet:
>
> https://twitter.com/silascutler/status/566983203232428033
>
> It is a great reminder about our responsibility to provide secure software.
>
> Out of the box NiFi starts up in a non-secure mode that is an HTTP
> port to which anyone that can access it can command and control nifi
> as an anonymous user.
>
> We do provide configuration options for setting up proper HTTPS with
> 2-way SSL where the client's browser can establish trust in the
> server, the server can establish trust in the client, the server can
> establish the client identity by pulling the DN from the cert, and the
> server can authorize the user for various roles based on a pluggable
> authorization scheme.
>
> The basic dilemma is how can we best balance out of the box usability
> and approach-ability with security.
>
> Ideas I'd propose:
> 1) In the UI provide a constant (and annoying in nature) reminder of a
> non-secure config
>
Sure.

2) Emphasize documentation, tooling, etc.. that makes it easy as
> possible for users to establish secure configurations.
>
Be careful what you bite off here. Off-loading to existing tools is a great
way to keep your developers sane.

3) Add support for other identity mechanisms (like what?)
>
Kerberos? AD?

>
> If folks have ideas on what the right balance is please share.  What
> we have now doesn't seem like the right answer and feels irresponsible
> knowing that folks will not secure their instances properly.
>
> Thanks
> Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] How to make nifi secure - or at least not insecure by default

Dan Bress
Joe,
   I think this is a really good idea.

   I think you could solve 1 and 2 by providing an annoying-ish banner/icon that reminds you that you are running in an insecure mode, that when clicked takes you to the (to-be-completed) section of the admin guide.

Dan Bress
Software Engineer
ONYX Consulting Services

________________________________________
From: Mike Drob <[hidden email]>
Sent: Sunday, February 15, 2015 9:08 PM
To: [hidden email]
Subject: Re: [discuss] How to make nifi secure - or at least not insecure by default

Inline.

On Sun, Feb 15, 2015 at 12:10 PM, Joe Witt <[hidden email]> wrote:

> Hello
>
> Received a note today about this tweet:
>
> https://twitter.com/silascutler/status/566983203232428033
>
> It is a great reminder about our responsibility to provide secure software.
>
> Out of the box NiFi starts up in a non-secure mode that is an HTTP
> port to which anyone that can access it can command and control nifi
> as an anonymous user.
>
> We do provide configuration options for setting up proper HTTPS with
> 2-way SSL where the client's browser can establish trust in the
> server, the server can establish trust in the client, the server can
> establish the client identity by pulling the DN from the cert, and the
> server can authorize the user for various roles based on a pluggable
> authorization scheme.
>
> The basic dilemma is how can we best balance out of the box usability
> and approach-ability with security.
>
> Ideas I'd propose:
> 1) In the UI provide a constant (and annoying in nature) reminder of a
> non-secure config
>
Sure.

2) Emphasize documentation, tooling, etc.. that makes it easy as
> possible for users to establish secure configurations.
>
Be careful what you bite off here. Off-loading to existing tools is a great
way to keep your developers sane.

3) Add support for other identity mechanisms (like what?)
>
Kerberos? AD?

>
> If folks have ideas on what the right balance is please share.  What
> we have now doesn't seem like the right answer and feels irresponsible
> knowing that folks will not secure their instances properly.
>
> Thanks
> Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] How to make nifi secure - or at least not insecure by default

Corey Flowers
I like the idea of the annoying banner. You could place it in the bar, near the area surrounding the "refresh" text for graph control or even take it a step further and add an indicator on the graph for secure or not, similar to the lock on site-to-site connections.

Sent from my iPhone

> On Feb 16, 2015, at 8:44 AM, Daniel Bress <[hidden email]> wrote:
>
> Joe,
>   I think this is a really good idea.
>
>   I think you could solve 1 and 2 by providing an annoying-ish banner/icon that reminds you that you are running in an insecure mode, that when clicked takes you to the (to-be-completed) section of the admin guide.
>
> Dan Bress
> Software Engineer
> ONYX Consulting Services
>
> ________________________________________
> From: Mike Drob <[hidden email]>
> Sent: Sunday, February 15, 2015 9:08 PM
> To: [hidden email]
> Subject: Re: [discuss] How to make nifi secure - or at least not insecure by default
>
> Inline.
>
>> On Sun, Feb 15, 2015 at 12:10 PM, Joe Witt <[hidden email]> wrote:
>>
>> Hello
>>
>> Received a note today about this tweet:
>>
>> https://twitter.com/silascutler/status/566983203232428033
>>
>> It is a great reminder about our responsibility to provide secure software.
>>
>> Out of the box NiFi starts up in a non-secure mode that is an HTTP
>> port to which anyone that can access it can command and control nifi
>> as an anonymous user.
>>
>> We do provide configuration options for setting up proper HTTPS with
>> 2-way SSL where the client's browser can establish trust in the
>> server, the server can establish trust in the client, the server can
>> establish the client identity by pulling the DN from the cert, and the
>> server can authorize the user for various roles based on a pluggable
>> authorization scheme.
>>
>> The basic dilemma is how can we best balance out of the box usability
>> and approach-ability with security.
>>
>> Ideas I'd propose:
>> 1) In the UI provide a constant (and annoying in nature) reminder of a
>> non-secure config
> Sure.
>
> 2) Emphasize documentation, tooling, etc.. that makes it easy as
>> possible for users to establish secure configurations.
> Be careful what you bite off here. Off-loading to existing tools is a great
> way to keep your developers sane.
>
> 3) Add support for other identity mechanisms (like what?)
> Kerberos? AD?
>
>>
>> If folks have ideas on what the right balance is please share.  What
>> we have now doesn't seem like the right answer and feels irresponsible
>> knowing that folks will not secure their instances properly.
>>
>> Thanks
>> Joe
>>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] How to make nifi secure - or at least not insecure by default

Aldrin Piri
I think Mike's mention about the tangential work that arises is very
important to remember.  Accordingly, the following means of a secure
environment is provided more for consideration of how one project solved
this than a suggestion explicitly for NiFi.

I like what boot2docker uses where they opt for secure by default, but
provide the guide for people to change that should they explicitly choose
to put the effort into that process.

From their documentation [1]:

> TLS support
>
> By default, boot2docker runs docker with TLS enabled. It auto-generates
> certificates and stores them in /home/docker/.docker inside the VM. The boot2docker
> up command will copy them to ~/.boot2docker/certs on the host machine
> once the VM has started, and output the correct values for the
> DOCKER_CERT_PATH and DOCKER_TLS_VERIFY environment variables.
>
> $(boot2docker shellinit) will also set them correctly.
>
> We strongly recommend against running Boot2Docker with an unencrypted
> Docker socket for security reasons, but if you have tools that cannot be
> easily switched, you can disable it by adding DOCKER_TLS=no to your
> /var/lib/boot2docker/profile file on the persistent partition inside the
> Boot2Docker virtual machine (use boot2docker ssh sudo vi
> /var/lib/boot2docker/profile).
>
The analog is that NiFi would generate the associated certificates and
configuration if secure properties aren't explicitly defined in the
properties via the bootstrapping portion of the startup process. The part
that makes me hesitant to consider this are the varied environments that
NiFi can run in and the tools needed for each environment.  boot2docker
benefits from having a custom image that has the needed tools to perform
this auto-generation that is identical.  One path could be to leverage
something like Bouncy Castle in a utility that creates these, but again,
becomes another development effort and item to maintain.

[1] https://github.com/boot2docker/boot2docker/blob/master/README.md

On Mon, Feb 16, 2015 at 10:09 AM, Corey Flowers <[hidden email]>
wrote:

> I like the idea of the annoying banner. You could place it in the bar,
> near the area surrounding the "refresh" text for graph control or even take
> it a step further and add an indicator on the graph for secure or not,
> similar to the lock on site-to-site connections.
>
> Sent from my iPhone
>
> > On Feb 16, 2015, at 8:44 AM, Daniel Bress <[hidden email]>
> wrote:
> >
> > Joe,
> >   I think this is a really good idea.
> >
> >   I think you could solve 1 and 2 by providing an annoying-ish
> banner/icon that reminds you that you are running in an insecure mode, that
> when clicked takes you to the (to-be-completed) section of the admin guide.
> >
> > Dan Bress
> > Software Engineer
> > ONYX Consulting Services
> >
> > ________________________________________
> > From: Mike Drob <[hidden email]>
> > Sent: Sunday, February 15, 2015 9:08 PM
> > To: [hidden email]
> > Subject: Re: [discuss] How to make nifi secure - or at least not
> insecure by default
> >
> > Inline.
> >
> >> On Sun, Feb 15, 2015 at 12:10 PM, Joe Witt <[hidden email]> wrote:
> >>
> >> Hello
> >>
> >> Received a note today about this tweet:
> >>
> >> https://twitter.com/silascutler/status/566983203232428033
> >>
> >> It is a great reminder about our responsibility to provide secure
> software.
> >>
> >> Out of the box NiFi starts up in a non-secure mode that is an HTTP
> >> port to which anyone that can access it can command and control nifi
> >> as an anonymous user.
> >>
> >> We do provide configuration options for setting up proper HTTPS with
> >> 2-way SSL where the client's browser can establish trust in the
> >> server, the server can establish trust in the client, the server can
> >> establish the client identity by pulling the DN from the cert, and the
> >> server can authorize the user for various roles based on a pluggable
> >> authorization scheme.
> >>
> >> The basic dilemma is how can we best balance out of the box usability
> >> and approach-ability with security.
> >>
> >> Ideas I'd propose:
> >> 1) In the UI provide a constant (and annoying in nature) reminder of a
> >> non-secure config
> > Sure.
> >
> > 2) Emphasize documentation, tooling, etc.. that makes it easy as
> >> possible for users to establish secure configurations.
> > Be careful what you bite off here. Off-loading to existing tools is a
> great
> > way to keep your developers sane.
> >
> > 3) Add support for other identity mechanisms (like what?)
> > Kerberos? AD?
> >
> >>
> >> If folks have ideas on what the right balance is please share.  What
> >> we have now doesn't seem like the right answer and feels irresponsible
> >> knowing that folks will not secure their instances properly.
> >>
> >> Thanks
> >> Joe
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] How to make nifi secure - or at least not insecure by default

Joey Echeverria-2
I'm not a fan of tools auto-generating certificates. It only provides
partial security and it encourages bad habits like blindly accepting
untrusted certificates in your browser and other tools.

In general, organizations have established ways of issuing and managing
certificates and it's better to integrate with those methods rather than
trying to add too much tooling in NiFi itself for a NiFi only solution.

Other security features are easier to enable by default, like requiring
authentication based on a file-based username/password database while
providing a warning with a link to the security admin guide, as has been
suggested earlier in the thread.

On Mon Feb 16 2015 at 7:53:36 AM Aldrin Piri <[hidden email]> wrote:

> I think Mike's mention about the tangential work that arises is very
> important to remember.  Accordingly, the following means of a secure
> environment is provided more for consideration of how one project solved
> this than a suggestion explicitly for NiFi.
>
> I like what boot2docker uses where they opt for secure by default, but
> provide the guide for people to change that should they explicitly choose
> to put the effort into that process.
>
> From their documentation [1]:
>
> > TLS support
> >
> > By default, boot2docker runs docker with TLS enabled. It auto-generates
> > certificates and stores them in /home/docker/.docker inside the VM. The
> boot2docker
> > up command will copy them to ~/.boot2docker/certs on the host machine
> > once the VM has started, and output the correct values for the
> > DOCKER_CERT_PATH and DOCKER_TLS_VERIFY environment variables.
> >
> > $(boot2docker shellinit) will also set them correctly.
> >
> > We strongly recommend against running Boot2Docker with an unencrypted
> > Docker socket for security reasons, but if you have tools that cannot be
> > easily switched, you can disable it by adding DOCKER_TLS=no to your
> > /var/lib/boot2docker/profile file on the persistent partition inside the
> > Boot2Docker virtual machine (use boot2docker ssh sudo vi
> > /var/lib/boot2docker/profile).
> >
> The analog is that NiFi would generate the associated certificates and
> configuration if secure properties aren't explicitly defined in the
> properties via the bootstrapping portion of the startup process. The part
> that makes me hesitant to consider this are the varied environments that
> NiFi can run in and the tools needed for each environment.  boot2docker
> benefits from having a custom image that has the needed tools to perform
> this auto-generation that is identical.  One path could be to leverage
> something like Bouncy Castle in a utility that creates these, but again,
> becomes another development effort and item to maintain.
>
> [1] https://github.com/boot2docker/boot2docker/blob/master/README.md
>
> On Mon, Feb 16, 2015 at 10:09 AM, Corey Flowers <[hidden email]>
> wrote:
>
> > I like the idea of the annoying banner. You could place it in the bar,
> > near the area surrounding the "refresh" text for graph control or even
> take
> > it a step further and add an indicator on the graph for secure or not,
> > similar to the lock on site-to-site connections.
> >
> > Sent from my iPhone
> >
> > > On Feb 16, 2015, at 8:44 AM, Daniel Bress <[hidden email]>
> > wrote:
> > >
> > > Joe,
> > >   I think this is a really good idea.
> > >
> > >   I think you could solve 1 and 2 by providing an annoying-ish
> > banner/icon that reminds you that you are running in an insecure mode,
> that
> > when clicked takes you to the (to-be-completed) section of the admin
> guide.
> > >
> > > Dan Bress
> > > Software Engineer
> > > ONYX Consulting Services
> > >
> > > ________________________________________
> > > From: Mike Drob <[hidden email]>
> > > Sent: Sunday, February 15, 2015 9:08 PM
> > > To: [hidden email]
> > > Subject: Re: [discuss] How to make nifi secure - or at least not
> > insecure by default
> > >
> > > Inline.
> > >
> > >> On Sun, Feb 15, 2015 at 12:10 PM, Joe Witt <[hidden email]>
> wrote:
> > >>
> > >> Hello
> > >>
> > >> Received a note today about this tweet:
> > >>
> > >> https://twitter.com/silascutler/status/566983203232428033
> > >>
> > >> It is a great reminder about our responsibility to provide secure
> > software.
> > >>
> > >> Out of the box NiFi starts up in a non-secure mode that is an HTTP
> > >> port to which anyone that can access it can command and control nifi
> > >> as an anonymous user.
> > >>
> > >> We do provide configuration options for setting up proper HTTPS with
> > >> 2-way SSL where the client's browser can establish trust in the
> > >> server, the server can establish trust in the client, the server can
> > >> establish the client identity by pulling the DN from the cert, and the
> > >> server can authorize the user for various roles based on a pluggable
> > >> authorization scheme.
> > >>
> > >> The basic dilemma is how can we best balance out of the box usability
> > >> and approach-ability with security.
> > >>
> > >> Ideas I'd propose:
> > >> 1) In the UI provide a constant (and annoying in nature) reminder of a
> > >> non-secure config
> > > Sure.
> > >
> > > 2) Emphasize documentation, tooling, etc.. that makes it easy as
> > >> possible for users to establish secure configurations.
> > > Be careful what you bite off here. Off-loading to existing tools is a
> > great
> > > way to keep your developers sane.
> > >
> > > 3) Add support for other identity mechanisms (like what?)
> > > Kerberos? AD?
> > >
> > >>
> > >> If folks have ideas on what the right balance is please share.  What
> > >> we have now doesn't seem like the right answer and feels irresponsible
> > >> knowing that folks will not secure their instances properly.
> > >>
> > >> Thanks
> > >> Joe
> > >>
> >
>