[
https://issues.apache.org/jira/browse/NIFI-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15638630#comment-15638630
]
ASF GitHub Bot commented on NIFI-2652:
--------------------------------------
GitHub user alopresto opened a pull request:
https://github.com/apache/nifi/pull/1186
NIFI-2652 [WIP] Handle encrypted config key migration
Submitting a WIP PR because other features depend on this work. There is an
unrelated test failure that I got locally after rebasing against master, so I
will investigate that, but the module where I did all of this work is fine.
I will also update the Admin Guide with instructions for key migration and
squash these commits.
---
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number
you are trying to resolve? Pay particular attention to the hyphen "-" character.
- [x] Has your PR been rebased against the latest commit within the target
branch (typically master)?
- [o] Is your initial contribution a single, squashed commit?
### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file, including the main
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [o] Have you ensured that format looks appropriate for the output in
which it is rendered?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build
issues and submit an update to your PR as soon as possible.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/alopresto/nifi NIFI-2652
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/1186.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1186
----
commit ad2b8d46a21a1642f88be9519ab535d60930dfe5
Author: Andy LoPresto <[email protected]>
Date: 2016-11-02T03:49:15Z
NIFI-2652 Implemented first pass of key migration logic and provided single
comprehensive unit test.
commit f7f88859e1b26e40d0abeb0670d2626ddf6f4714
Author: Andy LoPresto <[email protected]>
Date: 2016-11-03T02:31:37Z
NIFI-2652 Added logic and unit test for all combinations of original
key/password and new key/password.
commit 283924dacaf6f7b4396334c4315d040da240eb71
Author: Andy LoPresto <[email protected]>
Date: 2016-11-05T04:08:02Z
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.
commit f28610a65e9245e9a8b2fe462efdcec8aa777331
Author: Andy LoPresto <[email protected]>
Date: 2016-11-05T04:11:48Z
NIFI-2652 Removed SCrypt mock from one unit test that did not need it. Two
offenders remain ignored.
commit df9c18f4aae1f1dd40631f37139b91646bfa4e4f
Author: Andy LoPresto <[email protected]>
Date: 2016-11-05T04:14:13Z
NIFI-2652 Removed SCrypt mock from one redundant unit test. One offender
remains ignored.
commit 23a150c52120f12a7f772dc655cf5d8e8eeee223
Author: Andy LoPresto <[email protected]>
Date: 2016-11-05T04:22:51Z
NIFI-2652 Removed SCrypt mock from one unit test that didn't need it. Test
pollution is removed and all tests pass.
commit f6144a491ad27f70cf562749e1b8da02364bb348
Author: Andy LoPresto <[email protected]>
Date: 2016-11-05T04:42:46Z
NIFI-2652 Added unit tests for negative cases for migration argument
parsing.
Cleaned up TODOs and comments.
----
> 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.2.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)
