Support Questions

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

Nifi: What are some best practices to support a multi-tenant Team>Project heirarchy through access policies?

avatar

I have a secured nifi cluster that is identifying users via LDAP.

I wish to configure a security policy whereby multiple teams can use nifi for their multiple projects without risk of modifying or viewing other team's flows.

I understand that one can use ranger, or nifi's built-in authorization scheme, are there [dis]advantages to either approach?

The natural (naïve?) layout seems to be a process group for each team, and then each team may have multiple process groups underneath their team's process group representing projects. Are there any gotchas to be aware of with this setup?

One perceived gotcha is that this layout seems to clash with the ListSFTP->RPG->FetchSFTP pattern. A subgroup cannot directly receive RPG inputs, so anytime the List->RPG->Fetch pattern is used, an input port must be created at the root flow and then mapped all the way back into the sub process. This is a problem because this pattern will be common, and will require permissions on the root flow to create the input ports. Am I misunderstanding something, and is there a more elegant solution?

1 ACCEPTED SOLUTION

avatar
Super Mentor
hide-solution

This problem has been solved!

Want to get a detailed solution you have to login/registered on the community

Register/Login
4 REPLIES 4

avatar
Master Guru

You seem to have a good understanding of the situation...

There isn't really a big pro or con with NiFI's authorizer vs Ranger... If you are already using Ranger for other things then it gives you a nice central place to manage all policies across your enterprise and a nice way to look at audit logs. The current downside would be that when using an external authorizer like Ranger, NiFi's UI currently doesn't show anything about the policies, so you have to jump back and forth a bit between two UIs sometimes. This is only temporary though and in a future release there are plans to offer a read-only view of policies on the NiFi side when using an external authorizer. Sometimes it is helpful to start out with NiFi's authorizer to get an understanding of the policies before attempting to set them up in Ranger.

Regarding the RPG pattern, you are correct that this is one unfortunate scenario regarding multi-tenancy... I think the real way that this should be addressed is by creating a more user-friendly way to do load balancing of a connection across the cluster, most likely a special way to connect two components and indicate the connection should transfer data to each node across the cluster. The RPG approach is used simply because that is all that exists, but site-to-site was really meant for transfer between two separate instances.

An alternative option is always to have each team with its own NiFi instance and then they can manage the root canvas themselves, and they can send data across teams via site-to-site, but I realize this requires managing more clusters, just throwing it out there.

avatar

Thanks for the answer, it does seem like another mechanism besides RPG-to-self is needed to rebalance flowfiles generated on a single node.

avatar
Super Mentor
hide-solution

This problem has been solved!

Want to get a detailed solution you have to login/registered on the community

Register/Login

avatar

Thanks Matt, the pre-provisioned input port idea does seem workable.