[
https://issues.apache.org/jira/browse/NIP-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18054361#comment-18054361
]
Mark Bean commented on NIP-20:
------------------------------
That is an accurate summary. I envision different tenants needing access to
different Registry Clients. Originally, I thought the clients would be entirely
different repositories, but there would be no reason it couldn't be different
directories or branches within the same git repository.
I see your point of working around policies if a given user has the ability to
create a client - and to define it however they wish. I thought 'modify the
controller' would be used for this, but maybe we need a new controller-level
policy for "create registry client". This would be a similar mechanism to how
provenance work. You need a controller-level policy to query provenance at all,
but a component-level to view specific events.
> 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)
