"It would provide a list of variables that are readable to the current user
and one can be selected, just like allowable values or controller services.”
A person may have rights to configure nifi without knowing the “value” of
the secure db password ( for example ), but that doesn’t mean they
don’t have there rights to reference it.
On April 25, 2018 at 14:15:16, Bryan Bende (bbe...@gmail.com) wrote:
There is definitely room for improvement here.
Keep in mind that often the sensitive information is specific to a
given environment. For example you build a flow in dev with your
db.password. You don't actually want your dev db password to be
propagated to the next environment, but you do want to be able to set
a variable placeholder like ${db.password} and leave that placeholder
so you can just set that variable in the next environment. So to me
the goal here is how to handle secure variables.
Andy highlighted many of the issues, my proposal would be the following...
First, we can introduce a concept of a sensitive variable. This would
be something in the UI where a user can indicate a variable is
sensitive, maybe a checkbox, and then the framework can store these
values encrypted (currently all variable values are stored in plain
text because they aren't meant to be sensitive).
Second, we can introduce policies on sensitive variables so that we
can restrict who can read them elsewhere, just like policies on
controller services that determine which controller services show up
in the drop down of a processor.
Third, we introduce a new kind of PropertyDescriptor that allows
selecting a variable from the variable registry rather than free-form
expression language. It would provide a list of variables that are
readable to the current user and one can be selected, just like
allowable values or controller services. Ideally we can have a way to
still allow free form values for people who don't want to use
variables.
Fourth, anytime variables are evaluated from expression language we
would prevent evaluating any of these new sensitive variables since we
have no way of knowing if a user should have access to it from
free-form EL, so they can only be used from the special
PropertyDescriptors above.
If we put all this in place then when we save flows to the registry,
we can leave the variable place-holders in the sensitive properties,
and then when you import to the next environment you only need to edit
the variables section and not go through individual processors setting
sensitive properties.
On Wed, Apr 25, 2018 at 1:06 PM, Andy LoPresto <alopre...@apache.org>
wrote:
> 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
> [2] https://en.wikipedia.org/wiki/Hardware_security_module
> [3] https://www.vaultproject.io/
> [4] https://square.github.io/keywhiz/
> [5] https://issues.apache.org/jira/browse/NIFI-1831
> [6]
> https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap
> [7] 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
>
>
