David Handermann created NIP-39:
-----------------------------------
Summary: 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
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 Flow. 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)
