[
https://issues.apache.org/jira/browse/NIFI-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452168#comment-16452168
]
Joseph Witt commented on NIFI-5119:
-----------------------------------
[~jomach] There is no support as of yet for the concept of a 'sensitive
variable' as highlighted here [1].
We do not send the value of a processor/component property to the flow registry
if that property is marked sensitive.
As a result when importing a versioned flow with sensitive properties on it
(regardless of whether those properties point at things from variable registry
or not) we cannot pull the values in on the initial import. However, after the
initial import and the user enters those sensitive values we can retain and
honor them.
We can certainly add a way for someone entering variables into the variable
registries of a given process group to flag that what they're entering is
sensitive, should be encrypted and never displayed in plain text. Things we
have to sort out then are what do we do with the encrypted sensitive value when
we publish the flow to the flow registry. It will be encrypted on the nifi
flow with the key of that nifi instance/cluster. If it were imported to
another instance/cluster with a different key (which should be the case) then
they'd not be able to decrypt and use it. We could perhaps have a key on the
registry side for it to be re-encrypted with that key acting as a broker for
ensuring the sensitive value is set. Then re-encrypted on the other flow,
etc.. Or we could just say sensitive variables never get published and must be
set locally in the respective variable registry instances. We have options but
all this needs to be explored and built.
Then there is the other matter of how to handle entering sensitive values on
component/processor properties when those are actually referencing this new
concept of sensitive variables. It is not enough for us to detect an EL
statement as there could be multiple EL statements or intermixed EL and static
values. We cannot then automatically treat a sensitive property referenced
variable as sensitive in the variable reg because it could be used otherwise
too, etc.. So, one option here is that we provide an additional entry mode for
fields whereby users indicate they want to select a specific variable and then
we let them enter/select a single one. This eliminates the ambiguity/etc..
I said all that to point out that we'd love to support this as well but the
design/implementation just isnt there. The way to work with it as-is is still
a huge step forward and we've not compromised security in doing it. I think
this JIRA could be rewritten to reflect these ideas and intent to improve it
but it should also be a feature/improvement and not a bug. It is working as
designed and we just need to keep improving it. But the concept is certainly
not broken and the benefits are huge.
[1]
https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#show-local-changes
> Pulling changes from Registry does not respect sensitive Informations on
> Destination
> ------------------------------------------------------------------------------------
>
> Key: NIFI-5119
> URL: https://issues.apache.org/jira/browse/NIFI-5119
> Project: Apache NiFi
> Issue Type: Bug
> Components: Variable Registry
> Affects Versions: 1.5.0, 1.6.0
> Environment: all
> Reporter: Jorge Machado
> Priority: Major
> Fix For: 1.7.0
>
>
> When pulling changes from registry if a sensitive variable is set then it
> gets reset to its default.
> I have found out a use case that destroys the complete concept of the
> Registry.
> # Setup a flow with a sensitive field on Nifi Server A.
> # Push that to Registry
> # Pull the Flow in Nifi Server B. (this is expected to be reseted because
> is the first time)
> # Make changes on Nifi Server B and Push
> # Pull the changes from Nifi Server A.
>
> On Step 5 the sensitive Information from Nifi Server A get's deleted.
> This breaks the whole concept IMHO.
> Relates to : NIFI-5028
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
