You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Jeremy Taylor <jh...@everwatchsolutions.com> on 2020/11/04 18:37:31 UTC

enhancement request for NiFi variable registry support on SSLContextServices

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.taylor@acesinc.net<ma...@acesinc.net>
Email: jhtaylor@everwatchsolutions.com<ma...@everwatchsolutions.com>
http://acesinc.net<http://acesinc.net/>
http://everwatchsolutions.com<http://everwatchsolutions.com/>

Re: enhancement request for NiFi variable registry support on SSLContextServices

Posted by Bryan Bende <bb...@gmail.com>.
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 <
jhtaylor@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.taylor@acesinc.net
>
> Email: jhtaylor@everwatchsolutions.com
>
> http://acesinc.net
>
> http://everwatchsolutions.com
>
-- 
Sent from Gmail Mobile