[
https://issues.apache.org/jira/browse/NIP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard reassigned NIP-16:
---------------------------------
Assignee: Pierre Villard
> Parameter Tags
> --------------
>
> Key: NIP-16
> URL: https://issues.apache.org/jira/browse/NIP-16
> Project: NiFi Improvement Proposal
> Issue Type: Improvement
> Reporter: Pierre Villard
> Assignee: Pierre Villard
> Priority: Major
>
> This NIP is for adding support for Parameter Tags.
> Most parameter providers that we have in NiFi are talking to systems that
> implement the option to define tags that are just key/value pairs of strings.
> Having this information available with the parameters could be used by NiFi
> to inform some decisions such as deciding if a parameter is sensitive or not.
> At the moment, when we fetch parameters in the UI for a given parameter
> provider, the user has to decide which parameters are sensitive and which are
> not. There could be the option of defaulting everything to sensitive unless a
> specific tag has been set. In that case a parameter could be considered as
> non sensitive if and only if an expected tag has been set on the parameter in
> the external provider. This also increases the security when there is a
> separation of duties between the NiFi admin and whoever is in charge of the
> corresponding secrets.
> While this improvement would not change anything in the way NiFi is working
> with external parameters as of today, this could be used by the upcoming
> connectors concept to automatically decide if a value is sensitive or not
> without leaving this up to the user.
> The change is fairly limited and straightforward:
> * introduce public class ParameterTag in org.apache.nifi.parameter that is
> just with two strings key and value
> * update the class Parameter to have a List<ParameterTag> tags
> The idea of adding a new class instead of just a Map<String, String> is to
> have something more flexible in the future in case we would retain more
> information.
> There is no breaking change nor behavioural change as part of this proposal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)