[
https://issues.apache.org/jira/browse/NIP-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18053723#comment-18053723
]
David Handermann commented on NIP-20:
-------------------------------------
Thanks for describing the potential changes to authorization for Flow Registry
Clients [~markbean].
The differences in integration approach with NiFi Registry itself are worth
highlighting, and these details are worth considering with the proposed
deprecation of NiFi Registry in subsequent major versions.
To consider this further, it would be helpful to expand on a couple areas.
Following the proposed description, it sounds like the concept would be to
create multiple Flow Registry Clients, with different paths or even different
credentials, and then grant access as needed. Is that an accurate summary? In
order for this to be effective, it sounds like it would be necessary to
restrict the ability of such users to create or modify Flow Registry Client
instances, as that could result in working around initial configuration.
The current fine-grained authorization model has some inherent impedance
mismatch when it comes to configuration and resource consumption. This is
something I plan to consider in more detail in a separate improvement proposal.
Taking a step back then, this proposal raises a question of whether such
fine-grained authorization is only applicable to a NiFi installation with
multiple discrete groups of users, intending to isolate each group from
another. If that is not the goal, and new policies can provide enforceable
boundaries, this seems worth considering. On the other hand, if such boundaries
can be circumvented through custom code configuration or similar methods, then
it may be better to avoid going down this road.
> Add support for more granular access controls to Registry Clients
> -----------------------------------------------------------------
>
> Key: NIP-20
> URL: https://issues.apache.org/jira/browse/NIP-20
> Project: NiFi Improvement Proposal
> Issue Type: Improvement
> Reporter: Mark Bean
> Priority: Major
>
> h2. Motivation
> NiFi Registry server allows policies for various forms of authorization. For
> example, user policies manage which users can perform certain actions such as
> creating new buckets. Bucket policies manage which users can read, write or
> delete flows within a given bucket.
> When NiFi implements non-NiFiRegistryFlowRegistryClient, e.g.
> GitHubFlowRegistryClient, these access controls are no longer available. The
> Component Access Policy 'modify the component' is required in order to
> create, modify or stop version control of a process group. This is a blunt
> solution to an otherwise finer-grained authorization mechanism.
> It is worth mentioning that at this time, there is discussion of the
> possibility of deprecating the NiFi Registry application. Should this occur,
> all Registry access control capabilities will be lost.
> h2. Description
> New Global Access Policies will be created. The policies are required to be
> global because they apply to controller-level components, i.e. Registry
> Clients. Yet, they will behave similar to Component Access Policies in that
> they apply to a specific component, a Registry Client. A notable difference
> to traditional Component Access Policies is that there is no intended
> implementation of inheritance since all Registry Clients are at the
> controller level with no hierarchy.
> The new Access Policy is "access registry client" and contains two actions,
> "view" and "modify". Using the GitHubFlowRegistryClient as an example, in
> order to achieve bucket-level access controls, the client would specify a
> specific Repository Path for a directory in git containing bucket(s)
> requiring specific view/modify access controls. Multiple clients can be
> created on a single git project, one for each access control requirement.
> The "view" option grants users the ability to view buckets and versioned
> flows with a specific client. With this capability, authorized users may
> import flows from the Registry Client. However, "view" alone does not allow
> users to update a versioned flow nor create a new one within the client (nor
> create buckets when this feature becomes available.) Similarly, the "modify"
> option grants users the ability to create a new version of a flow including
> the initial version of a new versioned flow. (It will also grant the ability
> to create buckets when this feature becomes available.) The scope of both
> "view" and "modify" are for the given Registry Client to which the policy is
> attached.
> h2. Scope
> This feature will require additions to the API as well as implementing
> classes.
> h2. Compatibility
> This proposal creates additions to the Registry Client API, but does not
> remove any functionality. In addition, default values can be implemented
> which do not change access or behavior of current clients.
> h2. Verification
> Standard unit test patterns should be applied to new code. Also, integration
> tests or real-world testing should be performed to ensure interaction with
> the UI, external registries and application of policies produces the desired
> effect.
> h2. Alternatives
> The only existing alternative at this time is using the 'modify the
> component' Component Access Policy as a catch-all which allows or denies
> access to all Registry Client buckets in all Registry Clients. In addition,
> this alternative applies across the entire data flow to which it is applied
> and is independent of the Registry Client itself. Any similar Component
> Access Policy would have the same global consequences.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
