[
https://issues.apache.org/jira/browse/NIP-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard reassigned NIP-33:
---------------------------------
Assignee: Pierre Villard
> Allow Secrets to be Referenced by Non-Sensitive Connector Properties
> --------------------------------------------------------------------
>
> Key: NIP-33
> URL: https://issues.apache.org/jira/browse/NIP-33
> Project: NiFi Improvement Proposal
> Issue Type: Improvement
> Reporter: Pierre Villard
> Assignee: Pierre Villard
> Priority: Major
>
> Connectors let users configure an entire flow through a small set of typed
> properties. Properties declared with {{PropertyType.SECRET}} can be backed by
> a value from a Secrets Manager (resolved through a {{{}SecretReference{}}}),
> while all other property types must be given an explicit literal value. Today
> the framework strictly forbids a {{SECRET_REFERENCE}} on any
> non-{{{}SECRET{}}} property.
> However, users may want to store sensitive and non-sensitive information in
> the same place. A common example is a database connection: users want to
> store both the *username* and the *password* as secrets and reference both
> from the connector, so that the entire credential lives in one managed,
> rotatable, access-controlled place. The username property is not sensitive,
> so it cannot reference a secret today, forcing users to split a single
> credential across two management models (a managed secret for the password, a
> hand-entered literal for the username).
> The proposal touches the following all changes are additive):
> * *{{nifi-api}}* - a new enum and a new {{default}} method on the {{Secret}}
> interface (extension/public API).
> * *NiFi Configuration Files* - one new optional property in
> {{{}nifi.properties{}}}.
> * *{{nifi-web-api}}* - an additional optional field on the secret-listing
> DTO so REST clients (configuration UIs) can identify which secrets are
> eligible for non-sensitive properties.
> * *Framework internals* ({{{}nifi-framework-components{}}},
> {{{}nifi-framework-core{}}}) — populate the classification when adapting a
> parameter into a secret, and relax the connector property
> reference-validation gate accordingly. These are not public interfaces.
> * *Reference implementation* - the AWS Secrets Manager parameter provider,
> which already forwards source tags onto the parameters it produces, is used
> to demonstrate the feature end-to-end.
> The proposal is fully backward compatible and does *not* require a new major
> version.
> * The new {{Secret}} method is a {{default}} returning the
> existing-behaviour value ({{{}RESTRICTED{}}}), so all current {{Secret}}
> implementations compile and behave unchanged.
> * The new {{nifi.properties}} value has {*}no default{*}. When it is unset,
> every secret is {{RESTRICTED}} and behaviour is identical to today. The
> feature is strictly opt-in per deployment.
> * The validation change only ever {*}permits more{*}: a {{RESTRICTED}}
> secret on a non-sensitive property is rejected exactly as today, and a secret
> reference on a sensitive property is unaffected. No previously valid
> configuration becomes invalid.
> * The REST DTO change is an additive optional field.
> A secret is assigned one of two protection classifications:
> {code:java}
> package org.apache.nifi.components.connector;
> public enum PropertyProtectionType {
> /** The secret may only be referenced by sensitive (SECRET) properties.
> Default. */
> RESTRICTED,
> /** The secret owner has authorised it for use by any property, including
> non-sensitive ones. */
> UNRESTRICTED
> }
> {code}
> The {{Secret}} interface exposes the classification through a default method
> so existing implementations are unaffected:
> {code:java}
> public interface Secret {
> // ...existing methods...
> default PropertyProtectionType getPropertyProtectionType() {
> return PropertyProtectionType.RESTRICTED;
> }
> }
> {code}
> The classification originates from the {*}owner of the secret{*}, expressed
> as a tag on the secret in the backing system (e.g. an AWS Secrets Manager
> resource tag). The tag _name_ is configured per deployment through a new
> optional property:
> {code:java}
> # No default. When unset, all secrets are RESTRICTED (current behaviour).
> nifi.secrets.manager.unrestricted.tag.name= {code}
> A deployment chooses its own convention. A secret is classified UNRESTRICTED
> if the backing parameter carries a tag whose key equals the configured name
> and whose value equals true (case-insensitive). Presence of the tag alone is
> insufficient. This lets an owner set the value to false to keep a secret
> restricted explicitly. If the property is unset, classification is never
> evaluated and all secrets remain RESTRICTED.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
