[
https://issues.apache.org/jira/browse/NIFI-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405208#comment-16405208
]
ASF GitHub Bot commented on NIFI-4917:
--------------------------------------
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/2552
@pvillard31 no, we don't want the ALLOW_EXPLICIT_KEYTAB stuff in
nifi.properties for a couple of reasons. For one, it is really intended to be a
fairly short-lived thing - eventually we will want to remove the properties for
principal & keytab from the processors all together. They are allowed there now
only in order to ease the transition of upgrading, so that we don't immediately
force all users to reconfigure all processors that use keytabs. So adding it to
nifi.properties in that respect feels a bit odd.
Additionally, processors themselves don't have access to nifi.properties.
These are system-level properties, not intended to be used by processors.
(Processors probably could still get access to the properties if you really
want to desperately enough, but it would mean doing some rather hack-ish things
in code, I do believe, as they are not intended to be used by processors).
Finally, we don't want to allow someone to access the NiFiProperties class
and call setProperty in order to disable this checking.
> 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)
