Ranger-based NiFi policy descriptions

You can review how NiFi policies defined in Ranger align with NiFi's default file-based authorizer accessible through the NiFi user interface. The focus is on both controller-level policies and component-level policies, showing what access is granted to entities (users and servers) associated with them.

In Apache NiFi, policies are used to control access to various aspects of the system. You can define access policies at the controller or the component level. The combination of the two types of policies allows for a flexible access control mechanism.

Controller-level policies

Controller level policies provide a higher-level governance framework, overseeing global aspects of NiFi configuration and management. They are not tied to any specific component UUID. In Ranger, these policies are outlined as base policies and they show as

/<policy
     name>


Ranger policy (base policy)	NiFi policy	Ranger permission description
/resources¹	N/A	Allows Ranger to retrieve a list of NiFi policies. The server/user from the keystore used by Ranger must be granted read privileges to this resource.
/flow²	View user interface	Read/View: allows users to open and view the NiFi UI. Ensure that all users are granted read privileges to this policy, otherwise they will not be able to open the NiFi UI. If you run a NiFi cluster and/or access NiFi through a proxy, you need to grant read access to all nodes and any proxies involved. Write/Modify: N/A
/system	View system diagnostics	Read/View: provides access to system diagnostics, essential for users and nodes in a NiFi cluster to display system diagnostic stats returned by other nodes. Write/Modify: N/A
/controller	Access controller	Read/View: grants users and/or NiFi cluster nodes access to view: Controller thread pool configuration Cluster management page Controller-level reporting tasks Controller-level controller services Write/Modify: enables users and/or NiFi cluster nodes to create/modify: Controller thread pool configuration Cluster management page Controller-level reporting tasks Controller-level controller services
/counters	Access counters	Read/View: enables users to view counters. Write/Modify: enables users to modify counters.
/provenance	Query provenance	Read/View: allows users to run provenance queries or access provenance lineage graphs. Write/Modify: N/A
/restricted-components³	Access restricted components	Read/View: N/A Write/Modify: gives granted users ability to add components to the canvas that are tagged as 'restricted'.
/proxy⁴	Proxy user requests	Read/View: allows proxy servers to send request on behalf of other users. Write/Modify: required
/site-to-site	Retrieve site-to-site details	Read/View: allows other NiFi nodes to retrieve site-to-site details about the current NiFi.
/policies ^⁵	Access all policies	Read/View: allows users to view existing policies. Write/Modify: allows users to create new policies and modify existing policies.
/tenants ^⁵	Access users/user groups	Read/View: allows users to view currently authorized users and user groups. Write/Modify: allows users to add, delete, and modify existing users and user groups.
/parameter-contexts	Access parameter contexts	Read/View: allows users to view and use existing parameter contexts. Write/Modify: allows users to create, modify, and delete parameter contexts.

Component-level policies

Component level policies offer more granular access control, allowing administrators to regulate actions at the level of individual components within the NiFi data flow. These policies are based on assigned UUIDs, enforcing the access policies for specific components within NiFi, such as processors, input/output ports, or process groups.


Ranger component-based policies	NiFi component-based policies: component	Equivalent NiFi file based authorizer policy: policy	Ranger permissions description
/data-transfer/input-ports/<uuid>	Each NiFi remote input port is assigned a unique <uuid>	Receive data through site-to-site	Both read and write are required and should be granted to the source NIFi servers sending data to this NiFi through this input port.
/data-transfer/output-ports/<uuid>	Each NiFi remote output port is assigned a unique <uuid>	Send data through site-to-site	Both read and write are required and should be granted to the source NIFi servers pulling data from this NiFi through this output port.
/process-groups/<uuid>	Each NiFi process group is assigned a unique <uuid>	View component	Read: allows users to view process group details only.
/process-groups/<uuid>	Each NiFi process group is assigned a unique <uuid>	Modify component	Write: allows users to start, stop or delete process group. Users are able to added components inside process group and add controller services to process group.
/data/process-groups/<uuid>	Each NiFi process group is assigned a unique <uuid>	View data	Read: allows users to view data was processed by components in this process group and list queues.
/data/process-groups/<uuid>	Each NiFi process group is assigned a unique <uuid>	Modify data	Write: allows users to empty queues/purge data from queues within process group.
/policies/process-groups/<uuid>^⁶	Each NiFi process group is assigned a unique <uuid>	View policies	Read: N/A in Ranger
/policies/process-groups/<uuid>^⁶	Each NiFi process group is assigned a unique <uuid>	Modify policies	Write: N/A in Ranger
/processors/<uuid>	Each NiFi processor is assigned a unique <uuid>	View component	Read: allows users to view processor configuration only.
/processors/<uuid>	Each NiFi processor is assigned a unique <uuid>	Modify component	Write: allows users to start, stop, configure and delete processor.
/data/processors/<uuid>	Each NiFi processor is assigned a unique <uuid>	View data	Read: allows users to view data processed by this processor and list queues on this processor's outbound connections.
/data/processors/<uuid>	Each NiFi processor is assigned a unique <uuid>	Modify data	Write: allows users to empty queues/purge data from this processor's outbound connections.
/policies/processors/<uuid>^⁶	Each NiFi processor is assigned a unique <uuid>	View policies	Read: N/A in Ranger
/policies/processors/<uuid>^⁶	Each NiFi processor is assigned a unique <uuid>	Modify policies	Write: N/A in Ranger
/controller-services/<uuid>	Each NiFi controller services is assigned a unique <uuid>	View component	Read: allows users to view controller service configuration.
/controller-services/<uuid>	Each NiFi controller services is assigned a unique <uuid>	Modify component	Write: allows users to enable, disable, configure and delete controller services.
/provenance-data/<component-type>/<component-UUID>	Each NiFi component is assigned a unique <uuid>	View provenance	Read: allows users to view provenance events generated by this component. Write: N/A in Ranger
/operation/<component-type>/<component-UUID>	Each NiFi component is assigned a unique <uuid>	Operate component	Read: N/A in Ranger Write: allows users to operate components by changing component run status (start/stop/enable/disable), remote port transmission status, or by terminating processor threads.

Each component is assigned a unique UUID, resulting in a distinct policy for each specific component. Component-level authorizations are inherited from the parent process group when no explicit processor or sub-process group component-level policy is defined. Ranger facilitates policy assignment using the '*' wildcard, providing a versatile approach to policy configuration.

In a NiFi cluster, all nodes must be granted the ability to view and modify component data in order for users to list or empty queues in processor component outbound connections. With Ranger, you can accomplish this by using a wildcard to grant all the NiFi nodes read and write permissions to the /data/* NiFi resource.

¹ No policies are available until this policy is manually added.

² All users must at a minimum be assigned to the /flow policy to be able to view the NiFi UI.

³ See NiFi Restricted Components Policy Descriptions for more information.

⁴ All nodes in your NiFi cluster must be assigned to the /proxy policy.

⁵ In the context of Ranger, using this policy is unnecessary and serves no functional purpose.

⁶ Not needed when using Ranger.