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:
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
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:
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
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:
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
