Uploaded image for project: 'Apache NiFi'
  1. Apache NiFi
  2. NIFI-4917

Create a new Controller Service for specifying Keytabs

    XMLWordPrintableJSON

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6.0
    • Component/s: Extensions
    • Labels:
      None

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                markap14 Mark Payne
                Reporter:
                markap14 Mark Payne
              • Votes:
                2 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: