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, <ottobackwa...@gmail.com> 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 <kdo...@apache.org> 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 <marka...@hotmail.com> > 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 <marka...@hotmail.com> > >> 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 <joe.w...@gmail.com> 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 <bbe...@gmail.com> > >> 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 < > >>>> r...@windofkeltia.com > >>>>>>> > >>>>>>>>> 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 < > >> apere...@gmail.com> > >>>>>>>>> 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 <tk...@apache.org> > >> 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 <joew...@apache.org> > >>>> 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 > >>>>>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
