It is good that we are looking at revamping the system. But the proposal
as it is, is thin.
First I would like this proposal to be split into two. One for inheritance
and another for changes from existing controls. They are completely
orthogonal and independent issues. Second, both of them (inheritance and
changes) need to have a clear rationales.
There are 2 key underlying principles in Pulsar,. The cluster operators,
i.e. Pulsar admins (super-users) manage the system and system resources,
Their role is in operating the cluster and managing system resources (CPU,
storage, n/w bandwidth etc) and keeping the system healthy. Tenant admins
mange the tenant resources allocated to them) .Second, Pulsar has a model
of disintermediation. Owning, Producing and Consuming are separate concerns
and are abstracted from each other.
Many changes in this proposal does not fit the model. So I would like to
see rationale for each permission change from existing permissions
For eg: the proposed change for in namespace permissions for
set-clusters tenant-admin ==> super-user
breaks the resource model. A tenant is allocated resources in X,Y,Z
clusters. And it's up top the tenant to manage it - whether to use
resources in X, or in X& Y etc, and to which resources. There is no reason
for the super-user to get involved.
Another example, unloading a namespace is a system operation that moves
load in the cluster around. Allowing namespace owners to interfere in
system operations is never a good idea.
I see many such changes here which does not fit the resource model
I also see that this breaks the existing model of topic level override of
permissions. Again, this does not seem to be well thought-out on that side
either.
So I would like to see rationales that align with 1)resource management
principles 2) the separation of concerns between owner, producer and
consumer 2) zero trust (unless explicitly granted nothing is given)4) zero
discovery avenues - no information, however harmless it is, is revealed to
entities that don't need it. (eg: There is no reason for a namespace owner
to do get-dispatch-rate)
I agree that we Pulsar can improve on what we have today, but this proposal
needs additional work and understanding of the complex underlying issue of
resource management related to granting control.
Joe
On Wed, Oct 30, 2019 at 4:49 AM xiaolong ran <ranxiaolong...@gmail.com>
wrote:
> Hello all:
>
> When using pulsar-admin, I found that the current permission verification
> mechanism has some problems.
>
> We are starting a proposal about permission levels and inheritance in
> Apache Pulsar.
>
> The proposal is in:
>
> https://github.com/apache/pulsar/wiki/PIP-49%3A-Permission-levels-and-inheritance
> <
> https://github.com/apache/pulsar/wiki/PIP-49:-Permission-levels-and-inheritance
> >
>
> To ensure compatibility, these changes will be made in v4's admin api.
> About the v4 admin API, see:
>
> https://github.com/apache/pulsar/wiki/PIP-48%3A-hierarchical-admin-api <
> https://github.com/apache/pulsar/wiki/PIP-48:-hierarchical-admin-api>
>
> Looking forward to any feedback.
>
