[
https://issues.apache.org/jira/browse/NIFI-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405389#comment-16405389
]
ASF GitHub Bot commented on NIFI-4917:
--------------------------------------
Github user bbende commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2552#discussion_r175535507
--- Diff: nifi-nar-bundles/pom.xml ---
@@ -207,6 +207,11 @@
<version>1.6.0-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
+ <dependency>
+ <groupId>org.apache.nifi</groupId>
+
<artifactId>nifi-kerberos-credentials-service-api</artifactId>
+ <version>1.6.0-SNAPSHOT</version>
--- End diff --
I think we should mark this provided here like the other API modules, so
that the default behavior for other NARs is to use this as provided, and they
would have to override if they really want to include it in their own NAR.
> Create a new Controller Service for specifying Keytabs
> ------------------------------------------------------
>
> Key: NIFI-4917
> URL: https://issues.apache.org/jira/browse/NIFI-4917
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
>
> Currently, we have many processors that use keytabs for authenticating with
> kerberos. These processors allow the user to specify the keytab and the
> principal. However, in a multi-tenant environment, this can be dangerous. If
> users are able to type in the name of any keytab, then they can use any
> keytab that the user running nifi has access to. Additionally, they can use
> any principal within that keytab.
> Using the @Restricted annotation is not really enough because you need that
> permission just to use PutHDFS, for example. But you shouldn't have access to
> all Keytabs just because you need access to HDFS. NIFI-4885 provides the
> ability to make these restrictions more granular. But we need the ability to
> specify the keytab & principal external to the processors. This gives users
> the ability to control who is able to specify the Keytabs & Principals that
> are allowed to be referenced. Further, they can change permissions on those
> Controller Services so that only the appropriate users can access them.
> We would like to avoid completely removing the Keytab and Principal
> properties in those processors for now, though, as it would make a lot of
> users' flows now invalid and can be a pain to update. As a result, we should
> allow either the Keytab/Principal properties to be referenced OR the
> controller service. Additionally, we should allow an Environment Variable to
> be set that will prevent use of the Keytab & Principal properties directly.
> This allows an admin to enforce this rule when he/she chooses to do so
> without immediately forcing a lot of property changes. Because Processors
> themselves don't have access to nifi.properties we don't want to add a
> property there. Also, System Properties are not a good idea because that
> could very easily be changed via a script, etc. Environment Variables offer
> the correct trade-offs, I believe, and can be easily configured within
> bin/nifi-env.sh for most users and could be easily updated in the batch file
> for Windows users as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
