[
https://issues.apache.org/jira/browse/NIFI-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645966#comment-15645966
]
ASF subversion and git services commented on NIFI-2652:
-------------------------------------------------------
Commit 89eb2ce28c835a56452162002c46101288e61203 in nifi's branch
refs/heads/master from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=89eb2ce ]
NIFI-2652 Provided key migration capability for encrypted config tool.
Added test resources with 128-bit encryption for environments without unlimited
strength cryptographic jurisdiction policies installed. All tests pass in both
128- and 256-bit environments. (+8 squashed commits)
Squashed commits:
[55f127c] NIFI-2652 Updated Admin Guide with instructions for encrypted config
key migration.
[05abf0e] NIFI-2652 Added unit tests for negative cases for migration argument
parsing.
Cleaned up TODOs and comments.
[9b73b22] NIFI-2652 Removed SCrypt mock from one unit test that didn't need it.
Test pollution is removed and all tests pass.
[d17ea77] NIFI-2652 Removed SCrypt mock from one redundant unit test. One
offender remains ignored.
[0924ce0] NIFI-2652 Removed SCrypt mock from one unit test that did not need
it. Two offenders remain ignored.
[cb5f850] NIFI-2652 Expanded unit test for combinations into individual tests
due to System.exit() only be capturable once per test.
Three tests which mock Scrypt for speed are temporarily ignored to perform test
pollution identification.
[c9cc5dc] NIFI-2652 Added logic and unit test for all combinations of original
key/password and new key/password.
[19713ec] NIFI-2652 Implemented first pass of key migration logic and provided
single comprehensive unit test.
This closes #1186.
> Handle multiple invocations of the encrypt-config tool
> ------------------------------------------------------
>
> Key: NIFI-2652
> URL: https://issues.apache.org/jira/browse/NIFI-2652
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Tools and Build
> Affects Versions: 1.0.0
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Labels: bootstrap, config, encryption, security
> Fix For: 1.1.0
>
>
> A discussion between [~jtstorck] and myself led to some possible scenarios
> with the {{encrypt-config}} tool. If a user invokes the tool multiple times
> on the same input files (updating in place), what should happen?
> Currently:
> The tool will not operate on any already-protected properties. So sensitive
> properties present and unprotected would be protected by the first
> invocation. If, before the second invocation, new sensitive values were
> provided in the {{nifi.properties}} file, they would be protected by the
> second invocation. If the user provides the same key/password as the first
> invocation, all properties would be encrypted with the same key. However, if
> a different key/password were used, the properties encrypted on the second
> invocation would be protected with a different key, and the new key would
> overwrite the key in the {{bootstrap.conf}} file, rendering the first set of
> properties unrecoverable.
> Possible solutions:
> On invocation of the tool, it first tries to read the existing key from
> {{bootstrap.conf}}. If no key is present, operate as normal.
> * Possibly require second entry of the key/password for confirmation to
> ensure it was not mistyped
> If a key *is* present (one of the following):
> * (Derive if necessary and) validate the key against the existing key and if
> it does not match, fail to run
> * Decrypt any existing encrypted properties with the persisted key and
> re-encrypt all sensitive properties with the new key
> The second option does not require the same key/password to be used
> repeatedly and also provides a mechanism for key migration/rollover.
> Another possible error scenario is if the first invocation was run with the
> JCE unlimited strength cryptographic jurisdiction policies not present (so
> the system was limited to 128-bit encryption) and subsequent invocations are
> run with the policies installed (in which case the tool will attempt to use
> 256-bit encryption). The individual properties will be marked with key
> strength available at the time they were encrypted, so this would also
> indicate the second option above is more robust. However, if the opposite
> flow occurs (256-bit available at first invocation, 128-bit subsequently),
> the tool will not be able to decrypt and re-encrypt the existing protected
> properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
