Pierre Villard created NIP-33:
---------------------------------
Summary: 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
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)
