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

Reply via email to