jfrazee commented on a change in pull request #4843:
URL: https://github.com/apache/nifi/pull/4843#discussion_r583101760
##########
File path:
nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/services/azure/storage/ADLSCredentialsControllerService.java
##########
@@ -74,12 +75,56 @@
.addValidator(StandardValidators.BOOLEAN_VALIDATOR)
.build();
+ public static final PropertyDescriptor SERVICE_PRINCIPAL_TENANT_ID = new
PropertyDescriptor.Builder()
+ .name("service-principal-tenant-id")
+ .displayName("Service Principal Tenant ID")
+ .description("Tenant ID of the Azure Active Directory hosting the
Service Principal. The property is required when Service Principal
authentication is used.")
+ .sensitive(true)
+ .required(false)
+ .addValidator(StandardValidators.NON_BLANK_VALIDATOR)
+
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
Review comment:
I don't think the parameter contexts gets at the original desire since
you'd have to know in advance which and how many parameters to create, but
maybe since it's a new new feature, there's no harm in not allowing EL. We can
change our mind later without creating any upgrade issues. The opposite isn't
true if we try to remove it later.
The "right" thing to do here could be to say that the use case should use
managed identities, or _maybe_ SAS tokens.
Question: how much pain do you think would be induced by rolling this back
on Access Keys?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
