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 <[email protected]> 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 <[email protected]> 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 < > [email protected]> > > 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 <[email protected]> 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 <[email protected] > > > >>> 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 <[email protected]> > >>> 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 <[email protected]> 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 <[email protected]> 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 > >>>>>>>> > >>> > >> > >
