Bryan, The usage of the NiFi CLI commands would appear to require usage of the NiFi Registry. We evaluated the NiFi registry 18 months ago and decided not to move forward with it yet. However, we likely will re-evaluate the NiFi Registry within the next 6 months based your answer. Nevertheless, there would be a slight preference of not having to involve using the NiFi registry to support the desire of property injection for sensitive values. The suggestion of using NiFi CLI commands seem reasonable, but it is the need of the NiFi Registry where we would be unable to quickly follow-up in responding.
I am not an expert on Vault, but on initial glance, it looks like something that can be installed on a local or server system we have as it doesn’t require being stored in a central location by a vendor. I believe that if these sensitive properties for SSL could be stored either an external file or in Vault, this would likely alleviate us from using XSL for SSL property injection if the usage of NiFi-CLI commands were to be taken out of the equation out of not yet adopting the NiFi Registry. Thus, if there could be further consideration here in light of folks not yet adopting the NiFi Registry yet for miscellaneous reasons, we would be fairly appreciative. Thoughts? Regards, -- Jeremy H. Taylor Software Developer ACES Incorporated, an EverWatch Company Washington, DC Email: jeremy.tay...@acesinc.net<mailto:jeremy.tay...@acesinc.net> Email: jhtay...@everwatchsolutions.com<mailto:jhtay...@everwatchsolutions.com> Mobile: 321.205.6202 http://acesinc.net<http://acesinc.net/> http://everwatchsolutions.com<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 5:22 PM To: "users@nifi.apache.org" <users@nifi.apache.org> Subject: Re: enhancement request for NiFi variable registry support on SSLContextServices --> parameter contexts 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<mailto: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<mailto:jeremy.tay...@acesinc.net> Email: jhtay...@everwatchsolutions.com<mailto:jhtay...@everwatchsolutions.com> http://acesinc.net<http://acesinc.net/> http://everwatchsolutions.com<http://everwatchsolutions.com/> From: Bryan Bende <bbe...@gmail.com<mailto:bbe...@gmail.com>> Reply-To: "users@nifi.apache.org<mailto:users@nifi.apache.org>" <users@nifi.apache.org<mailto:users@nifi.apache.org>> Date: Wednesday, November 4, 2020 at 2:23 PM To: "users@nifi.apache.org<mailto:users@nifi.apache.org>" <users@nifi.apache.org<mailto: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<mailto: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<mailto:jeremy.tay...@acesinc.net> Email: jhtay...@everwatchsolutions.com<mailto:jhtay...@everwatchsolutions.com> http://acesinc.net<http://acesinc.net/> http://everwatchsolutions.com<http://everwatchsolutions.com/> -- Sent from Gmail Mobile -- Sent from Gmail Mobile
