They are currently stored in the flow and encrypted the same way as sensitive properties. There has been discussion around sourcing sensitive parameters from external systems like Vault, but I’m not aware of anyone working on it. I could see value binding to external files, but also not sure of anyone working on that at the moment.
Rather than try to modify the flow xml, I think you could build the automation through the REST api, there are NiFi CLI commands for all the Interactions with parameter contexts. On Wed, Nov 4, 2020 at 4:40 PM Jeremy Taylor < jhtay...@everwatchsolutions.com> wrote: > Hi Bryan, > > Thank you for pointing me to parameter contexts as a possible answer to a > shortcoming we deal w/ for reasons of some challenges in handling different > environments with their different constraints and limitations we deal w/ > for those environments. I’ve glanced at the parameter contexts > documentation. > > > > So, the question I have immediately is where are these parameter contexts > stored? If they are stored in external files away from the nifi flow, then > this could be a huge help. If these are still stored within the nifi flow > file, then could there be a consideration to do an enhancement to store > these parameter contexts sets external to the nifi flow? The reason why I > ask is that we have some particular challenges we deal w/ for supporting > various environments. If these parameter contexts are still stored within > the flow, then we would still be forced to run XSLs against the nifi flow > to inject values, which is evil and what we are having to do now on the > SSLContextServices. We are desiring to get out of the business of running > XSLs to inject properties in flows. Thoughts? > > > > Regards, > > > > -- > > Jeremy H. Taylor > > Software Developer > > ACES Incorporated, an EverWatch Company > > Email: jeremy.tay...@acesinc.net > > Email: jhtay...@everwatchsolutions.com > > http://acesinc.net > > http://everwatchsolutions.com > > > > *From: *Bryan Bende <bbe...@gmail.com> > *Reply-To: *"users@nifi.apache.org" <users@nifi.apache.org> > *Date: *Wednesday, November 4, 2020 at 2:23 PM > *To: *"users@nifi.apache.org" <users@nifi.apache.org> > *Subject: *Re: enhancement request for NiFi variable registry support on > SSLContextServices > > > > Hi Jeremy, > > > > The recommended approach would be to use parameter contexts Introduced in > 1.10.0. All properties automatically support parameters and parameters can > be marked as sensitive and will be stored encrypted. > > > > Thanks, > > > > Bryan > > > > On Wed, Nov 4, 2020 at 1:37 PM Jeremy Taylor < > jhtay...@everwatchsolutions.com> wrote: > > Greetings, > > (Background: We are currently using NiFi 1.9.2 and hope to do a leap-frog > upgrade within the next 6 months.) > > > > Upon looking into a particular NiFi topic, my team members and I were > recently reminded of the following two things that we feel go together that > we would love to see NiFi support, which we have been in some ways desiring > for a while as we would like to use the NiFi variable registry additionally > in this way. > > 1) We would like for you to consider supporting all properties of the > SSLContextServices via the NiFi variable registries, which would mean they > would need to all support the NiFi expression language. > > 2) Tying into #1, we would like to be able to support passwords for SSL > keystores in the NiFi variable registry. To be able to do that, a new > command-line tool or an enhancement to EncryptTool would likely need to be > introduced that would allow us to pass in an encryption password or > hexadecimal key value from bootstrap.conf (available after EncryptTool is > run) to encrypt the SSL keystore passwords individually, give us an > encrypted string value on the command-line to place in a particular > property in the variable registry, and then store those encrypted passwords > in the NiFi variable registry properties files. And, then somehow, that > encryption scheme on the encrypted passwords on those particular keystore > passwords in the variable registry would need to play nice with NiFi on > start-up in terms of NiFi being able to decrypt those encrypted strings > enough to use them. > > > > Thoughts on these requests? > > > > Regards, > > > > -- > > Jeremy H. Taylor > > Software Developer > > ACES Incorporated, an EverWatch Company > > Email: jeremy.tay...@acesinc.net > > Email: jhtay...@everwatchsolutions.com > > http://acesinc.net > > http://everwatchsolutions.com > > -- > > Sent from Gmail Mobile > -- Sent from Gmail Mobile
