Hi Sivaprasanna, This was a topic that was briefly considered earlier in the lifecycle of the project, but was sidelined due to other developments. With the NiFi Registry project, there has been renewed interest in securing sensitive values in the flow and allowing for easier import/export/persistence. There is a placeholder Jira [1] which doesn’t capture significant information about the problem. I think a larger conversation needs to occur which covers the following points (at a minimum, there is plenty of room for additional concerns and use cases):
* How the sensitive values are secured (encryption, storage [HSM [2], Hashicorp
Vault [3], Square KeyWhiz [4], JCEKS, locally-encrypted file], location)
* User access control (granularity, integration with UAC policies in NiFi,
Ranger, users/groups, etc.)
* Exporting/persistence behavior (should a sensitive value entered in “dev” be
exported to “prod” (and more significantly, vice-versa), which instance(s) of
the Variable Registry are allowed to be referenced from each NiFi / Registry
node, etc.)
* Variable references (how does the tool differentiate between “${db.password}”
meaning “load the variable db.password” and a literal password like
“myPass${word!&”?
The original Jira for encrypted configuration files / properties [5] also
referenced some of these concepts in the abstract, and there is a rough
security roadmap in the wiki [6]. The Variable Registry design document [7]
specifically did not allow for sensitive values to be exposed via UI or API.
I think there is an appetite for a more complete solution to this problem as
you outlined, but I think there needs to be an extensive collection of actual
use cases, user expectations, and then technical discussion on the
implementation to solve this successfully. It’s a minefield where half-steps
will lead to user confusion, unmet expectations, and potentially severe
security vulnerabilities.
I changed the subject line to include [DISCUSS] to hopefully generate some more
interest here for other community members to weigh in. Thanks for getting the
conversation started.
[1] https://issues.apache.org/jira/browse/NIFI-2653
<https://issues.apache.org/jira/browse/NIFI-2653>
[2] https://en.wikipedia.org/wiki/Hardware_security_module
<https://en.wikipedia.org/wiki/Hardware_security_module>
[3] https://www.vaultproject.io/ <https://www.vaultproject.io/>
[4] https://square.github.io/keywhiz/ <https://square.github.io/keywhiz/>
[5] https://issues.apache.org/jira/browse/NIFI-1831
<https://issues.apache.org/jira/browse/NIFI-1831>
[6] https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap
<https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap>
[7] https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry
<https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry>
Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Apr 25, 2018, at 12:24 PM, Sivaprasanna <sivaprasanna...@gmail.com> wrote:
>
> Hi
>
> Since flowfile attributes and VariableRegistry is not suitable (not safe,
> to be specific), developers have to rely on manually configuring the
> sensitive values on the components (Processors & ControllerServices). And
> during CI/CD (using flow registry), the sensitive information are dropped
> and once imported to the next environment (QA or Prod), the user is
> expected to configure the sensitive information again, although for the
> first time. How about we introduce sort of a 'vault' that holds sensitive
> values which could possibly avoid this unnecessary step completely ?
>
> -
> Sivaprasanna
signature.asc
Description: Message signed with OpenPGP using GPGMail
