Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

What policy in Ranger should be used for connections in Nifi?

avatar
Expert Contributor

Hi ,

I integrated Ranger and Nifi and also configured multi-tenancy.

I have a R/W to /proxy, R/W to /flow and R/W to all - nifi-resource.

Could you please help what policy should i add in Ranger for the connection ? i would like to list queue, empty queue ,etc.

I tried /flowfile-queues /View_Data but didn't work.

Thanks,

SJ

1 ACCEPTED SOLUTION

avatar
Super Mentor

@Sanaz Janbakhsh

The policies you have identified above /flow (grants users the ability to view the UI), /proxy (Allows NiFi nodes and proxy servers to proxy requests for users to other NiFi nodes), default "all-nifi-resources" assigns "*" which grants user here access to every policy.

The component level granular policies are based on the components assigned uuid. For connections, the policies are enforced based upon the processor component the connection originates from.

for example:

/remote-process-groups/<remote process group uuid>

/data/remote-process-groups/<remote process group uuid>

/process-groups/<process group uuid>

/data/process-groups/<process group uuid>

/processors/<processor uuid>

/data/processors/<processor uuid>

There will be a unique policy for each and every component based on the specific components assigned uuid available.

Component level authorizations are inherited from the parent process group when no specific processor, remote-process-group, or sub process group component level policy is set.

So for a user to be able to view the FlowFiles in a connection (list queue), they must be granted "read" for the component (/data/processors/<processor uuid>) from which that connection originated. Access can be granted via inheritance from a parent process group instead by granting the user "read" to a parent process group (/data/process-groups/<process group uuid>) that contains the processor component.

For a user to be able to empty a queue (empty queue), they must be granted "write" in the same manor as above for "read".

If you user was added to the default "all-nifi-resources" in Ranger, then they already have read and write to all NiFi policies. Effectively they are a NiFi admin user.

In addition to to user being granted the ability to "read" (list queue) and "write" (empty queue), the same must be granted for all node in your NiFi cluster. This is commonly done by adding a new policy in Ranger that uses the following NiFi resource Identifier:

19565-screen-shot-2017-07-25-at-95739-am.png

This policy would be assigned to all nodes and and include both "read" and "write" permissions. Why is this needed? When you login in to a NIFi cluster, you are logging in to only one node. When you make a request to list a queue, you expect to see results from all nodes in your cluster. So the node you are logged in to makes a request to all nodes to return there queue list. So the originating node must be granted the ability to view the other nodes data. The same holds true when you make a request to empty a queue while logged in to one node of a cluster. That node must be able to request that the other nodes empty their queue as well.

Thank you,

Matt

View solution in original post

7 REPLIES 7

avatar
Expert Contributor

I also granted myself R/W access to /province policy but still no luck.

avatar
Super Mentor

@Sanaz Janbakhsh

The policies you have identified above /flow (grants users the ability to view the UI), /proxy (Allows NiFi nodes and proxy servers to proxy requests for users to other NiFi nodes), default "all-nifi-resources" assigns "*" which grants user here access to every policy.

The component level granular policies are based on the components assigned uuid. For connections, the policies are enforced based upon the processor component the connection originates from.

for example:

/remote-process-groups/<remote process group uuid>

/data/remote-process-groups/<remote process group uuid>

/process-groups/<process group uuid>

/data/process-groups/<process group uuid>

/processors/<processor uuid>

/data/processors/<processor uuid>

There will be a unique policy for each and every component based on the specific components assigned uuid available.

Component level authorizations are inherited from the parent process group when no specific processor, remote-process-group, or sub process group component level policy is set.

So for a user to be able to view the FlowFiles in a connection (list queue), they must be granted "read" for the component (/data/processors/<processor uuid>) from which that connection originated. Access can be granted via inheritance from a parent process group instead by granting the user "read" to a parent process group (/data/process-groups/<process group uuid>) that contains the processor component.

For a user to be able to empty a queue (empty queue), they must be granted "write" in the same manor as above for "read".

If you user was added to the default "all-nifi-resources" in Ranger, then they already have read and write to all NiFi policies. Effectively they are a NiFi admin user.

In addition to to user being granted the ability to "read" (list queue) and "write" (empty queue), the same must be granted for all node in your NiFi cluster. This is commonly done by adding a new policy in Ranger that uses the following NiFi resource Identifier:

19565-screen-shot-2017-07-25-at-95739-am.png

This policy would be assigned to all nodes and and include both "read" and "write" permissions. Why is this needed? When you login in to a NIFi cluster, you are logging in to only one node. When you make a request to list a queue, you expect to see results from all nodes in your cluster. So the node you are logged in to makes a request to all nodes to return there queue list. So the originating node must be granted the ability to view the other nodes data. The same holds true when you make a request to empty a queue while logged in to one node of a cluster. That node must be able to request that the other nodes empty their queue as well.

Thank you,

Matt

avatar
Expert Contributor

Hi Matt,

Still I cannot make the "list queue" and "empty queue" working. The screenshot is attached to my previous post. Any thoughts?

SJ

avatar
Super Mentor

@Sanaz Janbakhsh

You should look in your nifi-user.log file. When you attempt to perform the "List Queue", What log entries do you see?

Unfortunately, the attachment you provided does not tell me much since it does not include the "NiFi Resource Identifier" or users assigned to each of those policy names.

Did you create a policy that uses the "NiFi Resource Identifier" of "/data/*" and assign your single node's DN to it?

Another place you could check is the Ranger Audit. Filter on Result:Denied and try to list your queue.

Do you see any Denied audit lines for any "/data" resource similar to the below:

22382-screen-shot-2017-07-31-at-83516-am.png

The above is the result of me trying to perform list queue for my user "nifiuser1" when the node has not been properly authorized to READ the data. As you can see Ranger is reporting there is no policy authorizing my node's DN for the resource listed. The UUID in the resource is the UUID of the processor which owns the connection I was trying to list.

Once I added my policy that gives the node's DN READ/WRITE to "/data/*", i was able to list and empty this queue.

Thanks,

Matt

avatar
Expert Contributor

Hi Matt,

It is fixed now. I granted our single node's DN to all - nifi-resource. Thanks for the help.

avatar
Contributor

Thanks adding the nodes to all - nifi-resource policy fixed the same problem for me

avatar
Expert Contributor

Hi Matt,untitled.png

I have an admin role and so I am granted to /all-nifi-resource but still I cannot list the queue.

FYI:

1- I applied multi- tenancy in Ranger

2- for HDF we don't have any cluster and it is just single node.

I attached the policies that I created in Ranger. (I am pretty part of all of them) Any advice what I missed.

Thanks,

SJ