[
https://issues.apache.org/jira/browse/NIFI-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405213#comment-16405213
]
ASF GitHub Bot commented on NIFI-4917:
--------------------------------------
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/2552
The logic above could be moved into a static method within
KerberosCredentialsService, but I would avoid doing so for a couple of reasons:
1. I'm not sure that all processors are already using the exactly same name
of the properties. And if not, then adding it to that interface would
complicate things.
2. Doing so would mean that we need to move the Property Descriptors
themselves into that interface as well. As described above, these are "legacy"
property descriptors that are intended to go away, so I would not want to add
them into the interface for the "new way to do things", if that makes sense.
> 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)
