[jira] [Resolved] (NIP-39) Replace Fine-Grained Component Authorization with Controller-Level Authorization

["David Handermann (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NIP-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Handermann resolved NIP-39.
---------------------------------
    Resolution: Resolved

> Replace Fine-Grained Component Authorization with Controller-Level Authorization
> --------------------------------------------------------------------------------
>
>                 Key: NIP-39
>                 URL: https://issues.apache.org/jira/browse/NIP-39
>             Project: NiFi Improvement Proposal
>          Issue Type: Improvement
>            Reporter: David Handermann
>            Assignee: David Handermann
>            Priority: Major
>
> h2. Motivation
> The current framework authorization model supports configuring Access Policies that can be applied to individual object instances, including Processors, Controller Services, and Parameter Providers. Introduced in early versions of the project, this authorization structure was intended to support fine-grained authorization to enable multi-tenant deployments.
> The problem with the fine-grained authorization model is that it provides a configurable security boundary which the framework cannot enforce. Processors and other extensions have full access to the shared Java Virtual Machine, including the operating system as the user running the Java process. This fact motivated the deprecation of the Restricted annotation for components.
> To provide a consistent and enforceable security boundary, the framework should deprecate and remove support for configuring fine-grained component authorization.
> h2. Scope
> Simplifying flow authorization requires changes to framework REST API implementation classes, as well as the Authorizer interface and supporting components.
> The primary scope involves eventual removal of fine-grained authorization in REST API Resource classes that check authorized component access. This should also extend to Parameter Contexts and Parameter Providers.
> The framework interfaces, including the Access Policy Provider, may require implementation adjustments to deprecate and remove writing and reading authorized actions for individual components, based on identifiers. These authorization methods will be adjusted to write and read allowed actions based on Resource Type, including the Controller Type, which should indicate complete access to create, modify, and delete Process Groups with any child components.
> Authorization for other Resource Types, such as Provenance, Data Content Viewing, Tenants, and Policies, should also be moved to the Controller level for consistency.
> These changes do not require any modifications or additions to the public NiFi API.
> h2. Description
> The simplified authorization strategy involves locating editing of extension components under a single Resource Type of Controller. Process Groups and all child components will be authorized under a single policy declaration. The current enumeration of Resource Types includes both Flow and Controller, so the simplified strategy should merge these Resource Types into a single Resource Type for authorization purposes. The Controller Resource Type appears to be the best option for this purpose as it aligns the authorization policy with the enforceable security boundary. The same function could be achieved using System as the shared Resource Type boundary. Read on the Controller continues to mean limiting actions to viewing without modification.
> The current Authorizer interface in the framework-api defines a generic authorize method with the AuthorizationRequest object. This interface definition can remain unchanged. The Resource interface, included in the AuthorizationRequest, should be extended to have a Resource Type included for simplified authorization evaluation.
> h2. Compatibility
> Initial deprecation will have no functional impact when upgrading existing deployments, continuing to enforce existing policies.
> Subsequent implementation will provide an automatic migration for existing Access Policies defined in the serialized XML authorization configuration. The specific mapping of existing authorizations is subject to implementation review.
> The basic strategy for migration will involve translating existing write permissions on one or more Process Groups and translating that to write access at the Controller level. This migration approach adjusts the declared policy implementation with the enforceable boundary.
> When upgrading, the migration process will write a new serialized XML authorization that removes authorization policies defined for individual components. The migration process will create a backup copy of the original XML authorizations prior to writing a new version.
> For other implementations of the Authorizer, the transitional approach will map authorized actions at a nested level to the corresponding action for the Resource Type, such as a Process Group.
> For final removal in a major version, the Authorizer and Access Policy Provider interfaces will remove any methods deprecated as part of the transitional implementation.
> h2. Verification
> Deprecation of features through standard deprecation logging, and migration capabilities, will be reviewed as part of the standard pull request process. Existing unit tests and system tests for authorization will be adjusted to consider applicable Resource Types instead of individual components. New unit tests for the migration should also be implemented.
> h2. Alternatives
> Retaining authorization at the Process Group level may appear to be a less impactful strategy that would still reduce the complexity associated with fine-grained authorization for components. However, supporting different authorization for different Process Groups remains subject to the fundamental problems with security boundaries that cannot be enforced.
> Retaining separate authorization for Flow Configuration versus Controller Configuration also has the appearance of a reasonable boundary, but the ability of configurable components to access system resources breaks the enforcement strategy.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)