Hello, You are correct that currently variables cannot be marked as sensitive, and for that reason they currently shouldn't be used to store sensitive values since they will be stored in plain-text in the flow.xml.gz and also in the versioned flows saved to registry.
I do think the concept of sensitive variables makes sense, and it was discussed in detail on the dev list a while ago [1], but no one has taken on the effort to implement it yet. Currently the values of sensitive properties are stripped out when saving a flow to registry. When you import a flow the values then need to be set, but only one time and it is excluded from being considered as a local change, so in the future when a new version of the flow is saved to registry and then the prod flow is upgraded, it will retain that value. If you are automating deployments then you should be able to do almost the same thing you are doing with config files per environment, but just shift to sourcing the flow from registry, rather than from a template (I assume that is what is you are doing now). The NiFi CLI [2] has commands to deploy the flow, but layering on the sensitive values is something that would have to be done in a tool/scripts that wrap the CLI. It could be a nice addition to the CLI to take a config file and a process group id and populate all of the necessary values. -Bryan [1] https://markmail.org/thread/53fzpsjbkp3uyxhb [2] https://github.com/apache/nifi/tree/master/nifi-toolkit/nifi-toolkit-cli On Tue, Sep 4, 2018 at 11:12 AM, Jonathan Meran <jonathan.me...@sonos.com> wrote: > Hello, > > I am looking for some guidance on managing sensitive property values for > things such as credentials in a DBCPConnectionPool within the NiFi Registry > Development Life Cycle. > > > > Currently we have rolled our own deployment tool in which we manage > configuration files per environment (Dev, QA, Prod, etc) and use the NiFi > API to deploy our Process Group and all the environment-specific properties. > We are looking to make the switch to using NiFi Registry instead of our own > tool but I don’t see a way to properly manage secrets. > > > > I believe we could use the Variable Registry but I have a few concerns with > that approach: > > Not all Processors and Controller Services support Expression Language so we > may have limitations with referencing properties and secrets inside the > Variable Registry. > There is no way (that I can tell) to mark a Variable as “sensitive” so that > it is write-only and not readable by other NiFi users after being set. > Are “sensitive” properties encrypted at rest inside flow.xml..gz? If so, > then we also lose encryption-at-rest if we use Variable Registry. > > > > I’m certain that every other NiFi Registry user will run into this same > issues so I am curious what others have done and what security trade-offs > they have made to continue on with the efficiency of using NiFi Registry. > > > > Thanks, > > Jon > > > > > >
