[
https://issues.apache.org/jira/browse/NIP-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann reassigned NIP-39:
-----------------------------------
Assignee: David Handermann
> 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 be unchanged.
> 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)
