Re: [discuss] we need to enable secure by default...
Hi, Agreed that NiFi should be secure by default, or at the very least not completely open for direct abuse. Although I understand the hesitation of requiring a secure startup can be overwhelming for new users or inconvenient for those who just want to “test” out NiFi - given the powerful capabilities of NiFi it seems reasonable to impose some level of authentication or restriction. This is where I believe really good documentation of clear, obvious, to-the-point instructions to secure NiFi would ease this process. This can include written documentation/images/screenshots. I even like Nathan’s suggestion of a YouTube/video tutorial for a wider scope of different learning preferences. Personally, when I encounter something I don’t know how to do in NiFi, the most helpful resources have been the short, step-by-step guides online - such as Pierre Villard’s blog, Bryan Bende's blog, and Andrew Lim’s walk-through videos. Whatever we decide on, whether complicated or not, I think having very clear instructions will alleviate barrier issues for all levels of users. Thanks, Margot > On Feb 10, 2021, at 10:14 AM, Joe Witt wrote: > > Nathan just commented on the Jira about an obvious first step being to > restrict HTTP to localhost only by default. This is an easy and > immediately doable first step. I am planning to wait for the RC4 creation > for that PR to land and get merged. > > Thanks > > On Wed, Feb 10, 2021 at 10:24 AM Nathan Gough wrote: > >> I 100% agree that something needs to be done. We cannot allow NiFi to build >> a reputation that it is 'insecure' by allowing its default installation to >> start up without any security. Especially considering how much work we put >> in to make sure it IS a secure product that integrates with many >> applications in a secure way. Security reputation is very important for >> software. If some major exploitation of NiFi were to happen in the future, >> we should be able to confidently say that we did our absolute best to >> create a secure application. We shouldn't point at new users and say 'they >> didn't configure it right'. >> >> Personally, I am in favor of providing automatically generated certificates >> and requiring the user to insert the client certificate in their browser, >> and providing instructions and perhaps a YouTube video on how to do that. >> Yes, X509 certificate errors are confusing and can be difficult for >> beginners to troubleshoot. But those beginner users will also be the most >> likely to use NiFi insecurely, connect it to the internet, and become part >> of a user base who got burnt by NiFi being 'insecure'. I acknowledge this >> is increasing the barrier for entry. If we intend to use a >> username/password + server cert for HTTPs but no client cert, as stated >> above we could automatically generate the password and provide this to the >> user in a log or file. >> >> >> On Wed, Feb 10, 2021 at 12:21 PM David Handermann < >> exceptionfact...@gmail.com> wrote: >> >>> Integrating an option to use Let's Encrypt would be a great improvement >>> over self-signed certificates, but it is difficult to support that for >>> instances of NiFi running on servers without Internet access. Even when >>> running NiFi for local development purposes, the development system is >> not >>> likely to have a publicly addressable DNS name, so Let's Encrypt is not >> an >>> option in those cases. >>> >>> Regards, >>> David Handermann >>> >>> On Wed, Feb 10, 2021 at 11:09 AM Joe Witt wrote: >>> Otto Installers like you mention are inherently brutal for portability so >> very difficult for us in the community. From the vendor world we of course >> do things like that. I think in apache nifi land we need a default 'even >>> for devs' which is not wide open. James I do think adding such a warning is good. But it doesn't help avoid >>> these wildly abusive cases. We need a secure by default path. We can >> probably do better than the self signed path if we add a 'before running' step >> in the CLI for the user. Not sure. Thanks On Wed, Feb 10, 2021 at 10:05 AM James Srinivasan < james.sriniva...@gmail.com> wrote: > Would a suitably large warning on the http ui be a good starting >> point? > > Browsers are getting increasingly wary of self signed certs and we probably > don't want to be encouraging people to ignore them. > > What about easier acme+certbot support? (notwithstanding all the non public > deployments) > > On Wed, 10 Feb 2021, 15:25 Otto Fowler, >>> wrote: > >> Aren’t most of these applications installed by an installer? >> Maybe we can have one or more installers that setup a secure >>> instance, > and >> those installers >> could be the *production* nifi, and keep the zip distribution open >>> for >> developers? >> >> >>>
Re: [discuss] we need to enable secure by default...
Joey We need to move to a model where NiFi comes with *nothing* by default and all items are sourced as needed when someone tries to put them in a flow or wants to create a deployable bundle. That gives them better control and us a much better community management experience. Smaller and more frequent and targeted releases. Thanks On Wed, Feb 10, 2021 at 11:44 AM Joey Frazee wrote: > This is probably a very important and overdue change. > > I think it’s important to recognize that there’s a lot of different ways > to unintentionally end up with a publicly accessible application and it > can’t always be pinned to one person or role. Routing, firewall rules, OS > admin, NiFi admin aren’t always the same people. > > I like the idea of the localhost change. > > I’d also be in favor of a making build profiles for opting in to some of > the more dangerous restricted processors, or delivering the binaries for > those separately. > > This exploit allows people to run a reverse shell and it probably doesn’t > stop on the NiFi host, so good Internet citizenship sort of says something > must be done. > > -joey > > > On Feb 10, 2021, at 10:14 AM, Joe Witt wrote: > > > > Nathan just commented on the Jira about an obvious first step being to > > restrict HTTP to localhost only by default. This is an easy and > > immediately doable first step. I am planning to wait for the RC4 > creation > > for that PR to land and get merged. > > > > Thanks > > > >> On Wed, Feb 10, 2021 at 10:24 AM Nathan Gough > wrote: > >> > >> I 100% agree that something needs to be done. We cannot allow NiFi to > build > >> a reputation that it is 'insecure' by allowing its default installation > to > >> start up without any security. Especially considering how much work we > put > >> in to make sure it IS a secure product that integrates with many > >> applications in a secure way. Security reputation is very important for > >> software. If some major exploitation of NiFi were to happen in the > future, > >> we should be able to confidently say that we did our absolute best to > >> create a secure application. We shouldn't point at new users and say > 'they > >> didn't configure it right'. > >> > >> Personally, I am in favor of providing automatically generated > certificates > >> and requiring the user to insert the client certificate in their > browser, > >> and providing instructions and perhaps a YouTube video on how to do > that. > >> Yes, X509 certificate errors are confusing and can be difficult for > >> beginners to troubleshoot. But those beginner users will also be the > most > >> likely to use NiFi insecurely, connect it to the internet, and become > part > >> of a user base who got burnt by NiFi being 'insecure'. I acknowledge > this > >> is increasing the barrier for entry. If we intend to use a > >> username/password + server cert for HTTPs but no client cert, as stated > >> above we could automatically generate the password and provide this to > the > >> user in a log or file. > >> > >> > >> On Wed, Feb 10, 2021 at 12:21 PM David Handermann < > >> exceptionfact...@gmail.com> wrote: > >> > >>> Integrating an option to use Let's Encrypt would be a great improvement > >>> over self-signed certificates, but it is difficult to support that for > >>> instances of NiFi running on servers without Internet access. Even > when > >>> running NiFi for local development purposes, the development system is > >> not > >>> likely to have a publicly addressable DNS name, so Let's Encrypt is not > >> an > >>> option in those cases. > >>> > >>> Regards, > >>> David Handermann > >>> > On Wed, Feb 10, 2021 at 11:09 AM Joe Witt wrote: > >>> > Otto > > Installers like you mention are inherently brutal for portability so > >> very > difficult for us in the community. From the vendor world we of course > >> do > things like that. I think in apache nifi land we need a default 'even > >>> for > devs' which is not wide open. > > James > > I do think adding such a warning is good. But it doesn't help avoid > >>> these > wildly abusive cases. We need a secure by default path. We can > >> probably > do better than the self signed path if we add a 'before running' step > >> in > the CLI for the user. Not sure. > > Thanks > > On Wed, Feb 10, 2021 at 10:05 AM James Srinivasan < > james.sriniva...@gmail.com> wrote: > > > Would a suitably large warning on the http ui be a good starting > >> point? > > > > Browsers are getting increasingly wary of self signed certs and we > probably > > don't want to be encouraging people to ignore them. > > > > What about easier acme+certbot support? (notwithstanding all the non > public > > deployments) > > > > On Wed, 10 Feb 2021, 15:25 Otto Fowler, > >>> wrote: > > > >> Aren’t most of these applications installed by an installer? > >> Maybe we can have one
Re: [discuss] we need to enable secure by default...
This is probably a very important and overdue change. I think it’s important to recognize that there’s a lot of different ways to unintentionally end up with a publicly accessible application and it can’t always be pinned to one person or role. Routing, firewall rules, OS admin, NiFi admin aren’t always the same people. I like the idea of the localhost change. I’d also be in favor of a making build profiles for opting in to some of the more dangerous restricted processors, or delivering the binaries for those separately. This exploit allows people to run a reverse shell and it probably doesn’t stop on the NiFi host, so good Internet citizenship sort of says something must be done. -joey > On Feb 10, 2021, at 10:14 AM, Joe Witt wrote: > > Nathan just commented on the Jira about an obvious first step being to > restrict HTTP to localhost only by default. This is an easy and > immediately doable first step. I am planning to wait for the RC4 creation > for that PR to land and get merged. > > Thanks > >> On Wed, Feb 10, 2021 at 10:24 AM Nathan Gough wrote: >> >> I 100% agree that something needs to be done. We cannot allow NiFi to build >> a reputation that it is 'insecure' by allowing its default installation to >> start up without any security. Especially considering how much work we put >> in to make sure it IS a secure product that integrates with many >> applications in a secure way. Security reputation is very important for >> software. If some major exploitation of NiFi were to happen in the future, >> we should be able to confidently say that we did our absolute best to >> create a secure application. We shouldn't point at new users and say 'they >> didn't configure it right'. >> >> Personally, I am in favor of providing automatically generated certificates >> and requiring the user to insert the client certificate in their browser, >> and providing instructions and perhaps a YouTube video on how to do that. >> Yes, X509 certificate errors are confusing and can be difficult for >> beginners to troubleshoot. But those beginner users will also be the most >> likely to use NiFi insecurely, connect it to the internet, and become part >> of a user base who got burnt by NiFi being 'insecure'. I acknowledge this >> is increasing the barrier for entry. If we intend to use a >> username/password + server cert for HTTPs but no client cert, as stated >> above we could automatically generate the password and provide this to the >> user in a log or file. >> >> >> On Wed, Feb 10, 2021 at 12:21 PM David Handermann < >> exceptionfact...@gmail.com> wrote: >> >>> Integrating an option to use Let's Encrypt would be a great improvement >>> over self-signed certificates, but it is difficult to support that for >>> instances of NiFi running on servers without Internet access. Even when >>> running NiFi for local development purposes, the development system is >> not >>> likely to have a publicly addressable DNS name, so Let's Encrypt is not >> an >>> option in those cases. >>> >>> Regards, >>> David Handermann >>> On Wed, Feb 10, 2021 at 11:09 AM Joe Witt wrote: >>> Otto Installers like you mention are inherently brutal for portability so >> very difficult for us in the community. From the vendor world we of course >> do things like that. I think in apache nifi land we need a default 'even >>> for devs' which is not wide open. James I do think adding such a warning is good. But it doesn't help avoid >>> these wildly abusive cases. We need a secure by default path. We can >> probably do better than the self signed path if we add a 'before running' step >> in the CLI for the user. Not sure. Thanks On Wed, Feb 10, 2021 at 10:05 AM James Srinivasan < james.sriniva...@gmail.com> wrote: > Would a suitably large warning on the http ui be a good starting >> point? > > Browsers are getting increasingly wary of self signed certs and we probably > don't want to be encouraging people to ignore them. > > What about easier acme+certbot support? (notwithstanding all the non public > deployments) > > On Wed, 10 Feb 2021, 15:25 Otto Fowler, >>> wrote: > >> Aren’t most of these applications installed by an installer? >> Maybe we can have one or more installers that setup a secure >>> instance, > and >> those installers >> could be the *production* nifi, and keep the zip distribution open >>> for >> developers? >> >> >>> On Feb 10, 2021, at 10:04, David Handermann < > exceptionfact...@gmail.com> >> wrote: >>> >>> I agree that a generated password is the way to go, and the >>> challenge > is >>> making it available to the user. Depending on how it is stored >> for the >>> identity provider, having a command line tool to read and print >> it > could >> be >>> a
Re: [discuss] we need to enable secure by default...
Nathan just commented on the Jira about an obvious first step being to restrict HTTP to localhost only by default. This is an easy and immediately doable first step. I am planning to wait for the RC4 creation for that PR to land and get merged. Thanks On Wed, Feb 10, 2021 at 10:24 AM Nathan Gough wrote: > I 100% agree that something needs to be done. We cannot allow NiFi to build > a reputation that it is 'insecure' by allowing its default installation to > start up without any security. Especially considering how much work we put > in to make sure it IS a secure product that integrates with many > applications in a secure way. Security reputation is very important for > software. If some major exploitation of NiFi were to happen in the future, > we should be able to confidently say that we did our absolute best to > create a secure application. We shouldn't point at new users and say 'they > didn't configure it right'. > > Personally, I am in favor of providing automatically generated certificates > and requiring the user to insert the client certificate in their browser, > and providing instructions and perhaps a YouTube video on how to do that. > Yes, X509 certificate errors are confusing and can be difficult for > beginners to troubleshoot. But those beginner users will also be the most > likely to use NiFi insecurely, connect it to the internet, and become part > of a user base who got burnt by NiFi being 'insecure'. I acknowledge this > is increasing the barrier for entry. If we intend to use a > username/password + server cert for HTTPs but no client cert, as stated > above we could automatically generate the password and provide this to the > user in a log or file. > > > On Wed, Feb 10, 2021 at 12:21 PM David Handermann < > exceptionfact...@gmail.com> wrote: > > > Integrating an option to use Let's Encrypt would be a great improvement > > over self-signed certificates, but it is difficult to support that for > > instances of NiFi running on servers without Internet access. Even when > > running NiFi for local development purposes, the development system is > not > > likely to have a publicly addressable DNS name, so Let's Encrypt is not > an > > option in those cases. > > > > Regards, > > David Handermann > > > > On Wed, Feb 10, 2021 at 11:09 AM Joe Witt wrote: > > > > > Otto > > > > > > Installers like you mention are inherently brutal for portability so > very > > > difficult for us in the community. From the vendor world we of course > do > > > things like that. I think in apache nifi land we need a default 'even > > for > > > devs' which is not wide open. > > > > > > James > > > > > > I do think adding such a warning is good. But it doesn't help avoid > > these > > > wildly abusive cases. We need a secure by default path. We can > probably > > > do better than the self signed path if we add a 'before running' step > in > > > the CLI for the user. Not sure. > > > > > > Thanks > > > > > > On Wed, Feb 10, 2021 at 10:05 AM James Srinivasan < > > > james.sriniva...@gmail.com> wrote: > > > > > > > Would a suitably large warning on the http ui be a good starting > point? > > > > > > > > Browsers are getting increasingly wary of self signed certs and we > > > probably > > > > don't want to be encouraging people to ignore them. > > > > > > > > What about easier acme+certbot support? (notwithstanding all the non > > > public > > > > deployments) > > > > > > > > On Wed, 10 Feb 2021, 15:25 Otto Fowler, > > wrote: > > > > > > > > > Aren’t most of these applications installed by an installer? > > > > > Maybe we can have one or more installers that setup a secure > > instance, > > > > and > > > > > those installers > > > > > could be the *production* nifi, and keep the zip distribution open > > for > > > > > developers? > > > > > > > > > > > > > > > > On Feb 10, 2021, at 10:04, David Handermann < > > > > exceptionfact...@gmail.com> > > > > > wrote: > > > > > > > > > > > > I agree that a generated password is the way to go, and the > > challenge > > > > is > > > > > > making it available to the user. Depending on how it is stored > for > > > the > > > > > > identity provider, having a command line tool to read and print > it > > > > could > > > > > be > > > > > > a reasonable option. > > > > > > > > > > > > Although this particular thread referenced a specific Twitter > post, > > > > this > > > > > > general discussion is more of a reflection of the need to make > > things > > > > > more > > > > > > secure by default as other products have followed similar > > approaches. > > > > > > > > > > > > Regards, > > > > > > David Handermann > > > > > > > > > > > > On Wed, Feb 10, 2021 at 8:53 AM Kevin Doran > > > wrote: > > > > > > > > > > > >> I am in favor of requiring some authentication by default. > > > > > >> > > > > > >> I’m in favor of an admin username and generated password. (It > > sounds > > > > > li9ke > > > > > >> most of us are on the same page, but I don’t think a static, > > default
Re: [discuss] we need to enable secure by default...
I 100% agree that something needs to be done. We cannot allow NiFi to build a reputation that it is 'insecure' by allowing its default installation to start up without any security. Especially considering how much work we put in to make sure it IS a secure product that integrates with many applications in a secure way. Security reputation is very important for software. If some major exploitation of NiFi were to happen in the future, we should be able to confidently say that we did our absolute best to create a secure application. We shouldn't point at new users and say 'they didn't configure it right'. Personally, I am in favor of providing automatically generated certificates and requiring the user to insert the client certificate in their browser, and providing instructions and perhaps a YouTube video on how to do that. Yes, X509 certificate errors are confusing and can be difficult for beginners to troubleshoot. But those beginner users will also be the most likely to use NiFi insecurely, connect it to the internet, and become part of a user base who got burnt by NiFi being 'insecure'. I acknowledge this is increasing the barrier for entry. If we intend to use a username/password + server cert for HTTPs but no client cert, as stated above we could automatically generate the password and provide this to the user in a log or file. On Wed, Feb 10, 2021 at 12:21 PM David Handermann < exceptionfact...@gmail.com> wrote: > Integrating an option to use Let's Encrypt would be a great improvement > over self-signed certificates, but it is difficult to support that for > instances of NiFi running on servers without Internet access. Even when > running NiFi for local development purposes, the development system is not > likely to have a publicly addressable DNS name, so Let's Encrypt is not an > option in those cases. > > Regards, > David Handermann > > On Wed, Feb 10, 2021 at 11:09 AM Joe Witt wrote: > > > Otto > > > > Installers like you mention are inherently brutal for portability so very > > difficult for us in the community. From the vendor world we of course do > > things like that. I think in apache nifi land we need a default 'even > for > > devs' which is not wide open. > > > > James > > > > I do think adding such a warning is good. But it doesn't help avoid > these > > wildly abusive cases. We need a secure by default path. We can probably > > do better than the self signed path if we add a 'before running' step in > > the CLI for the user. Not sure. > > > > Thanks > > > > On Wed, Feb 10, 2021 at 10:05 AM James Srinivasan < > > james.sriniva...@gmail.com> wrote: > > > > > Would a suitably large warning on the http ui be a good starting point? > > > > > > Browsers are getting increasingly wary of self signed certs and we > > probably > > > don't want to be encouraging people to ignore them. > > > > > > What about easier acme+certbot support? (notwithstanding all the non > > public > > > deployments) > > > > > > On Wed, 10 Feb 2021, 15:25 Otto Fowler, > wrote: > > > > > > > Aren’t most of these applications installed by an installer? > > > > Maybe we can have one or more installers that setup a secure > instance, > > > and > > > > those installers > > > > could be the *production* nifi, and keep the zip distribution open > for > > > > developers? > > > > > > > > > > > > > On Feb 10, 2021, at 10:04, David Handermann < > > > exceptionfact...@gmail.com> > > > > wrote: > > > > > > > > > > I agree that a generated password is the way to go, and the > challenge > > > is > > > > > making it available to the user. Depending on how it is stored for > > the > > > > > identity provider, having a command line tool to read and print it > > > could > > > > be > > > > > a reasonable option. > > > > > > > > > > Although this particular thread referenced a specific Twitter post, > > > this > > > > > general discussion is more of a reflection of the need to make > things > > > > more > > > > > secure by default as other products have followed similar > approaches. > > > > > > > > > > Regards, > > > > > David Handermann > > > > > > > > > > On Wed, Feb 10, 2021 at 8:53 AM Kevin Doran > > wrote: > > > > > > > > > >> I am in favor of requiring some authentication by default. > > > > >> > > > > >> I’m in favor of an admin username and generated password. (It > sounds > > > > li9ke > > > > >> most of us are on the same page, but I don’t think a static, > default > > > > >> password buys us much against the types of abuse shown on the > > twitter > > > > >> thread Joe shared.) > > > > >> > > > > >> We need some way of making the generated password discoverable… > > Print > > > to > > > > >> the logs on first boot? Not great but are there other mechanisms? > A > > > > setup > > > > >> CLI utility? > > > > >> > > > > >> To help not impede automated deployments, maybe we should change > the > > > > >> startup flow such that there is a way to provide this password. > That > > > > would > > > > >> be better than people
Re: [discuss] we need to enable secure by default...
Integrating an option to use Let's Encrypt would be a great improvement over self-signed certificates, but it is difficult to support that for instances of NiFi running on servers without Internet access. Even when running NiFi for local development purposes, the development system is not likely to have a publicly addressable DNS name, so Let's Encrypt is not an option in those cases. Regards, David Handermann On Wed, Feb 10, 2021 at 11:09 AM Joe Witt wrote: > Otto > > Installers like you mention are inherently brutal for portability so very > difficult for us in the community. From the vendor world we of course do > things like that. I think in apache nifi land we need a default 'even for > devs' which is not wide open. > > James > > I do think adding such a warning is good. But it doesn't help avoid these > wildly abusive cases. We need a secure by default path. We can probably > do better than the self signed path if we add a 'before running' step in > the CLI for the user. Not sure. > > Thanks > > On Wed, Feb 10, 2021 at 10:05 AM James Srinivasan < > james.sriniva...@gmail.com> wrote: > > > Would a suitably large warning on the http ui be a good starting point? > > > > Browsers are getting increasingly wary of self signed certs and we > probably > > don't want to be encouraging people to ignore them. > > > > What about easier acme+certbot support? (notwithstanding all the non > public > > deployments) > > > > On Wed, 10 Feb 2021, 15:25 Otto Fowler, wrote: > > > > > Aren’t most of these applications installed by an installer? > > > Maybe we can have one or more installers that setup a secure instance, > > and > > > those installers > > > could be the *production* nifi, and keep the zip distribution open for > > > developers? > > > > > > > > > > On Feb 10, 2021, at 10:04, David Handermann < > > exceptionfact...@gmail.com> > > > wrote: > > > > > > > > I agree that a generated password is the way to go, and the challenge > > is > > > > making it available to the user. Depending on how it is stored for > the > > > > identity provider, having a command line tool to read and print it > > could > > > be > > > > a reasonable option. > > > > > > > > Although this particular thread referenced a specific Twitter post, > > this > > > > general discussion is more of a reflection of the need to make things > > > more > > > > secure by default as other products have followed similar approaches. > > > > > > > > Regards, > > > > David Handermann > > > > > > > > On Wed, Feb 10, 2021 at 8:53 AM Kevin Doran > wrote: > > > > > > > >> I am in favor of requiring some authentication by default. > > > >> > > > >> I’m in favor of an admin username and generated password. (It sounds > > > li9ke > > > >> most of us are on the same page, but I don’t think a static, default > > > >> password buys us much against the types of abuse shown on the > twitter > > > >> thread Joe shared.) > > > >> > > > >> We need some way of making the generated password discoverable… > Print > > to > > > >> the logs on first boot? Not great but are there other mechanisms? A > > > setup > > > >> CLI utility? > > > >> > > > >> To help not impede automated deployments, maybe we should change the > > > >> startup flow such that there is a way to provide this password. That > > > would > > > >> be better than people just disabling whatever default authentication > > we > > > set. > > > >> > > > >> > > > >>> On Feb 10, 2021, at 09:45, David Handermann < > > > exceptionfact...@gmail.com> > > > >> wrote: > > > >>> > > > >>> Mark, > > > >>> > > > >>> Thanks for clarifying, that makes sense. > > > >>> > > > >>> Regards, > > > >>> David Handermann > > > >>> > > > >>> On Wed, Feb 10, 2021 at 8:41 AM Mark Payne > > > wrote: > > > >>> > > > David, > > > > > > My concern was purely around generating client certs and using > > mutual > > > >> TLS. > > > I definitely think we should have a server cert if using username > & > > > password. > > > > > > Thanks > > > -Mark > > > > > > > > > > On Feb 10, 2021, at 9:37 AM, David Handermann < > > > exceptionfact...@gmail.com> wrote: > > > > > > > > Mark, > > > > > > > > Thanks for your perspective on certificate generation, I agree > that > > > > troubleshooting certificates can be confusing due to unclear > error > > > > messaging. Generating self-signed certificates for one-way TLS > > still > > > > requires the user to accept the certificate presented, but at > least > > > >> that > > > is > > > > more common in various products. Are you concerned about that > > > >> situation, > > > > or are you more concerned about the additional challenges of > mutual > > > TLS > > > > authentication? > > > > > > > > Generating a random password in absence of any other > configuration > > > >> would > > > > certainly be easier from a new user perspective. Some of the > > > security > > > > concerns
Re: [discuss] we need to enable secure by default...
Otto Installers like you mention are inherently brutal for portability so very difficult for us in the community. From the vendor world we of course do things like that. I think in apache nifi land we need a default 'even for devs' which is not wide open. James I do think adding such a warning is good. But it doesn't help avoid these wildly abusive cases. We need a secure by default path. We can probably do better than the self signed path if we add a 'before running' step in the CLI for the user. Not sure. Thanks On Wed, Feb 10, 2021 at 10:05 AM James Srinivasan < james.sriniva...@gmail.com> wrote: > Would a suitably large warning on the http ui be a good starting point? > > Browsers are getting increasingly wary of self signed certs and we probably > don't want to be encouraging people to ignore them. > > What about easier acme+certbot support? (notwithstanding all the non public > deployments) > > On Wed, 10 Feb 2021, 15:25 Otto Fowler, wrote: > > > Aren’t most of these applications installed by an installer? > > Maybe we can have one or more installers that setup a secure instance, > and > > those installers > > could be the *production* nifi, and keep the zip distribution open for > > developers? > > > > > > > On Feb 10, 2021, at 10:04, David Handermann < > exceptionfact...@gmail.com> > > wrote: > > > > > > I agree that a generated password is the way to go, and the challenge > is > > > making it available to the user. Depending on how it is stored for the > > > identity provider, having a command line tool to read and print it > could > > be > > > a reasonable option. > > > > > > Although this particular thread referenced a specific Twitter post, > this > > > general discussion is more of a reflection of the need to make things > > more > > > secure by default as other products have followed similar approaches. > > > > > > Regards, > > > David Handermann > > > > > > On Wed, Feb 10, 2021 at 8:53 AM Kevin Doran wrote: > > > > > >> I am in favor of requiring some authentication by default. > > >> > > >> I’m in favor of an admin username and generated password. (It sounds > > li9ke > > >> most of us are on the same page, but I don’t think a static, default > > >> password buys us much against the types of abuse shown on the twitter > > >> thread Joe shared.) > > >> > > >> We need some way of making the generated password discoverable… Print > to > > >> the logs on first boot? Not great but are there other mechanisms? A > > setup > > >> CLI utility? > > >> > > >> To help not impede automated deployments, maybe we should change the > > >> startup flow such that there is a way to provide this password. That > > would > > >> be better than people just disabling whatever default authentication > we > > set. > > >> > > >> > > >>> On Feb 10, 2021, at 09:45, David Handermann < > > exceptionfact...@gmail.com> > > >> wrote: > > >>> > > >>> Mark, > > >>> > > >>> Thanks for clarifying, that makes sense. > > >>> > > >>> Regards, > > >>> David Handermann > > >>> > > >>> On Wed, Feb 10, 2021 at 8:41 AM Mark Payne > > wrote: > > >>> > > David, > > > > My concern was purely around generating client certs and using > mutual > > >> TLS. > > I definitely think we should have a server cert if using username & > > password. > > > > Thanks > > -Mark > > > > > > > On Feb 10, 2021, at 9:37 AM, David Handermann < > > exceptionfact...@gmail.com> wrote: > > > > > > Mark, > > > > > > Thanks for your perspective on certificate generation, I agree that > > > troubleshooting certificates can be confusing due to unclear error > > > messaging. Generating self-signed certificates for one-way TLS > still > > > requires the user to accept the certificate presented, but at least > > >> that > > is > > > more common in various products. Are you concerned about that > > >> situation, > > > or are you more concerned about the additional challenges of mutual > > TLS > > > authentication? > > > > > > Generating a random password in absence of any other configuration > > >> would > > > certainly be easier from a new user perspective. Some of the > > security > > > concerns with password authentication can be mitigated with one-way > > >> TLS, > > so > > > a blending of these approaches, as Joe describes in NIFI-8220, > seems > > like a > > > good way to go. > > > > > > Regards, > > > David Handermann > > > > > > On Wed, Feb 10, 2021 at 8:23 AM Mark Payne > > >> wrote: > > > > > >> I would be in favor of this as well. I agree that there is no need > > to > > wait > > >> for a 2.0 version - there is no inherit backward compatibility > > >> challenge > > >> here. > > >> Requiring that new application configs be set, etc. I think is > > completely > > >> fair game between minor versions. > > >> > > >> Personally, though, I would very
Re: [discuss] we need to enable secure by default...
Would a suitably large warning on the http ui be a good starting point? Browsers are getting increasingly wary of self signed certs and we probably don't want to be encouraging people to ignore them. What about easier acme+certbot support? (notwithstanding all the non public deployments) On Wed, 10 Feb 2021, 15:25 Otto Fowler, wrote: > Aren’t most of these applications installed by an installer? > Maybe we can have one or more installers that setup a secure instance, and > those installers > could be the *production* nifi, and keep the zip distribution open for > developers? > > > > On Feb 10, 2021, at 10:04, David Handermann > wrote: > > > > I agree that a generated password is the way to go, and the challenge is > > making it available to the user. Depending on how it is stored for the > > identity provider, having a command line tool to read and print it could > be > > a reasonable option. > > > > Although this particular thread referenced a specific Twitter post, this > > general discussion is more of a reflection of the need to make things > more > > secure by default as other products have followed similar approaches. > > > > Regards, > > David Handermann > > > > On Wed, Feb 10, 2021 at 8:53 AM Kevin Doran wrote: > > > >> I am in favor of requiring some authentication by default. > >> > >> I’m in favor of an admin username and generated password. (It sounds > li9ke > >> most of us are on the same page, but I don’t think a static, default > >> password buys us much against the types of abuse shown on the twitter > >> thread Joe shared.) > >> > >> We need some way of making the generated password discoverable… Print to > >> the logs on first boot? Not great but are there other mechanisms? A > setup > >> CLI utility? > >> > >> To help not impede automated deployments, maybe we should change the > >> startup flow such that there is a way to provide this password. That > would > >> be better than people just disabling whatever default authentication we > set. > >> > >> > >>> On Feb 10, 2021, at 09:45, David Handermann < > exceptionfact...@gmail.com> > >> wrote: > >>> > >>> Mark, > >>> > >>> Thanks for clarifying, that makes sense. > >>> > >>> Regards, > >>> David Handermann > >>> > >>> On Wed, Feb 10, 2021 at 8:41 AM Mark Payne > wrote: > >>> > David, > > My concern was purely around generating client certs and using mutual > >> TLS. > I definitely think we should have a server cert if using username & > password. > > Thanks > -Mark > > > > On Feb 10, 2021, at 9:37 AM, David Handermann < > exceptionfact...@gmail.com> wrote: > > > > Mark, > > > > Thanks for your perspective on certificate generation, I agree that > > troubleshooting certificates can be confusing due to unclear error > > messaging. Generating self-signed certificates for one-way TLS still > > requires the user to accept the certificate presented, but at least > >> that > is > > more common in various products. Are you concerned about that > >> situation, > > or are you more concerned about the additional challenges of mutual > TLS > > authentication? > > > > Generating a random password in absence of any other configuration > >> would > > certainly be easier from a new user perspective. Some of the > security > > concerns with password authentication can be mitigated with one-way > >> TLS, > so > > a blending of these approaches, as Joe describes in NIFI-8220, seems > like a > > good way to go. > > > > Regards, > > David Handermann > > > > On Wed, Feb 10, 2021 at 8:23 AM Mark Payne > >> wrote: > > > >> I would be in favor of this as well. I agree that there is no need > to > wait > >> for a 2.0 version - there is no inherit backward compatibility > >> challenge > >> here. > >> Requiring that new application configs be set, etc. I think is > completely > >> fair game between minor versions. > >> > >> Personally, though, I would very much stray away from > auto-generating > >> certificates. For those of us who have dealt with certificates > significantly > >> In the past, minor configuration issues are easy to address. But for > >> someone who hasn’t spent much time dealing with certificates, the > >> error > >> messages > >> that are often intentionally vague can quickly result in users being > >> overwhelmed. This is especially true if browser configurations are > already > >> setup to > >> automatically offer certificates that area already installed - this > >> can > >> result in weird error messages about untrusted certificates when the > user > >> thinks > >> they haven’t even provided a certificate, etc. It gets really hairy. > >> > >> I am more in favor of a default username/password personally. It > would > >> require implementing a new auth provider. And
Re: [discuss] we need to enable secure by default...
Aren’t most of these applications installed by an installer? Maybe we can have one or more installers that setup a secure instance, and those installers could be the *production* nifi, and keep the zip distribution open for developers? > On Feb 10, 2021, at 10:04, David Handermann > wrote: > > I agree that a generated password is the way to go, and the challenge is > making it available to the user. Depending on how it is stored for the > identity provider, having a command line tool to read and print it could be > a reasonable option. > > Although this particular thread referenced a specific Twitter post, this > general discussion is more of a reflection of the need to make things more > secure by default as other products have followed similar approaches. > > Regards, > David Handermann > > On Wed, Feb 10, 2021 at 8:53 AM Kevin Doran wrote: > >> I am in favor of requiring some authentication by default. >> >> I’m in favor of an admin username and generated password. (It sounds li9ke >> most of us are on the same page, but I don’t think a static, default >> password buys us much against the types of abuse shown on the twitter >> thread Joe shared.) >> >> We need some way of making the generated password discoverable… Print to >> the logs on first boot? Not great but are there other mechanisms? A setup >> CLI utility? >> >> To help not impede automated deployments, maybe we should change the >> startup flow such that there is a way to provide this password. That would >> be better than people just disabling whatever default authentication we set. >> >> >>> On Feb 10, 2021, at 09:45, David Handermann >> wrote: >>> >>> Mark, >>> >>> Thanks for clarifying, that makes sense. >>> >>> Regards, >>> David Handermann >>> >>> On Wed, Feb 10, 2021 at 8:41 AM Mark Payne wrote: >>> David, My concern was purely around generating client certs and using mutual >> TLS. I definitely think we should have a server cert if using username & password. Thanks -Mark > On Feb 10, 2021, at 9:37 AM, David Handermann < exceptionfact...@gmail.com> wrote: > > Mark, > > Thanks for your perspective on certificate generation, I agree that > troubleshooting certificates can be confusing due to unclear error > messaging. Generating self-signed certificates for one-way TLS still > requires the user to accept the certificate presented, but at least >> that is > more common in various products. Are you concerned about that >> situation, > or are you more concerned about the additional challenges of mutual TLS > authentication? > > Generating a random password in absence of any other configuration >> would > certainly be easier from a new user perspective. Some of the security > concerns with password authentication can be mitigated with one-way >> TLS, so > a blending of these approaches, as Joe describes in NIFI-8220, seems like a > good way to go. > > Regards, > David Handermann > > On Wed, Feb 10, 2021 at 8:23 AM Mark Payne >> wrote: > >> I would be in favor of this as well. I agree that there is no need to wait >> for a 2.0 version - there is no inherit backward compatibility >> challenge >> here. >> Requiring that new application configs be set, etc. I think is completely >> fair game between minor versions. >> >> Personally, though, I would very much stray away from auto-generating >> certificates. For those of us who have dealt with certificates significantly >> In the past, minor configuration issues are easy to address. But for >> someone who hasn’t spent much time dealing with certificates, the >> error >> messages >> that are often intentionally vague can quickly result in users being >> overwhelmed. This is especially true if browser configurations are already >> setup to >> automatically offer certificates that area already installed - this >> can >> result in weird error messages about untrusted certificates when the user >> thinks >> they haven’t even provided a certificate, etc. It gets really hairy. >> >> I am more in favor of a default username/password personally. It would >> require implementing a new auth provider. And it’s one that historically we >> have >> avoided implementing because a basic auth type of approach is less secure >> than mutual auth, ldap, etc. But it’s more secure than nothing. >> >> Thanks >> -Mark >> >> >>> On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: >>> >>> There are a range of things to consider. And yes whatever we do will >>> involve writing code. We also have to find the right place for the >> bar >>> here. >>> >>> 1. Disable HTTP by default. And if they want to enable HTTP they should >>> also have to
Re: [discuss] we need to enable secure by default...
I agree that a generated password is the way to go, and the challenge is making it available to the user. Depending on how it is stored for the identity provider, having a command line tool to read and print it could be a reasonable option. Although this particular thread referenced a specific Twitter post, this general discussion is more of a reflection of the need to make things more secure by default as other products have followed similar approaches. Regards, David Handermann On Wed, Feb 10, 2021 at 8:53 AM Kevin Doran wrote: > I am in favor of requiring some authentication by default. > > I’m in favor of an admin username and generated password. (It sounds li9ke > most of us are on the same page, but I don’t think a static, default > password buys us much against the types of abuse shown on the twitter > thread Joe shared.) > > We need some way of making the generated password discoverable… Print to > the logs on first boot? Not great but are there other mechanisms? A setup > CLI utility? > > To help not impede automated deployments, maybe we should change the > startup flow such that there is a way to provide this password. That would > be better than people just disabling whatever default authentication we set. > > > > On Feb 10, 2021, at 09:45, David Handermann > wrote: > > > > Mark, > > > > Thanks for clarifying, that makes sense. > > > > Regards, > > David Handermann > > > > On Wed, Feb 10, 2021 at 8:41 AM Mark Payne wrote: > > > >> David, > >> > >> My concern was purely around generating client certs and using mutual > TLS. > >> I definitely think we should have a server cert if using username & > >> password. > >> > >> Thanks > >> -Mark > >> > >> > >>> On Feb 10, 2021, at 9:37 AM, David Handermann < > >> exceptionfact...@gmail.com> wrote: > >>> > >>> Mark, > >>> > >>> Thanks for your perspective on certificate generation, I agree that > >>> troubleshooting certificates can be confusing due to unclear error > >>> messaging. Generating self-signed certificates for one-way TLS still > >>> requires the user to accept the certificate presented, but at least > that > >> is > >>> more common in various products. Are you concerned about that > situation, > >>> or are you more concerned about the additional challenges of mutual TLS > >>> authentication? > >>> > >>> Generating a random password in absence of any other configuration > would > >>> certainly be easier from a new user perspective. Some of the security > >>> concerns with password authentication can be mitigated with one-way > TLS, > >> so > >>> a blending of these approaches, as Joe describes in NIFI-8220, seems > >> like a > >>> good way to go. > >>> > >>> Regards, > >>> David Handermann > >>> > >>> On Wed, Feb 10, 2021 at 8:23 AM Mark Payne > wrote: > >>> > I would be in favor of this as well. I agree that there is no need to > >> wait > for a 2.0 version - there is no inherit backward compatibility > challenge > here. > Requiring that new application configs be set, etc. I think is > >> completely > fair game between minor versions. > > Personally, though, I would very much stray away from auto-generating > certificates. For those of us who have dealt with certificates > >> significantly > In the past, minor configuration issues are easy to address. But for > someone who hasn’t spent much time dealing with certificates, the > error > messages > that are often intentionally vague can quickly result in users being > overwhelmed. This is especially true if browser configurations are > >> already > setup to > automatically offer certificates that area already installed - this > can > result in weird error messages about untrusted certificates when the > >> user > thinks > they haven’t even provided a certificate, etc. It gets really hairy. > > I am more in favor of a default username/password personally. It would > require implementing a new auth provider. And it’s one that > >> historically we > have > avoided implementing because a basic auth type of approach is less > >> secure > than mutual auth, ldap, etc. But it’s more secure than nothing. > > Thanks > -Mark > > > > On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: > > > > There are a range of things to consider. And yes whatever we do will > > involve writing code. We also have to find the right place for the > bar > > here. > > > > 1. Disable HTTP by default. And if they want to enable HTTP they > >> should > > also have to make a config change indicating they are fully willing > to > > accept that it is an entirely non secure configuration as far as the > > application is concerned. > > 2. Provide a default username/password provider out of the box > >> configured > > by default and an auto generate self-signed server cert. This means > >> the > > NiFi server will provide the
Re: [discuss] we need to enable secure by default...
I dont believe automated deployments would be impacted. They can use any of the existing security mechanisms. We would not be doing 'http basic' for anything. The username and password would not be static. These would be auto generated and made available to the user in some way that isn't by default accessible to the world. It isn't a knee jerk reaction to finally take meaningful steps here. This isn't a single server. If you look at the reports of how many there are it is embarrassing and shocking. Is it our 'fault'? No, not really. It is our responsibility to make this better. Yep. On Wed, Feb 10, 2021 at 7:53 AM Kevin Doran wrote: > I am in favor of requiring some authentication by default. > > I’m in favor of an admin username and generated password. (It sounds li9ke > most of us are on the same page, but I don’t think a static, default > password buys us much against the types of abuse shown on the twitter > thread Joe shared.) > > We need some way of making the generated password discoverable… Print to > the logs on first boot? Not great but are there other mechanisms? A setup > CLI utility? > > To help not impede automated deployments, maybe we should change the > startup flow such that there is a way to provide this password. That would > be better than people just disabling whatever default authentication we set. > > > > On Feb 10, 2021, at 09:45, David Handermann > wrote: > > > > Mark, > > > > Thanks for clarifying, that makes sense. > > > > Regards, > > David Handermann > > > > On Wed, Feb 10, 2021 at 8:41 AM Mark Payne wrote: > > > >> David, > >> > >> My concern was purely around generating client certs and using mutual > TLS. > >> I definitely think we should have a server cert if using username & > >> password. > >> > >> Thanks > >> -Mark > >> > >> > >>> On Feb 10, 2021, at 9:37 AM, David Handermann < > >> exceptionfact...@gmail.com> wrote: > >>> > >>> Mark, > >>> > >>> Thanks for your perspective on certificate generation, I agree that > >>> troubleshooting certificates can be confusing due to unclear error > >>> messaging. Generating self-signed certificates for one-way TLS still > >>> requires the user to accept the certificate presented, but at least > that > >> is > >>> more common in various products. Are you concerned about that > situation, > >>> or are you more concerned about the additional challenges of mutual TLS > >>> authentication? > >>> > >>> Generating a random password in absence of any other configuration > would > >>> certainly be easier from a new user perspective. Some of the security > >>> concerns with password authentication can be mitigated with one-way > TLS, > >> so > >>> a blending of these approaches, as Joe describes in NIFI-8220, seems > >> like a > >>> good way to go. > >>> > >>> Regards, > >>> David Handermann > >>> > >>> On Wed, Feb 10, 2021 at 8:23 AM Mark Payne > wrote: > >>> > I would be in favor of this as well. I agree that there is no need to > >> wait > for a 2.0 version - there is no inherit backward compatibility > challenge > here. > Requiring that new application configs be set, etc. I think is > >> completely > fair game between minor versions. > > Personally, though, I would very much stray away from auto-generating > certificates. For those of us who have dealt with certificates > >> significantly > In the past, minor configuration issues are easy to address. But for > someone who hasn’t spent much time dealing with certificates, the > error > messages > that are often intentionally vague can quickly result in users being > overwhelmed. This is especially true if browser configurations are > >> already > setup to > automatically offer certificates that area already installed - this > can > result in weird error messages about untrusted certificates when the > >> user > thinks > they haven’t even provided a certificate, etc. It gets really hairy. > > I am more in favor of a default username/password personally. It would > require implementing a new auth provider. And it’s one that > >> historically we > have > avoided implementing because a basic auth type of approach is less > >> secure > than mutual auth, ldap, etc. But it’s more secure than nothing. > > Thanks > -Mark > > > > On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: > > > > There are a range of things to consider. And yes whatever we do will > > involve writing code. We also have to find the right place for the > bar > > here. > > > > 1. Disable HTTP by default. And if they want to enable HTTP they > >> should > > also have to make a config change indicating they are fully willing > to > > accept that it is an entirely non secure configuration as far as the > > application is concerned. > > 2. Provide a default username/password provider out of the box > >> configured > > by
Re: [discuss] we need to enable secure by default...
I am in favor of requiring some authentication by default. I’m in favor of an admin username and generated password. (It sounds li9ke most of us are on the same page, but I don’t think a static, default password buys us much against the types of abuse shown on the twitter thread Joe shared.) We need some way of making the generated password discoverable… Print to the logs on first boot? Not great but are there other mechanisms? A setup CLI utility? To help not impede automated deployments, maybe we should change the startup flow such that there is a way to provide this password. That would be better than people just disabling whatever default authentication we set. > On Feb 10, 2021, at 09:45, David Handermann > wrote: > > Mark, > > Thanks for clarifying, that makes sense. > > Regards, > David Handermann > > On Wed, Feb 10, 2021 at 8:41 AM Mark Payne wrote: > >> David, >> >> My concern was purely around generating client certs and using mutual TLS. >> I definitely think we should have a server cert if using username & >> password. >> >> Thanks >> -Mark >> >> >>> On Feb 10, 2021, at 9:37 AM, David Handermann < >> exceptionfact...@gmail.com> wrote: >>> >>> Mark, >>> >>> Thanks for your perspective on certificate generation, I agree that >>> troubleshooting certificates can be confusing due to unclear error >>> messaging. Generating self-signed certificates for one-way TLS still >>> requires the user to accept the certificate presented, but at least that >> is >>> more common in various products. Are you concerned about that situation, >>> or are you more concerned about the additional challenges of mutual TLS >>> authentication? >>> >>> Generating a random password in absence of any other configuration would >>> certainly be easier from a new user perspective. Some of the security >>> concerns with password authentication can be mitigated with one-way TLS, >> so >>> a blending of these approaches, as Joe describes in NIFI-8220, seems >> like a >>> good way to go. >>> >>> Regards, >>> David Handermann >>> >>> On Wed, Feb 10, 2021 at 8:23 AM Mark Payne wrote: >>> I would be in favor of this as well. I agree that there is no need to >> wait for a 2.0 version - there is no inherit backward compatibility challenge here. Requiring that new application configs be set, etc. I think is >> completely fair game between minor versions. Personally, though, I would very much stray away from auto-generating certificates. For those of us who have dealt with certificates >> significantly In the past, minor configuration issues are easy to address. But for someone who hasn’t spent much time dealing with certificates, the error messages that are often intentionally vague can quickly result in users being overwhelmed. This is especially true if browser configurations are >> already setup to automatically offer certificates that area already installed - this can result in weird error messages about untrusted certificates when the >> user thinks they haven’t even provided a certificate, etc. It gets really hairy. I am more in favor of a default username/password personally. It would require implementing a new auth provider. And it’s one that >> historically we have avoided implementing because a basic auth type of approach is less >> secure than mutual auth, ldap, etc. But it’s more secure than nothing. Thanks -Mark > On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: > > There are a range of things to consider. And yes whatever we do will > involve writing code. We also have to find the right place for the bar > here. > > 1. Disable HTTP by default. And if they want to enable HTTP they >> should > also have to make a config change indicating they are fully willing to > accept that it is an entirely non secure configuration as far as the > application is concerned. > 2. Provide a default username/password provider out of the box >> configured > by default and an auto generate self-signed server cert. This means >> the > NiFi server will provide the client browser a cert. It won't be > known/trusted so the browser will advise of this. And on startup NiFi can > auto generate and log this username and password. It would truly be a > single username/password and not some store for various users. We > disallow access to all restricted components by default. > > This default configuration at least means someone cannot start NiFi and it > is totally exposed by default while also preserving a pretty simple >> 'get > started' model for the user. They'd have to take action to make it >> less > secure. > > The option DavidH mentions of mutual auth could work well also and as >> he > mentioned avoids the need for anything special in terms of
Re: [discuss] we need to enable secure by default...
I'm on the opposite side of this discussion. I disagree that NiFi has to implement something immediately. Now, I admit that I am old school, and feel that if you aren't capable of doing what is necessary to secure your own things, it's your own fault. But, I also realize, everyone on the internet seems to be coding now without the true understanding of what that means. I totally agree that a NiFi server open in the wild is a bad thing, and can be used by hackers. But, truly, NiFi isn't broken in the sense of security vulnerability. Mark mentions a default username password with a basic auth, which is actually no better than what that Twitter post had. The default username/password will be known to all, and that will be the first thing they attempt to get into those servers. (Or using the API.) My company has looked into the basic auth side of things, just so that even in a local network, people couldn't just find the server and do stuff on it. But, since there wasn't a NiFi "approved" method, we didn't pursue it. Instead, we run NiFi on a single machine that you have to log in to to be able to get to it, and the single machine has very limited users and the no access to NiFi from outside that machine. In a second instance, we have done a SSH tunnel into a Linux machine to access the NiFi running on that Linux machine when firewalls are not open to the NiFi port. Also, I run NiFi at home, and I don't have it connected to the Internet. I wouldn't want to deal with user/pass or HTTPS because there is no need for it. HTTP on its own isn't bad, it is the data individuals are sending that determines if HTTP shouldn't be used. My small website is just simple data with absolutely no usefulness to hackers, and therefore, doesn't really need HTTPS. My opinion is that we shouldn't take a knee-jerk reaction to this one Twitter post about what appears to be ONE NiFi server, unsecured on the Internet. Just my opposing opinion. John On Wednesday, February 10, 2021, 09:24:01 AM EST, Mark Payne wrote: > I would be in favor of this as well. I agree that there is no need to wait > for a 2.0 version - there is no inherit backward compatibility challenge here. > Requiring that new application configs be set, etc. I think is completely > fair game between minor versions. > > Personally, though, I would very much stray away from auto-generating > certificates. For those of us who have dealt with certificates significantly > In the past, minor configuration issues are easy to address. But for someone > who hasn’t spent much time dealing with certificates, the error messages > that are often intentionally vague can quickly result in users being > overwhelmed. This is especially true if browser configurations are already > setup to > automatically offer certificates that area already installed - this can > result in weird error messages about untrusted certificates when the user > thinks > they haven’t even provided a certificate, etc. It gets really hairy. > > I am more in favor of a default username/password personally. It would > require implementing a new auth provider. And it’s one that historically we > have > avoided implementing because a basic auth type of approach is less secure > than mutual auth, ldap, etc. But it’s more secure than nothing. > > Thanks > -Mark
Re: [discuss] we need to enable secure by default...
Mark, Thanks for clarifying, that makes sense. Regards, David Handermann On Wed, Feb 10, 2021 at 8:41 AM Mark Payne wrote: > David, > > My concern was purely around generating client certs and using mutual TLS. > I definitely think we should have a server cert if using username & > password. > > Thanks > -Mark > > > > On Feb 10, 2021, at 9:37 AM, David Handermann < > exceptionfact...@gmail.com> wrote: > > > > Mark, > > > > Thanks for your perspective on certificate generation, I agree that > > troubleshooting certificates can be confusing due to unclear error > > messaging. Generating self-signed certificates for one-way TLS still > > requires the user to accept the certificate presented, but at least that > is > > more common in various products. Are you concerned about that situation, > > or are you more concerned about the additional challenges of mutual TLS > > authentication? > > > > Generating a random password in absence of any other configuration would > > certainly be easier from a new user perspective. Some of the security > > concerns with password authentication can be mitigated with one-way TLS, > so > > a blending of these approaches, as Joe describes in NIFI-8220, seems > like a > > good way to go. > > > > Regards, > > David Handermann > > > > On Wed, Feb 10, 2021 at 8:23 AM Mark Payne wrote: > > > >> I would be in favor of this as well. I agree that there is no need to > wait > >> for a 2.0 version - there is no inherit backward compatibility challenge > >> here. > >> Requiring that new application configs be set, etc. I think is > completely > >> fair game between minor versions. > >> > >> Personally, though, I would very much stray away from auto-generating > >> certificates. For those of us who have dealt with certificates > significantly > >> In the past, minor configuration issues are easy to address. But for > >> someone who hasn’t spent much time dealing with certificates, the error > >> messages > >> that are often intentionally vague can quickly result in users being > >> overwhelmed. This is especially true if browser configurations are > already > >> setup to > >> automatically offer certificates that area already installed - this can > >> result in weird error messages about untrusted certificates when the > user > >> thinks > >> they haven’t even provided a certificate, etc. It gets really hairy. > >> > >> I am more in favor of a default username/password personally. It would > >> require implementing a new auth provider. And it’s one that > historically we > >> have > >> avoided implementing because a basic auth type of approach is less > secure > >> than mutual auth, ldap, etc. But it’s more secure than nothing. > >> > >> Thanks > >> -Mark > >> > >> > >>> On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: > >>> > >>> There are a range of things to consider. And yes whatever we do will > >>> involve writing code. We also have to find the right place for the bar > >>> here. > >>> > >>> 1. Disable HTTP by default. And if they want to enable HTTP they > should > >>> also have to make a config change indicating they are fully willing to > >>> accept that it is an entirely non secure configuration as far as the > >>> application is concerned. > >>> 2. Provide a default username/password provider out of the box > configured > >>> by default and an auto generate self-signed server cert. This means > the > >>> NiFi server will provide the client browser a cert. It won't be > >>> known/trusted so the browser will advise of this. And on startup NiFi > >> can > >>> auto generate and log this username and password. It would truly be a > >>> single username/password and not some store for various users. We > >>> disallow access to all restricted components by default. > >>> > >>> This default configuration at least means someone cannot start NiFi and > >> it > >>> is totally exposed by default while also preserving a pretty simple > 'get > >>> started' model for the user. They'd have to take action to make it > less > >>> secure. > >>> > >>> The option DavidH mentions of mutual auth could work well also and as > he > >>> mentioned avoids the need for anything special in terms of auth > provider > >>> which is compelling for us but I do worry about the user experience on > >> that. > >>> > >>> I'll add to this that I think we cannot afford to wait for a NiFi 2.0 > >>> release to take action here. Or that we should expedite a NiFi 2.0 > >> release > >>> to take action and that we should just not make the bar for what 2.0 is > >> so > >>> high that we never get this done. But frankly I think we could make > this > >>> change in NiFi 1.15 and document what is happening. For existing > >>> installs/configs we'd not be changing anything except maybe when > they're > >>> using HTTP and don't set the 'no seriously i want this thing wide open > >>> option'. > >>> > >>> Thanks > >>> > >>> On Wed, Feb 10, 2021 at 6:58 AM David Handermann < > >> exceptionfact...@gmail.com> > >>>
Re: [discuss] we need to enable secure by default...
David, My concern was purely around generating client certs and using mutual TLS. I definitely think we should have a server cert if using username & password. Thanks -Mark > On Feb 10, 2021, at 9:37 AM, David Handermann > wrote: > > Mark, > > Thanks for your perspective on certificate generation, I agree that > troubleshooting certificates can be confusing due to unclear error > messaging. Generating self-signed certificates for one-way TLS still > requires the user to accept the certificate presented, but at least that is > more common in various products. Are you concerned about that situation, > or are you more concerned about the additional challenges of mutual TLS > authentication? > > Generating a random password in absence of any other configuration would > certainly be easier from a new user perspective. Some of the security > concerns with password authentication can be mitigated with one-way TLS, so > a blending of these approaches, as Joe describes in NIFI-8220, seems like a > good way to go. > > Regards, > David Handermann > > On Wed, Feb 10, 2021 at 8:23 AM Mark Payne wrote: > >> I would be in favor of this as well. I agree that there is no need to wait >> for a 2.0 version - there is no inherit backward compatibility challenge >> here. >> Requiring that new application configs be set, etc. I think is completely >> fair game between minor versions. >> >> Personally, though, I would very much stray away from auto-generating >> certificates. For those of us who have dealt with certificates significantly >> In the past, minor configuration issues are easy to address. But for >> someone who hasn’t spent much time dealing with certificates, the error >> messages >> that are often intentionally vague can quickly result in users being >> overwhelmed. This is especially true if browser configurations are already >> setup to >> automatically offer certificates that area already installed - this can >> result in weird error messages about untrusted certificates when the user >> thinks >> they haven’t even provided a certificate, etc. It gets really hairy. >> >> I am more in favor of a default username/password personally. It would >> require implementing a new auth provider. And it’s one that historically we >> have >> avoided implementing because a basic auth type of approach is less secure >> than mutual auth, ldap, etc. But it’s more secure than nothing. >> >> Thanks >> -Mark >> >> >>> On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: >>> >>> There are a range of things to consider. And yes whatever we do will >>> involve writing code. We also have to find the right place for the bar >>> here. >>> >>> 1. Disable HTTP by default. And if they want to enable HTTP they should >>> also have to make a config change indicating they are fully willing to >>> accept that it is an entirely non secure configuration as far as the >>> application is concerned. >>> 2. Provide a default username/password provider out of the box configured >>> by default and an auto generate self-signed server cert. This means the >>> NiFi server will provide the client browser a cert. It won't be >>> known/trusted so the browser will advise of this. And on startup NiFi >> can >>> auto generate and log this username and password. It would truly be a >>> single username/password and not some store for various users. We >>> disallow access to all restricted components by default. >>> >>> This default configuration at least means someone cannot start NiFi and >> it >>> is totally exposed by default while also preserving a pretty simple 'get >>> started' model for the user. They'd have to take action to make it less >>> secure. >>> >>> The option DavidH mentions of mutual auth could work well also and as he >>> mentioned avoids the need for anything special in terms of auth provider >>> which is compelling for us but I do worry about the user experience on >> that. >>> >>> I'll add to this that I think we cannot afford to wait for a NiFi 2.0 >>> release to take action here. Or that we should expedite a NiFi 2.0 >> release >>> to take action and that we should just not make the bar for what 2.0 is >> so >>> high that we never get this done. But frankly I think we could make this >>> change in NiFi 1.15 and document what is happening. For existing >>> installs/configs we'd not be changing anything except maybe when they're >>> using HTTP and don't set the 'no seriously i want this thing wide open >>> option'. >>> >>> Thanks >>> >>> On Wed, Feb 10, 2021 at 6:58 AM David Handermann < >> exceptionfact...@gmail.com> >>> wrote: >>> Having NiFi enforce authentication by default seems like the right way >> to go, especially given the capabilities of the system. Bryan raises a good point about storage of account information, so >> weighing the positives and negatives of various identity providers should be considered. Following on Joe's point about disabling plain
Re: [discuss] we need to enable secure by default...
Mark, Thanks for your perspective on certificate generation, I agree that troubleshooting certificates can be confusing due to unclear error messaging. Generating self-signed certificates for one-way TLS still requires the user to accept the certificate presented, but at least that is more common in various products. Are you concerned about that situation, or are you more concerned about the additional challenges of mutual TLS authentication? Generating a random password in absence of any other configuration would certainly be easier from a new user perspective. Some of the security concerns with password authentication can be mitigated with one-way TLS, so a blending of these approaches, as Joe describes in NIFI-8220, seems like a good way to go. Regards, David Handermann On Wed, Feb 10, 2021 at 8:23 AM Mark Payne wrote: > I would be in favor of this as well. I agree that there is no need to wait > for a 2.0 version - there is no inherit backward compatibility challenge > here. > Requiring that new application configs be set, etc. I think is completely > fair game between minor versions. > > Personally, though, I would very much stray away from auto-generating > certificates. For those of us who have dealt with certificates significantly > In the past, minor configuration issues are easy to address. But for > someone who hasn’t spent much time dealing with certificates, the error > messages > that are often intentionally vague can quickly result in users being > overwhelmed. This is especially true if browser configurations are already > setup to > automatically offer certificates that area already installed - this can > result in weird error messages about untrusted certificates when the user > thinks > they haven’t even provided a certificate, etc. It gets really hairy. > > I am more in favor of a default username/password personally. It would > require implementing a new auth provider. And it’s one that historically we > have > avoided implementing because a basic auth type of approach is less secure > than mutual auth, ldap, etc. But it’s more secure than nothing. > > Thanks > -Mark > > > > On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: > > > > There are a range of things to consider. And yes whatever we do will > > involve writing code. We also have to find the right place for the bar > > here. > > > > 1. Disable HTTP by default. And if they want to enable HTTP they should > > also have to make a config change indicating they are fully willing to > > accept that it is an entirely non secure configuration as far as the > > application is concerned. > > 2. Provide a default username/password provider out of the box configured > > by default and an auto generate self-signed server cert. This means the > > NiFi server will provide the client browser a cert. It won't be > > known/trusted so the browser will advise of this. And on startup NiFi > can > > auto generate and log this username and password. It would truly be a > > single username/password and not some store for various users. We > > disallow access to all restricted components by default. > > > > This default configuration at least means someone cannot start NiFi and > it > > is totally exposed by default while also preserving a pretty simple 'get > > started' model for the user. They'd have to take action to make it less > > secure. > > > > The option DavidH mentions of mutual auth could work well also and as he > > mentioned avoids the need for anything special in terms of auth provider > > which is compelling for us but I do worry about the user experience on > that. > > > > I'll add to this that I think we cannot afford to wait for a NiFi 2.0 > > release to take action here. Or that we should expedite a NiFi 2.0 > release > > to take action and that we should just not make the bar for what 2.0 is > so > > high that we never get this done. But frankly I think we could make this > > change in NiFi 1.15 and document what is happening. For existing > > installs/configs we'd not be changing anything except maybe when they're > > using HTTP and don't set the 'no seriously i want this thing wide open > > option'. > > > > Thanks > > > > On Wed, Feb 10, 2021 at 6:58 AM David Handermann < > exceptionfact...@gmail.com> > > wrote: > > > >> Having NiFi enforce authentication by default seems like the right way > to > >> go, especially given the capabilities of the system. > >> > >> Bryan raises a good point about storage of account information, so > weighing > >> the positives and negatives of various identity providers should be > >> considered. > >> > >> Following on Joe's point about disabling plain HTTP, one option could be > >> generating both client and server certificates and using Mutual TLS for > >> authentication. This would obviously require installing the client > >> certificate in a browser, which is not trivial, but could be part of an > >> installation guide. This approach definitely provides a high barrier of > >>
Re: [discuss] we need to enable secure by default...
I think the way Joe broke it down makes sense in that there are technically two different parts... For https, I don't see how we could do that without generating a default self-signed server cert where you'd get a warning in your browser to proceed. I suppose this could be confusing for users, although I feel like most people are familiar with this. For authentication, I suppose we could implement the identity provider in a way that it couldn't/wouldn't really be used for anything else, i.e. don't make it a general purpose database provider, make it only store a single default user/password. If we didn't do https by default, then we'd be providing username/password authentication via plain-text, which doesn't seem great. On Wed, Feb 10, 2021 at 9:30 AM Joe Witt wrote: > > Created https://issues.apache.org/jira/browse/NIFI-8220 > > I think we need to do this or some variation of it in 1.14 (said 1.15 > before but I meant 1.14). > > Thanks > > On Wed, Feb 10, 2021 at 7:23 AM Mark Payne wrote: > > > I would be in favor of this as well. I agree that there is no need to wait > > for a 2.0 version - there is no inherit backward compatibility challenge > > here. > > Requiring that new application configs be set, etc. I think is completely > > fair game between minor versions. > > > > Personally, though, I would very much stray away from auto-generating > > certificates. For those of us who have dealt with certificates significantly > > In the past, minor configuration issues are easy to address. But for > > someone who hasn’t spent much time dealing with certificates, the error > > messages > > that are often intentionally vague can quickly result in users being > > overwhelmed. This is especially true if browser configurations are already > > setup to > > automatically offer certificates that area already installed - this can > > result in weird error messages about untrusted certificates when the user > > thinks > > they haven’t even provided a certificate, etc. It gets really hairy. > > > > I am more in favor of a default username/password personally. It would > > require implementing a new auth provider. And it’s one that historically we > > have > > avoided implementing because a basic auth type of approach is less secure > > than mutual auth, ldap, etc. But it’s more secure than nothing. > > > > Thanks > > -Mark > > > > > > > On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: > > > > > > There are a range of things to consider. And yes whatever we do will > > > involve writing code. We also have to find the right place for the bar > > > here. > > > > > > 1. Disable HTTP by default. And if they want to enable HTTP they should > > > also have to make a config change indicating they are fully willing to > > > accept that it is an entirely non secure configuration as far as the > > > application is concerned. > > > 2. Provide a default username/password provider out of the box configured > > > by default and an auto generate self-signed server cert. This means the > > > NiFi server will provide the client browser a cert. It won't be > > > known/trusted so the browser will advise of this. And on startup NiFi > > can > > > auto generate and log this username and password. It would truly be a > > > single username/password and not some store for various users. We > > > disallow access to all restricted components by default. > > > > > > This default configuration at least means someone cannot start NiFi and > > it > > > is totally exposed by default while also preserving a pretty simple 'get > > > started' model for the user. They'd have to take action to make it less > > > secure. > > > > > > The option DavidH mentions of mutual auth could work well also and as he > > > mentioned avoids the need for anything special in terms of auth provider > > > which is compelling for us but I do worry about the user experience on > > that. > > > > > > I'll add to this that I think we cannot afford to wait for a NiFi 2.0 > > > release to take action here. Or that we should expedite a NiFi 2.0 > > release > > > to take action and that we should just not make the bar for what 2.0 is > > so > > > high that we never get this done. But frankly I think we could make this > > > change in NiFi 1.15 and document what is happening. For existing > > > installs/configs we'd not be changing anything except maybe when they're > > > using HTTP and don't set the 'no seriously i want this thing wide open > > > option'. > > > > > > Thanks > > > > > > On Wed, Feb 10, 2021 at 6:58 AM David Handermann < > > exceptionfact...@gmail.com> > > > wrote: > > > > > >> Having NiFi enforce authentication by default seems like the right way > > to > > >> go, especially given the capabilities of the system. > > >> > > >> Bryan raises a good point about storage of account information, so > > weighing > > >> the positives and negatives of various identity providers should be > > >> considered. > > >> > > >> Following on Joe's point about disabling
Re: [discuss] we need to enable secure by default...
Created https://issues.apache.org/jira/browse/NIFI-8220 I think we need to do this or some variation of it in 1.14 (said 1.15 before but I meant 1.14). Thanks On Wed, Feb 10, 2021 at 7:23 AM Mark Payne wrote: > I would be in favor of this as well. I agree that there is no need to wait > for a 2.0 version - there is no inherit backward compatibility challenge > here. > Requiring that new application configs be set, etc. I think is completely > fair game between minor versions. > > Personally, though, I would very much stray away from auto-generating > certificates. For those of us who have dealt with certificates significantly > In the past, minor configuration issues are easy to address. But for > someone who hasn’t spent much time dealing with certificates, the error > messages > that are often intentionally vague can quickly result in users being > overwhelmed. This is especially true if browser configurations are already > setup to > automatically offer certificates that area already installed - this can > result in weird error messages about untrusted certificates when the user > thinks > they haven’t even provided a certificate, etc. It gets really hairy. > > I am more in favor of a default username/password personally. It would > require implementing a new auth provider. And it’s one that historically we > have > avoided implementing because a basic auth type of approach is less secure > than mutual auth, ldap, etc. But it’s more secure than nothing. > > Thanks > -Mark > > > > On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: > > > > There are a range of things to consider. And yes whatever we do will > > involve writing code. We also have to find the right place for the bar > > here. > > > > 1. Disable HTTP by default. And if they want to enable HTTP they should > > also have to make a config change indicating they are fully willing to > > accept that it is an entirely non secure configuration as far as the > > application is concerned. > > 2. Provide a default username/password provider out of the box configured > > by default and an auto generate self-signed server cert. This means the > > NiFi server will provide the client browser a cert. It won't be > > known/trusted so the browser will advise of this. And on startup NiFi > can > > auto generate and log this username and password. It would truly be a > > single username/password and not some store for various users. We > > disallow access to all restricted components by default. > > > > This default configuration at least means someone cannot start NiFi and > it > > is totally exposed by default while also preserving a pretty simple 'get > > started' model for the user. They'd have to take action to make it less > > secure. > > > > The option DavidH mentions of mutual auth could work well also and as he > > mentioned avoids the need for anything special in terms of auth provider > > which is compelling for us but I do worry about the user experience on > that. > > > > I'll add to this that I think we cannot afford to wait for a NiFi 2.0 > > release to take action here. Or that we should expedite a NiFi 2.0 > release > > to take action and that we should just not make the bar for what 2.0 is > so > > high that we never get this done. But frankly I think we could make this > > change in NiFi 1.15 and document what is happening. For existing > > installs/configs we'd not be changing anything except maybe when they're > > using HTTP and don't set the 'no seriously i want this thing wide open > > option'. > > > > Thanks > > > > On Wed, Feb 10, 2021 at 6:58 AM David Handermann < > exceptionfact...@gmail.com> > > wrote: > > > >> Having NiFi enforce authentication by default seems like the right way > to > >> go, especially given the capabilities of the system. > >> > >> Bryan raises a good point about storage of account information, so > weighing > >> the positives and negatives of various identity providers should be > >> considered. > >> > >> Following on Joe's point about disabling plain HTTP, one option could be > >> generating both client and server certificates and using Mutual TLS for > >> authentication. This would obviously require installing the client > >> certificate in a browser, which is not trivial, but could be part of an > >> installation guide. This approach definitely provides a high barrier of > >> entry of new users, but provides a strong level of security while > avoiding > >> the need for some other identity provider service to be configured. As > >> others have mentioned, this seems necessary to address the situation of > >> someone installing NiFi without a full understanding of the > configuration > >> required, so it is important to keep the audience in mind when > evaluating a > >> solution. > >> > >> Regards, > >> David Handermann > >> > >> On Wed, Feb 10, 2021 at 7:39 AM Bryan Bende wrote: > >> > >>> Just to clarify, I was not suggesting that we make a default secure > >>> setup that requires LDAP. > >>>
Re: [discuss] we need to enable secure by default...
I would be in favor of this as well. I agree that there is no need to wait for a 2.0 version - there is no inherit backward compatibility challenge here. Requiring that new application configs be set, etc. I think is completely fair game between minor versions. Personally, though, I would very much stray away from auto-generating certificates. For those of us who have dealt with certificates significantly In the past, minor configuration issues are easy to address. But for someone who hasn’t spent much time dealing with certificates, the error messages that are often intentionally vague can quickly result in users being overwhelmed. This is especially true if browser configurations are already setup to automatically offer certificates that area already installed - this can result in weird error messages about untrusted certificates when the user thinks they haven’t even provided a certificate, etc. It gets really hairy. I am more in favor of a default username/password personally. It would require implementing a new auth provider. And it’s one that historically we have avoided implementing because a basic auth type of approach is less secure than mutual auth, ldap, etc. But it’s more secure than nothing. Thanks -Mark > On Feb 10, 2021, at 9:13 AM, Joe Witt wrote: > > There are a range of things to consider. And yes whatever we do will > involve writing code. We also have to find the right place for the bar > here. > > 1. Disable HTTP by default. And if they want to enable HTTP they should > also have to make a config change indicating they are fully willing to > accept that it is an entirely non secure configuration as far as the > application is concerned. > 2. Provide a default username/password provider out of the box configured > by default and an auto generate self-signed server cert. This means the > NiFi server will provide the client browser a cert. It won't be > known/trusted so the browser will advise of this. And on startup NiFi can > auto generate and log this username and password. It would truly be a > single username/password and not some store for various users. We > disallow access to all restricted components by default. > > This default configuration at least means someone cannot start NiFi and it > is totally exposed by default while also preserving a pretty simple 'get > started' model for the user. They'd have to take action to make it less > secure. > > The option DavidH mentions of mutual auth could work well also and as he > mentioned avoids the need for anything special in terms of auth provider > which is compelling for us but I do worry about the user experience on that. > > I'll add to this that I think we cannot afford to wait for a NiFi 2.0 > release to take action here. Or that we should expedite a NiFi 2.0 release > to take action and that we should just not make the bar for what 2.0 is so > high that we never get this done. But frankly I think we could make this > change in NiFi 1.15 and document what is happening. For existing > installs/configs we'd not be changing anything except maybe when they're > using HTTP and don't set the 'no seriously i want this thing wide open > option'. > > Thanks > > On Wed, Feb 10, 2021 at 6:58 AM David Handermann > wrote: > >> Having NiFi enforce authentication by default seems like the right way to >> go, especially given the capabilities of the system. >> >> Bryan raises a good point about storage of account information, so weighing >> the positives and negatives of various identity providers should be >> considered. >> >> Following on Joe's point about disabling plain HTTP, one option could be >> generating both client and server certificates and using Mutual TLS for >> authentication. This would obviously require installing the client >> certificate in a browser, which is not trivial, but could be part of an >> installation guide. This approach definitely provides a high barrier of >> entry of new users, but provides a strong level of security while avoiding >> the need for some other identity provider service to be configured. As >> others have mentioned, this seems necessary to address the situation of >> someone installing NiFi without a full understanding of the configuration >> required, so it is important to keep the audience in mind when evaluating a >> solution. >> >> Regards, >> David Handermann >> >> On Wed, Feb 10, 2021 at 7:39 AM Bryan Bende wrote: >> >>> Just to clarify, I was not suggesting that we make a default secure >>> setup that requires LDAP. >>> >>> I was just saying that in order to provide a default secure setup, >>> we'd have to provide a login identity provider implementation that is >>> backed by a file or database table, which in the past we decided >>> against. >>> >>> On Wed, Feb 10, 2021 at 8:28 AM Russell Bateman >>> wrote: I second the concerns expressed, but second especially Bryan's pointing out that requiring LDAP/AD to be set up in
Re: [discuss] we need to enable secure by default...
There are a range of things to consider. And yes whatever we do will involve writing code. We also have to find the right place for the bar here. 1. Disable HTTP by default. And if they want to enable HTTP they should also have to make a config change indicating they are fully willing to accept that it is an entirely non secure configuration as far as the application is concerned. 2. Provide a default username/password provider out of the box configured by default and an auto generate self-signed server cert. This means the NiFi server will provide the client browser a cert. It won't be known/trusted so the browser will advise of this. And on startup NiFi can auto generate and log this username and password. It would truly be a single username/password and not some store for various users. We disallow access to all restricted components by default. This default configuration at least means someone cannot start NiFi and it is totally exposed by default while also preserving a pretty simple 'get started' model for the user. They'd have to take action to make it less secure. The option DavidH mentions of mutual auth could work well also and as he mentioned avoids the need for anything special in terms of auth provider which is compelling for us but I do worry about the user experience on that. I'll add to this that I think we cannot afford to wait for a NiFi 2.0 release to take action here. Or that we should expedite a NiFi 2.0 release to take action and that we should just not make the bar for what 2.0 is so high that we never get this done. But frankly I think we could make this change in NiFi 1.15 and document what is happening. For existing installs/configs we'd not be changing anything except maybe when they're using HTTP and don't set the 'no seriously i want this thing wide open option'. Thanks On Wed, Feb 10, 2021 at 6:58 AM David Handermann wrote: > Having NiFi enforce authentication by default seems like the right way to > go, especially given the capabilities of the system. > > Bryan raises a good point about storage of account information, so weighing > the positives and negatives of various identity providers should be > considered. > > Following on Joe's point about disabling plain HTTP, one option could be > generating both client and server certificates and using Mutual TLS for > authentication. This would obviously require installing the client > certificate in a browser, which is not trivial, but could be part of an > installation guide. This approach definitely provides a high barrier of > entry of new users, but provides a strong level of security while avoiding > the need for some other identity provider service to be configured. As > others have mentioned, this seems necessary to address the situation of > someone installing NiFi without a full understanding of the configuration > required, so it is important to keep the audience in mind when evaluating a > solution. > > Regards, > David Handermann > > On Wed, Feb 10, 2021 at 7:39 AM Bryan Bende wrote: > > > Just to clarify, I was not suggesting that we make a default secure > > setup that requires LDAP. > > > > I was just saying that in order to provide a default secure setup, > > we'd have to provide a login identity provider implementation that is > > backed by a file or database table, which in the past we decided > > against. > > > > On Wed, Feb 10, 2021 at 8:28 AM Russell Bateman > > wrote: > > > > > > I second the concerns expressed, but second especially Bryan's pointing > > > out that requiring LDAP/AD to be set up in order even to begin to use > > > our framework would be a bit onerous for developers just interested in > > > getting work done and a barrier to considering the framework should it > > > be erected a little too high. Should we at least glance at how this is > > > solved by the likes of other projects, Kafka and Cassandra come to > mind, > > > even if it means resorting to a store of a name or two? I didn't find > > > getting into developing with them a pain, but making me jump through > the > > > hoop of setting up LDAP may very well have changed that. > > > > > > These unsecure instances of NiFi out there are not our community's > > > fault. I suppose we're worried about getting splattered by bad press? > > > > > > On 2/10/21 5:47 AM, Bryan Bende wrote: > > > > I agree with the overall idea, although I would think it requires a > > > > major release to make this kind of change to the default behavior. > > > > > > > > Also, we have always avoided NiFi being a store of usernames and > > > > passwords, so we don't have a login provider that uses a local file > or > > > > a database, we've always said you connect to LDAP/AD for that. > > > > > > > > Obviously it can be implemented, but just pointing out that we'd have > > > > to change our stance here if we want to provide a default username > and > > > > password to authenticate with. > > > > > > > > On Tue, Feb 9, 2021 at 11:25 PM Andrew
Re: [discuss] we need to enable secure by default...
Having NiFi enforce authentication by default seems like the right way to go, especially given the capabilities of the system. Bryan raises a good point about storage of account information, so weighing the positives and negatives of various identity providers should be considered. Following on Joe's point about disabling plain HTTP, one option could be generating both client and server certificates and using Mutual TLS for authentication. This would obviously require installing the client certificate in a browser, which is not trivial, but could be part of an installation guide. This approach definitely provides a high barrier of entry of new users, but provides a strong level of security while avoiding the need for some other identity provider service to be configured. As others have mentioned, this seems necessary to address the situation of someone installing NiFi without a full understanding of the configuration required, so it is important to keep the audience in mind when evaluating a solution. Regards, David Handermann On Wed, Feb 10, 2021 at 7:39 AM Bryan Bende wrote: > Just to clarify, I was not suggesting that we make a default secure > setup that requires LDAP. > > I was just saying that in order to provide a default secure setup, > we'd have to provide a login identity provider implementation that is > backed by a file or database table, which in the past we decided > against. > > On Wed, Feb 10, 2021 at 8:28 AM Russell Bateman > wrote: > > > > I second the concerns expressed, but second especially Bryan's pointing > > out that requiring LDAP/AD to be set up in order even to begin to use > > our framework would be a bit onerous for developers just interested in > > getting work done and a barrier to considering the framework should it > > be erected a little too high. Should we at least glance at how this is > > solved by the likes of other projects, Kafka and Cassandra come to mind, > > even if it means resorting to a store of a name or two? I didn't find > > getting into developing with them a pain, but making me jump through the > > hoop of setting up LDAP may very well have changed that. > > > > These unsecure instances of NiFi out there are not our community's > > fault. I suppose we're worried about getting splattered by bad press? > > > > On 2/10/21 5:47 AM, Bryan Bende wrote: > > > I agree with the overall idea, although I would think it requires a > > > major release to make this kind of change to the default behavior. > > > > > > Also, we have always avoided NiFi being a store of usernames and > > > passwords, so we don't have a login provider that uses a local file or > > > a database, we've always said you connect to LDAP/AD for that. > > > > > > Obviously it can be implemented, but just pointing out that we'd have > > > to change our stance here if we want to provide a default username and > > > password to authenticate with. > > > > > > On Tue, Feb 9, 2021 at 11:25 PM Andrew Grande > wrote: > > >> Mysql has been generating an admin password on default installs for, > like, > > >> forever. This workflow should be familiar for many users. > > >> > > >> I'd suggest taking the automation tooling into account and how a > production > > >> rollout (user-provided password) would fit into the workflow. > > >> > > >> Andrew > > >> > > >> On Tue, Feb 9, 2021, 8:15 PM Tony Kurc wrote: > > >> > > >>> Joe, > > >>> In addition to your suggestions, were you thinking of making this > processor > > >>> disabled by default as well? > > >>> > > >>> Tony > > >>> > > >>> > > >>> On Tue, Feb 9, 2021, 11:04 PM Joe Witt wrote: > > >>> > > Team > > > > While secure by default may not be practical perhaps ‘not blatantly > wide > > open’ by default should be adopted. > > > > I think we should consider killing support for http entirely and > support > > only https. We should consider auto generating a user and password > and > > possibly server cert if nothing is configured and log the generated > user > > and password. Sure it could still be configured to be non secure > but > > >>> that > > would truly be an admins fault. Now its just ‘on’ > > > > This tweet is a great example of why > > > > https://twitter.com/_escctrl_/status/1359280656174510081?s=21 > > > > > > Who agrees? Who disagrees? Please share ideas. > > > > Thanks > > >
Re: [discuss] we need to enable secure by default...
Just to clarify, I was not suggesting that we make a default secure setup that requires LDAP. I was just saying that in order to provide a default secure setup, we'd have to provide a login identity provider implementation that is backed by a file or database table, which in the past we decided against. On Wed, Feb 10, 2021 at 8:28 AM Russell Bateman wrote: > > I second the concerns expressed, but second especially Bryan's pointing > out that requiring LDAP/AD to be set up in order even to begin to use > our framework would be a bit onerous for developers just interested in > getting work done and a barrier to considering the framework should it > be erected a little too high. Should we at least glance at how this is > solved by the likes of other projects, Kafka and Cassandra come to mind, > even if it means resorting to a store of a name or two? I didn't find > getting into developing with them a pain, but making me jump through the > hoop of setting up LDAP may very well have changed that. > > These unsecure instances of NiFi out there are not our community's > fault. I suppose we're worried about getting splattered by bad press? > > On 2/10/21 5:47 AM, Bryan Bende wrote: > > I agree with the overall idea, although I would think it requires a > > major release to make this kind of change to the default behavior. > > > > Also, we have always avoided NiFi being a store of usernames and > > passwords, so we don't have a login provider that uses a local file or > > a database, we've always said you connect to LDAP/AD for that. > > > > Obviously it can be implemented, but just pointing out that we'd have > > to change our stance here if we want to provide a default username and > > password to authenticate with. > > > > On Tue, Feb 9, 2021 at 11:25 PM Andrew Grande wrote: > >> Mysql has been generating an admin password on default installs for, like, > >> forever. This workflow should be familiar for many users. > >> > >> I'd suggest taking the automation tooling into account and how a production > >> rollout (user-provided password) would fit into the workflow. > >> > >> Andrew > >> > >> On Tue, Feb 9, 2021, 8:15 PM Tony Kurc wrote: > >> > >>> Joe, > >>> In addition to your suggestions, were you thinking of making this > >>> processor > >>> disabled by default as well? > >>> > >>> Tony > >>> > >>> > >>> On Tue, Feb 9, 2021, 11:04 PM Joe Witt wrote: > >>> > Team > > While secure by default may not be practical perhaps ‘not blatantly wide > open’ by default should be adopted. > > I think we should consider killing support for http entirely and support > only https. We should consider auto generating a user and password and > possibly server cert if nothing is configured and log the generated user > and password. Sure it could still be configured to be non secure but > >>> that > would truly be an admins fault. Now its just ‘on’ > > This tweet is a great example of why > > https://twitter.com/_escctrl_/status/1359280656174510081?s=21 > > > Who agrees? Who disagrees? Please share ideas. > > Thanks >
Re: [discuss] we need to enable secure by default...
I second the concerns expressed, but second especially Bryan's pointing out that requiring LDAP/AD to be set up in order even to begin to use our framework would be a bit onerous for developers just interested in getting work done and a barrier to considering the framework should it be erected a little too high. Should we at least glance at how this is solved by the likes of other projects, Kafka and Cassandra come to mind, even if it means resorting to a store of a name or two? I didn't find getting into developing with them a pain, but making me jump through the hoop of setting up LDAP may very well have changed that. These unsecure instances of NiFi out there are not our community's fault. I suppose we're worried about getting splattered by bad press? On 2/10/21 5:47 AM, Bryan Bende wrote: I agree with the overall idea, although I would think it requires a major release to make this kind of change to the default behavior. Also, we have always avoided NiFi being a store of usernames and passwords, so we don't have a login provider that uses a local file or a database, we've always said you connect to LDAP/AD for that. Obviously it can be implemented, but just pointing out that we'd have to change our stance here if we want to provide a default username and password to authenticate with. On Tue, Feb 9, 2021 at 11:25 PM Andrew Grande wrote: Mysql has been generating an admin password on default installs for, like, forever. This workflow should be familiar for many users. I'd suggest taking the automation tooling into account and how a production rollout (user-provided password) would fit into the workflow. Andrew On Tue, Feb 9, 2021, 8:15 PM Tony Kurc wrote: Joe, In addition to your suggestions, were you thinking of making this processor disabled by default as well? Tony On Tue, Feb 9, 2021, 11:04 PM Joe Witt wrote: Team While secure by default may not be practical perhaps ‘not blatantly wide open’ by default should be adopted. I think we should consider killing support for http entirely and support only https. We should consider auto generating a user and password and possibly server cert if nothing is configured and log the generated user and password. Sure it could still be configured to be non secure but that would truly be an admins fault. Now its just ‘on’ This tweet is a great example of why https://twitter.com/_escctrl_/status/1359280656174510081?s=21 Who agrees? Who disagrees? Please share ideas. Thanks
Re: [discuss] we need to enable secure by default...
I agree with the overall idea, although I would think it requires a major release to make this kind of change to the default behavior. Also, we have always avoided NiFi being a store of usernames and passwords, so we don't have a login provider that uses a local file or a database, we've always said you connect to LDAP/AD for that. Obviously it can be implemented, but just pointing out that we'd have to change our stance here if we want to provide a default username and password to authenticate with. On Tue, Feb 9, 2021 at 11:25 PM Andrew Grande wrote: > > Mysql has been generating an admin password on default installs for, like, > forever. This workflow should be familiar for many users. > > I'd suggest taking the automation tooling into account and how a production > rollout (user-provided password) would fit into the workflow. > > Andrew > > On Tue, Feb 9, 2021, 8:15 PM Tony Kurc wrote: > > > Joe, > > In addition to your suggestions, were you thinking of making this processor > > disabled by default as well? > > > > Tony > > > > > > On Tue, Feb 9, 2021, 11:04 PM Joe Witt wrote: > > > > > Team > > > > > > While secure by default may not be practical perhaps ‘not blatantly wide > > > open’ by default should be adopted. > > > > > > I think we should consider killing support for http entirely and support > > > only https. We should consider auto generating a user and password and > > > possibly server cert if nothing is configured and log the generated user > > > and password. Sure it could still be configured to be non secure but > > that > > > would truly be an admins fault. Now its just ‘on’ > > > > > > This tweet is a great example of why > > > > > > https://twitter.com/_escctrl_/status/1359280656174510081?s=21 > > > > > > > > > Who agrees? Who disagrees? Please share ideas. > > > > > > Thanks > > > > >
Re: [discuss] we need to enable secure by default...
Mysql has been generating an admin password on default installs for, like, forever. This workflow should be familiar for many users. I'd suggest taking the automation tooling into account and how a production rollout (user-provided password) would fit into the workflow. Andrew On Tue, Feb 9, 2021, 8:15 PM Tony Kurc wrote: > Joe, > In addition to your suggestions, were you thinking of making this processor > disabled by default as well? > > Tony > > > On Tue, Feb 9, 2021, 11:04 PM Joe Witt wrote: > > > Team > > > > While secure by default may not be practical perhaps ‘not blatantly wide > > open’ by default should be adopted. > > > > I think we should consider killing support for http entirely and support > > only https. We should consider auto generating a user and password and > > possibly server cert if nothing is configured and log the generated user > > and password. Sure it could still be configured to be non secure but > that > > would truly be an admins fault. Now its just ‘on’ > > > > This tweet is a great example of why > > > > https://twitter.com/_escctrl_/status/1359280656174510081?s=21 > > > > > > Who agrees? Who disagrees? Please share ideas. > > > > Thanks > > >
Re: [discuss] we need to enable secure by default...
Joe, In addition to your suggestions, were you thinking of making this processor disabled by default as well? Tony On Tue, Feb 9, 2021, 11:04 PM Joe Witt wrote: > Team > > While secure by default may not be practical perhaps ‘not blatantly wide > open’ by default should be adopted. > > I think we should consider killing support for http entirely and support > only https. We should consider auto generating a user and password and > possibly server cert if nothing is configured and log the generated user > and password. Sure it could still be configured to be non secure but that > would truly be an admins fault. Now its just ‘on’ > > This tweet is a great example of why > > https://twitter.com/_escctrl_/status/1359280656174510081?s=21 > > > Who agrees? Who disagrees? Please share ideas. > > Thanks >
