I think Mike's mention about the tangential work that arises is very important to remember. Accordingly, the following means of a secure environment is provided more for consideration of how one project solved this than a suggestion explicitly for NiFi.
I like what boot2docker uses where they opt for secure by default, but provide the guide for people to change that should they explicitly choose to put the effort into that process. >From their documentation [1]: > TLS support > > By default, boot2docker runs docker with TLS enabled. It auto-generates > certificates and stores them in /home/docker/.docker inside the VM. The > boot2docker > up command will copy them to ~/.boot2docker/certs on the host machine > once the VM has started, and output the correct values for the > DOCKER_CERT_PATH and DOCKER_TLS_VERIFY environment variables. > > $(boot2docker shellinit) will also set them correctly. > > We strongly recommend against running Boot2Docker with an unencrypted > Docker socket for security reasons, but if you have tools that cannot be > easily switched, you can disable it by adding DOCKER_TLS=no to your > /var/lib/boot2docker/profile file on the persistent partition inside the > Boot2Docker virtual machine (use boot2docker ssh sudo vi > /var/lib/boot2docker/profile). > The analog is that NiFi would generate the associated certificates and configuration if secure properties aren't explicitly defined in the properties via the bootstrapping portion of the startup process. The part that makes me hesitant to consider this are the varied environments that NiFi can run in and the tools needed for each environment. boot2docker benefits from having a custom image that has the needed tools to perform this auto-generation that is identical. One path could be to leverage something like Bouncy Castle in a utility that creates these, but again, becomes another development effort and item to maintain. [1] https://github.com/boot2docker/boot2docker/blob/master/README.md On Mon, Feb 16, 2015 at 10:09 AM, Corey Flowers <[email protected]> wrote: > I like the idea of the annoying banner. You could place it in the bar, > near the area surrounding the "refresh" text for graph control or even take > it a step further and add an indicator on the graph for secure or not, > similar to the lock on site-to-site connections. > > Sent from my iPhone > > > On Feb 16, 2015, at 8:44 AM, Daniel Bress <[email protected]> > wrote: > > > > Joe, > > I think this is a really good idea. > > > > I think you could solve 1 and 2 by providing an annoying-ish > banner/icon that reminds you that you are running in an insecure mode, that > when clicked takes you to the (to-be-completed) section of the admin guide. > > > > Dan Bress > > Software Engineer > > ONYX Consulting Services > > > > ________________________________________ > > From: Mike Drob <[email protected]> > > Sent: Sunday, February 15, 2015 9:08 PM > > To: [email protected] > > Subject: Re: [discuss] How to make nifi secure - or at least not > insecure by default > > > > Inline. > > > >> On Sun, Feb 15, 2015 at 12:10 PM, Joe Witt <[email protected]> wrote: > >> > >> Hello > >> > >> Received a note today about this tweet: > >> > >> https://twitter.com/silascutler/status/566983203232428033 > >> > >> It is a great reminder about our responsibility to provide secure > software. > >> > >> Out of the box NiFi starts up in a non-secure mode that is an HTTP > >> port to which anyone that can access it can command and control nifi > >> as an anonymous user. > >> > >> We do provide configuration options for setting up proper HTTPS with > >> 2-way SSL where the client's browser can establish trust in the > >> server, the server can establish trust in the client, the server can > >> establish the client identity by pulling the DN from the cert, and the > >> server can authorize the user for various roles based on a pluggable > >> authorization scheme. > >> > >> The basic dilemma is how can we best balance out of the box usability > >> and approach-ability with security. > >> > >> Ideas I'd propose: > >> 1) In the UI provide a constant (and annoying in nature) reminder of a > >> non-secure config > > Sure. > > > > 2) Emphasize documentation, tooling, etc.. that makes it easy as > >> possible for users to establish secure configurations. > > Be careful what you bite off here. Off-loading to existing tools is a > great > > way to keep your developers sane. > > > > 3) Add support for other identity mechanisms (like what?) > > Kerberos? AD? > > > >> > >> If folks have ideas on what the right balance is please share. What > >> we have now doesn't seem like the right answer and feels irresponsible > >> knowing that folks will not secure their instances properly. > >> > >> Thanks > >> Joe > >> >
