Thanks Joe! Do you know if there is an existing JIRA issue to track such a feature proposal (vault integration for flow secrets)? I’d be happy to create one if not.
Cannon On Tue, Feb 1, 2022 at 3:46 PM Joe Gresock <[email protected]> wrote: > Hi Cannon, > > Both the HashiCorp Vault Transit and Key/Value Sensitive Property > Providers are able to protect NiFi's configuration files (e.g., > nifi.properties, login-identity-providers.xml, and authorizers.xml). In > the case of the Transit implementation, you would use the encrypt-config.sh > tool from the NiFi Toolkit to encrypt properties in these files using the > Vault Transit Engine, and these will be decrypted using Vault as NiFi > starts up. The process is similar for the Key/Value implementation, but > the values of the properties are stored inside the Vault server instead of > being encrypted at rest in the configuration files. > > The properties in the flow.xml.gz file (e.g., your ConsumeMQTT processor > password) are protected by a different mechanism, and there is not > currently a Vault implementation that protects these. > > Hope this helps, > Joe > > On Tue, Feb 1, 2022 at 11:05 AM Cannon Palms <[email protected]> > wrote: > >> Hello, >> >> From what I understand from the documentation, the transit engine of >> Hashicorp Vault is definitely supported for system properties. It is also >> clear that the standard key/value engine of Hashicorp vault is supported >> for sensitive processor properties (e.g. the password used to connect to an >> MQTT broker in a ConsumeMQTT processor). >> >> What I cannot tell is if NiFi supports using the transit engine for these >> sensitive properties of processors. >> >> I'd like to ensure that these properties are encrypted at rest inside of >> the registry, but decrypted using the transit engine and a provided vault >> encryption key at runtime. >> >> Is this currently supported? Or is the only the standard key/value engine >> supported for such properties? >> >> Thanks, >> Cannon >> >
