Access Policies

You can manage the ability for users and groups to view or modify NiFi resources using 'access policies'. There are two types of access policies that can be applied to a resource:

View - If a view policy is created for a resource, only the users or groups that are added to that policy are able to see the details of that resource.
Modify - If a resource has a modify policy, only the users or groups that are added to that policy can change the configuration of that resource.

You can create and apply access policies on both global and component levels.

Global Access Policies

Global access policies govern the following system level authorizations:


Policy	Privilege	Global Menu Selection	Resource Descriptor
view the UI	Allow users to view the UI	N/A	`/flow`
access the controller	Allows users to view/modify the controller including Reporting Tasks, Controller Services, and Nodes in the Cluster	Controller Settings	`/controller`
query provenance	Allows users to submit a Provenance Search and request Event Lineage	Data Provenance	`/provenance`
access restricted components	Allows users to create/modify restricted components assuming other permissions are sufficient. The restricted components may indicate which specific permissions are required. Permissions can be granted for specific restrictions or be granted regardless of restrictions. If permission is granted regardless of restrictions, the user can create/modify all restricted components.	N/A	`/restricted-components`
access all policies	Allows users to view/modify the policies for all components	Policies	`/policies`
access users/user groups	Allows users to view/modify the users and user groups	Users	`/tenants`
retrieve site-to-site details	Allows other NiFi instances to retrieve Site-To-Site details	N/A	`/site-to-site`
view system diagnostics	Allows users to view System Diagnostics	Summary	`/system`
proxy user requests	Allows proxy machines to send requests on the behalf of others	N/A	`/proxy`
access counters	Allows users to view/modify Counters	Counters	`/counters`

Component Level Access Policies

Component level access policies govern the following component level authorizations:


Policy	Privilege	Resource Descriptor & Action
view the component	Allows users to view component configuration details	`resource="/<component-type>/<component-UUID>" action="R"`
modify the component	Allows users to modify component configuration details	`resource="/<component-type>/<component-UUID>" action="W"`
operate the component	Allows users to operate components by changing component run status (start/stop/enable/disable), remote port transmission status, or terminating processor threads	`resource="/operation/<component-type>/<component-UUID>" action="W"`
view provenance	Allows users to view provenance events generated by this component	`resource="/provenance-data/<component-type>/<component-UUID>" action="R"`
view the data	Allows users to view metadata and content for this component in flowfile queues in outbound connections and through provenance events	`resource="/data/<component-type>/<component-UUID>" action="R"`
modify the data	Allows users to empty flowfile queues in outbound connections and submit replays through provenance events	`resource="/data/<component-type>/<component-UUID>" action="W"`
view the policies	Allows users to view the list of users who can view/modify a component	`resource="/policies/<component-type>/<component-UUID>" action="R"`
modify the policies	Allows users to modify the list of users who can view/modify a component	`resource="/policies/<component-type>/<component-UUID>" action="W"`
receive data via site-to-site	Allows a port to receive data from NiFi instances	`resource="/data-transfer/input-ports/<port-UUID>" action="W"`
send data via site-to-site	Allows a port to send data from NiFi instances	`resource="/data-transfer/output-ports/<port-UUID>" action="W"`

	Note
	You can apply access policies to all component types except connections. Connection authorizations are inferred by the individual access policies on the source and destination components of the connection, as well as the access policy of the process group containing the components. This is discussed in more detail in the Creating a Connection and Editing a Connection examples below.

	Note
	In order to access List Queue or Delete Queue for a connection, a user requires permission to the "view the data" and "modify the data" policies on the component. In a clustered environment, all nodes must be be added to these policies as well, as a user request could be replicated through any node in the cluster.

Access Policy Inheritance

An administrator does not need to manually create policies for every component in the dataflow. To reduce the amount of time admins spend on authorization management, policies are inherited from parent resource to child resource. For example, if a user is given access to view and modify a process group, that user can also view and modify the components in the process group. Policy inheritance enables an administrator to assign policies at one time and have the policies apply throughout the entire dataflow.

You can override an inherited policy. Overriding a policy removes the inherited policy, breaking the chain of inheritance from parent to child, and creates a replacement policy to add users as desired. Inherited policies and their users can be restored by deleting the replacement policy.

Note

"View the policies" and "modify the policies" component-level access policies are an exception to this inherited behavior. When a user is added to either policy, they are added to the current list of administrators. They do not override higher level administrators. For this reason, only component specific administrators are displayed for the "view the policies" and "modify the policies" access policies.

	Note
	You cannot modify the users/groups on an inherited policy. Users and groups can only be added or removed from a parent policy or an override policy.