Thanks Matteo and Joe. In here, I have two questions:
1. In `namespaces` and `topics`, most of the commands are `tenant admin`, are they reasonable? 2. Whether permissions management should be inherited? For examples: in `bin/pulsar-admin topics create [topic name]`, should only the `tenant admin` have permission to operate, even if the `super user ` should not have permission to create a topic, right? > From `set-subscribe-rate` to `set-max-producers-per-topic`, all these methods are there for protecting the system and give the operator the flexibility to box users into different shaped boxes based on necessity. Yes, for some permissions of commands, we need to discuss further, this is also the purpose of this PIP. This PIP proposes introducing permission levels and inheritance into Pulsar authorization system to make permission check clearer across Pulsar codebase. We can discuss which of the permissions for the commands in this PIP are reasonable, and which of the commands' permissions we should keep current permissions. Thanks again. Best Regards, Xiaolong Ran > 在 2019年10月31日，上午12:33，Matteo Merli <mme...@apache.org> 写道： > > Agree with Joe, > > there are several methods in namespaces API that *really* meant for > super-user only. It was not a mistake or oversight. > > From `set-subscribe-rate` to `set-max-producers-per-topic`, all these > methods are there for protecting the system and > give the operator the flexibility to box users into different shaped > boxes based on necessity. > > Also, if we're talking about inheritance we should also include the > topic level ACLs (which are already supported) and how > the topic level ACLs interacts with the APIs. > > Eg: if I have topic level produce permission on a topic, I should be > able to get/set the schema for that topic. > > > > > -- > Matteo Merli > <mme...@apache.org> > > On Wed, Oct 30, 2019 at 7:22 AM Joe F <j...@apache.org> wrote: >> >> 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. >>>
