[
https://issues.apache.org/jira/browse/NIFI-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589210#comment-16589210
]
Bryan Bende commented on NIFI-5549:
-----------------------------------
Thanks for clarifying... what about the case where the cluster is not secured?
I know that is unrealistic in production, but in my test scenario it wasn't
secure so there was no TLS connection between nodes, but we still support the
encrypted sensitive properties even though not secure.
> Handle/prevent cluster nodes with different sensitive property keys
> -------------------------------------------------------------------
>
> Key: NIFI-5549
> URL: https://issues.apache.org/jira/browse/NIFI-5549
> Project: Apache NiFi
> Issue Type: Improvement
> Affects Versions: 1.7.1
> Reporter: Bryan Bende
> Assignee: Andy LoPresto
> Priority: Minor
>
> I was testing some scenarios with sensitive property keys and noticed the
> following behavior...
> Created a two node cluster and set the sensitive property key different on
> each node. The cluster started up fine and I added a processor with a
> sensitive property and set the value, this saved fine, but behind the scenes
> the local flow.xml.gz on each node has the value encrypted with a different
> key.
> I then stopped node 2 and deleted its flow.xml.gz and started it back up.
> When trying to inherit the flow from the cluster it failed because it can't
> decrypt the sensitive value, which then fails start up.
> One question would be, should the original cluster ever have started
> successfully in the first place?
> Presumably when node 1 started and became the coordinator, something could be
> done when the next node joins to ensure it has the same sensitive properties
> key and disallow it from joining if different.
> Another option would be to let nodes have different values, but somehow
> migrate the value after receiving it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
