NIFI service user ID

[#1]

Currently HDF 1.2 is running as user root. I am using HDP 2.3.2 so NIFI is not part of Ambari controlled list.

Since it is run as root, getHDFS or putHDFS processor uses a user keytab. How could I prevent a user A to create

a processor to use user B's keytab? In HDP 2.4 or later, do we have NIFI service user ID provisioned?

[#2]

If the NiFi process has access to keytab1 and keytab2 on the filesystem, then any use can enter either of those keytabs into a processor. You would need two separate NiFi instances each running as a different operating system user, lets say user1 and user2, and user1 only has filesystem access to keytab1, and user2 only has filesystem access to keytab2.

You can run NiFi as a user other than root by specifying a value for the run.as property in bootstrap.conf.

[#3]

Do you mean that each nifi user should have his/her own instance? There could be too many. Also is there any way to specify multiple instances per host?

[#4 · Accepted solution]

In general many users can share the same instance (these are not the same as OS users). In the NiFi 0.x baseline (HDF 1.2) users can have roles and roles can restrict what users can do. For example, a monitor can get a read only view of the UI and a data flow manager can change anything they want. In NiFi 1.x (HDF 2.0, not yet released) there will be a much finer grained security model where policies can be created for anything on the canvas to give specific users or groups access to an individual component (processor, process-group, etc.).

A keytab is a file on the operating system controlled by the standard operating system file permissions. If the NiFi process is running as an operating system user that can access that keytab file, then any NiFi user can go into the UI and create a PutHDFS processor and type in the path to that keytab, because its not based on the user accessing NiFi, its based on the OS user NiFi is running as.

The only way I could see preventing this was if files/keytabs could be defined as some kind of first-class resource in NiFi, and then policies could be created to limit which NiFi users could use those resources.