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

Reply via email to