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 <[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 > >>>>>>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
