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 <[email protected]> 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 <[email protected]> > wrote: > > > > Mark, > > > > Thanks for clarifying, that makes sense. > > > > Regards, > > David Handermann > > > > On Wed, Feb 10, 2021 at 8:41 AM Mark Payne <[email protected]> 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 < > >> [email protected]> 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 <[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 > >>>>>>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
