[
https://issues.apache.org/jira/browse/NIFI-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869679#comment-17869679
]
Bryan Bende commented on NIFI-13585:
------------------------------------
I'm not totally sure I follow everything here, but in general, all properties
are marked as sensitive when a component is ghosted because we don't have the
property descriptors to tell us which properties are sensitive and which ones
aren't. I suppose if the value of the property references a parameter when can
infer that if the parameter is not sensitive then the property couldn't have
been sensitive?
I think this overall issue may be the same as this one -
https://issues.apache.org/jira/browse/NIFI-11570
> When ghosting a component some properties should not be encrypted
> -----------------------------------------------------------------
>
> Key: NIFI-13585
> URL: https://issues.apache.org/jira/browse/NIFI-13585
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Pierre Villard
> Priority: Major
>
> Let's consider the following scenario:
> I have a flow definition with a RouteOnAttribute processor that is version X.
> This processor has dynamic properties to define the routing of the flowfiles,
> and the properties are referencing parameters. In the flow.json.gz, I can see:
> {code:java}
> {
> ...
> "type": "org.apache.nifi.processors.standard.RouteOnAttribute",
> "bundle": {
> "group": "org.apache.nifi",
> "artifact": "nifi-standard-nar",
> "version": "X"
> },
> "properties": {
> "1": "${#{test}:equals('1')}",
> "2": "${#{test}:equals('2')}",
> "Routing Strategy": "Route to Property name"
> },
> ...
> } {code}
> This flow is being deployed in an environment where we have multiple versions
> of RouteOnAttribute (Y and Z, but not X). When the flow is deployed, we're
> going to ghost the component. In that process, we're treating dynamic
> properties as sensitive by default because we don't know what to do with
> those and we want to be on the safe side. Because of this the values are
> encrypted, and in flow.json.gz, I can now see:
> {code:java}
> {
> ...
> "type": "org.apache.nifi.processors.standard.RouteOnAttribute",
> "bundle": {
> "group": "org.apache.nifi",
> "artifact": "nifi-standard-nar",
> "version": "X"
> },
> "properties": {
> "1": "enc{xxxxxxxxxxx}",
> "2": "enc{xxxxxxxxxxx}",
> "Routing Strategy": "enc{xxxxxxxxxxx}"
> },
> ...
> } {code}
> The problem is that if I now make this component version available, or if I
> remove version Y (to force the switch to version Z), and restart NiFi, NiFi
> won't be able to start anymore and will throw the below exception:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: The property '1' is a
> sensitive property so it can reference a Parameter only if there is no other
> context around the value. For instance, the value '#{abc}' is allowed but
> 'password#{abc}' is not allowed.
> at
> org.apache.nifi.controller.AbstractComponentNode.verifyCanUpdateProperties(AbstractComponentNode.java:392)
> at
> org.apache.nifi.controller.AbstractComponentNode.setProperties(AbstractComponentNode.java:277)
> at
> org.apache.nifi.flow.synchronization.StandardVersionedComponentSynchronizer.updateProcessor(StandardVersionedComponentSynchronizer.java:2771){code}
> In this case it fails because the property is sensitive and has a value that
> is mixing expression language and a parameter. The problem would be similar
> if the property is only referencing a parameter: it would fail saying that a
> sensitive property cannot reference a non-sensitive parameter.
> I think that NiFi behavior should be improved when ghosting the components
> and implement a better handling of the properties to only encrypt the
> properties that should and not encrypt properties referencing a non-sensitive
> parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
