[ https://issues.apache.org/jira/browse/NIFI-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy LoPresto updated NIFI-2652: -------------------------------- Component/s: Tools and Build > 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)