I'm on the opposite side of this discussion. I disagree that NiFi has to implement something immediately.
Now, I admit that I am old school, and feel that if you aren't capable of doing what is necessary to secure your own things, it's your own fault. But, I also realize, everyone on the internet seems to be coding now without the true understanding of what that means. I totally agree that a NiFi server open in the wild is a bad thing, and can be used by hackers. But, truly, NiFi isn't broken in the sense of security vulnerability. Mark mentions a default username password with a basic auth, which is actually no better than what that Twitter post had. The default username/password will be known to all, and that will be the first thing they attempt to get into those servers. (Or using the API.) My company has looked into the basic auth side of things, just so that even in a local network, people couldn't just find the server and do stuff on it. But, since there wasn't a NiFi "approved" method, we didn't pursue it. Instead, we run NiFi on a single machine that you have to log in to to be able to get to it, and the single machine has very limited users and the no access to NiFi from outside that machine. In a second instance, we have done a SSH tunnel into a Linux machine to access the NiFi running on that Linux machine when firewalls are not open to the NiFi port. Also, I run NiFi at home, and I don't have it connected to the Internet. I wouldn't want to deal with user/pass or HTTPS because there is no need for it. HTTP on its own isn't bad, it is the data individuals are sending that determines if HTTP shouldn't be used. My small website is just simple data with absolutely no usefulness to hackers, and therefore, doesn't really need HTTPS. My opinion is that we shouldn't take a knee-jerk reaction to this one Twitter post about what appears to be ONE NiFi server, unsecured on the Internet. Just my opposing opinion. John On Wednesday, February 10, 2021, 09:24:01 AM EST, Mark Payne <marka...@hotmail.com> 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
