Mark Bean created NIP-20:
----------------------------
Summary: 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
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)
