[
https://issues.apache.org/jira/browse/NIFI-15710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Doran updated NIFI-15710:
-------------------------------
Description:
h2. Connector Update Fails in Clustered NiFi: Node Identity Lacks READ
Permission on /connectors
h3. Summary
In a clustered NiFi deployment, applying an update to a connector fails with a
403 Forbidden error. The ClusteredConnectorRequestReplicator polls connector
state across the cluster during updates using the node's own identity, but node
identities are not granted READ access to the /connectors resource, causing the
authorization check to fail.
h3. Steps to Reproduce
# Configure a multi-node NiFi cluster with authorization enabled (e.g., using
FileAccessPolicyProvider with node identities configured)
# Create a connector
# Apply an update to the connector
h3. Expected Behavior
The connector update completes successfully. The node should be able to poll
the state of the connector across all cluster nodes during the update lifecycle.
h3. Actual Behavior
The update fails with:
{code:java}
java.io.IOException: Client-side error requesting State for Connector with ID
<uuid>. Status code: 403, reason: Forbidden{code}
The authorization log shows:
{code:java}
Identity [<node-hostname>] Groups [] does not have permission to access the
requested resource. Unable to view Connector with ID <uuid>. [Authorization
denied] Returning Forbidden response.{code}
h3. Root Cause
During a connector update, StandardConnectorRepository.waitForState() calls
ConnectorRequestReplicator.getState(), which in the clustered implementation
(ClusteredConnectorRequestReplicator) replicates a GET
/nifi-api/connectors/\{id} request to all nodes using the local node's
identity. The receiving node's ConnectorResource endpoint authorizes this as a
READ on /connectors/\{uuid}, which falls back to the parent authorizable
/connectors.
h3. Involved Components
* ClusteredConnectorRequestReplicator.getState() -- the caller that triggers
the authorization failure
* StandardConnectorRepository.waitForState() -- invoked during
updateConnector() on the "NiFi Connector Lifecycle" background thread
h3. Notes
* This only affects clustered deployments. The standalone implementation
(StandaloneConnectorRequestReplicator) queries the FlowManager directly and
does not go through the REST API or authorization.
* The ConnectorRequestReplicator interface has a single method (getState), and
waitForState is the only caller, so this is an isolated issue.
h3. Proposed Solution
ParameterContextResource has a similar problem for syncing assets referenced by
parameters throughout the cluster. The solution there is to always allow calls
that are coming from node identities. That approach could be applied here.
was:
h2. Connector Update Fails in Clustered NiFi: Node Identity Lacks READ
Permission on /connectors
h3. Summary
In a clustered NiFi deployment, applying an update to a connector fails with a
403 Forbidden error. The ClusteredConnectorRequestReplicator polls connector
state across the cluster during updates using the node's own identity, but node
identities are not granted READ access to the /connectors resource, causing the
authorization check to fail.
h3. Steps to Reproduce
# Configure a multi-node NiFi cluster with authorization enabled (e.g., using
FileAccessPolicyProvider with node identities configured)
# Create a connector
# Apply an update to the connector
h3. Expected Behavior
The connector update completes successfully. The node should be able to poll
the state of the connector across all cluster nodes during the update lifecycle.
h3. Actual Behavior
The update fails with:
{code:java}
java.io.IOException: Client-side error requesting State for Connector with ID
<uuid>. Status code: 403, reason: Forbidden{code}
The authorization log shows:
{code:java}
Identity [<node-hostname>] Groups [] does not have permission to access the
requested resource. Unable to view Connector with ID <uuid>. [Authorization
denied] Returning Forbidden response.{code}
h3. Root Cause
During a connector update, StandardConnectorRepository.waitForState() calls
ConnectorRequestReplicator.getState(), which in the clustered implementation
(ClusteredConnectorRequestReplicator) replicates a GET
/nifi-api/connectors/\{id} request to all nodes using the local node's
identity. The receiving node's ConnectorResource endpoint authorizes this as a
READ on /connectors/\{uuid}, which falls back to the parent authorizable
/connectors.
FileAccessPolicyProvider.populateNodes() seeds default policies for node
identities (WRITE on /proxy, READ on /controller, READ/WRITE on
/data/process-groups/\{root-group-id}), but does not include READ on
/connectors.
h3. Involved Components
* ClusteredConnectorRequestReplicator.getState() -- the caller that triggers
the authorization failure
* StandardConnectorRepository.waitForState() -- invoked during
updateConnector() on the "NiFi Connector Lifecycle" background thread
h3. Notes
* This only affects clustered deployments. The standalone implementation
(StandaloneConnectorRequestReplicator) queries the FlowManager directly and
does not go through the REST API or authorization.
* The ConnectorRequestReplicator interface has a single method (getState), and
waitForState is the only caller, so this is an isolated issue.
> Update authorization for calls made by ClusteredConnectorRequestReplicator
> --------------------------------------------------------------------------
>
> Key: NIFI-15710
> URL: https://issues.apache.org/jira/browse/NIFI-15710
> Project: Apache NiFi
> Issue Type: Task
> Components: Core Framework, Security
> Reporter: Kevin Doran
> Assignee: Kevin Doran
> Priority: Major
>
> h2. Connector Update Fails in Clustered NiFi: Node Identity Lacks READ
> Permission on /connectors
> h3. Summary
> In a clustered NiFi deployment, applying an update to a connector fails with
> a 403 Forbidden error. The ClusteredConnectorRequestReplicator polls
> connector state across the cluster during updates using the node's own
> identity, but node identities are not granted READ access to the /connectors
> resource, causing the authorization check to fail.
> h3. Steps to Reproduce
> # Configure a multi-node NiFi cluster with authorization enabled (e.g.,
> using FileAccessPolicyProvider with node identities configured)
> # Create a connector
> # Apply an update to the connector
> h3. Expected Behavior
> The connector update completes successfully. The node should be able to poll
> the state of the connector across all cluster nodes during the update
> lifecycle.
> h3. Actual Behavior
> The update fails with:
> {code:java}
> java.io.IOException: Client-side error requesting State for Connector with ID
> <uuid>. Status code: 403, reason: Forbidden{code}
>
> The authorization log shows:
>
> {code:java}
> Identity [<node-hostname>] Groups [] does not have permission to access the
> requested resource. Unable to view Connector with ID <uuid>. [Authorization
> denied] Returning Forbidden response.{code}
>
> h3. Root Cause
> During a connector update, StandardConnectorRepository.waitForState() calls
> ConnectorRequestReplicator.getState(), which in the clustered implementation
> (ClusteredConnectorRequestReplicator) replicates a GET
> /nifi-api/connectors/\{id} request to all nodes using the local node's
> identity. The receiving node's ConnectorResource endpoint authorizes this as
> a READ on /connectors/\{uuid}, which falls back to the parent authorizable
> /connectors.
> h3. Involved Components
> * ClusteredConnectorRequestReplicator.getState() -- the caller that triggers
> the authorization failure
> * StandardConnectorRepository.waitForState() -- invoked during
> updateConnector() on the "NiFi Connector Lifecycle" background thread
> h3. Notes
> * This only affects clustered deployments. The standalone implementation
> (StandaloneConnectorRequestReplicator) queries the FlowManager directly and
> does not go through the REST API or authorization.
> * The ConnectorRequestReplicator interface has a single method (getState),
> and waitForState is the only caller, so this is an isolated issue.
>
> h3. Proposed Solution
> ParameterContextResource has a similar problem for syncing assets referenced
> by parameters throughout the cluster. The solution there is to always allow
> calls that are coming from node identities. That approach could be applied
> here.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
