If your concern is the malicious insider using FetchHDFS to read the keytab as data from the filesystem, the *HDFS processors are marked as Restricted and require an additional explicit permission to be granted for users to configure them. At a file system interaction level, the NiFi Java processes are running as a single OS user, so all of the keytabs will need to be readable by that OS user, and the OS can’t detect which Java process is acting as which application user.
Andy LoPresto [email protected] [email protected] He/Him PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jul 30, 2020, at 8:10 AM, Mark Payne <[email protected]> wrote: > > Olivier, > > As Joe mentioned, it may help to further explain the exact scenario that you > are concerned about. > > But what I *think* you are concerned about is the following scenario: > - You have several different users developing flows in NiFi. > - You want the ability to give User A (and only User A) access to Keytab A by > creating a KeytabCredentialsService and giving User A READ Access to it. > - You want the ability to give User B (and only User B) access to Keytab B by > creating a KeytabCredentialsService and giving User B READ Access to it. > - If you do the above, but User A happens to know that Keytab B is stored at > /etc/keytabs/keytab-b, then all User A has to do is configure PutHDFS’s > Keytab property to “/etc/keytabs/keytab-b” instead of using the > KeytabCredentialsService. Then User A has access to User B’s keytab. > > Is that the scenario that you are concerned about? > > If yes, then the answer is to set the NIFI_ALLOW_EXPLICIT_KEYTAB Environment > Variable to a value of “false”. If you do that, then PutHDFS and related > processors that allow for either a KeytabCredentialsService or an explicit > keytab will become invalid (and therefore not runnable) if an explicit keytab > is used. This prevents User A from using Keytab A or Keytab B directly and > instead forces them to use no Keytab (which presumably will result in > authorization failure) or using the KeytabCrdentialsService, which you can > control READ access to. > > Does this help? > > Thanks > -Mark > >> On Jul 30, 2020, at 10:09 AM, Joe Witt <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hello >> >> Can you more fully explain the scenario you have in mind and what an >> intentionally malicious user might do? >> >> Thanks >> >> On Thu, Jul 30, 2020 at 6:54 AM oliver twix <[email protected] >> <mailto:[email protected]>> wrote: >> Hello, >> Getting deeper on using nifi in multitenant use cases, I am facing a >> security question: our nifi users must be able to interact with hdfs not >> sharing their credentials (keytabs). >> >> From what understood, keytabCredentialsService enable a way to give a policy >> based control over keytabs access. >> Where I miss something is that for a user to use an hdfs processor, it >> requires read/write filesystem permissions. In this context, any hdfs user >> is able to read the keytabs of any other users. So in my understanding, it >> breaks the initial objective of keytabCredentialsService to control keytabs >> accesses. >> >> Am I missing something ? Do you have a mean to avoid giving access to all >> keytabs stored on local filesystem? >> >> Olivier >> >> >
