Apache NiFi Security Reference
Also available as:
PDF

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