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