[jira] [Assigned] (NIP-16) Parameter Tags

["Pierre Villard (Jira)" <ji...@apache.org>]

     [ 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)