Is there any appetite for considering a "namespace admin"? We could really have use of this as currently we have to give more people than we would want tenant admin to ease administration, when many users basically just need permissions to create topics and grant permissions to those topics.
>From my reading of this chain, it is obvious that it probably won't be given a ton of permissions and it may be complex to add, but it seems like starting with a conservative approach of permissions for a namespace admin initially could be done fairly quickly and safely. I would say the following could make a a lot of sense to be in a namespace admin permissions: Topics - compaction/compaction status - offload/offload-status - create/delete non partitioned topics - create/delete partitioned topics - list/grant/revoke permissions - create/delete/peek/seek subscriptions - stats calls Namespaces - list/grant/revoke permissions - set/get clusters (maybe not?) - get/set ttl - get/set persistence (maybe not?) I think that set of permissions (with some deletions or adjustments) could go a long way to making the current permissions model work a fair bit better for orgs trying to deploy pulsar. Long term, it feels like the correct answer to this problem is probably to introduce some sort of policy language with a role being tied to some policy that can grant a wide range of individual permissions, with the existing superuser/tenant-admin/etc being redefined in terms of some of these policies (perhaps using something like https://casbin.org/en/). If it seems like the focus should be on the more general solution, then I am fine leaving this for now, but this will be something we need to tackle in the next 6 months or so for my org, so I would love to see any sort of direction of where things should be heading so we can plan to that and perhaps help where possible! On Mon, Nov 11, 2019 at 2:24 AM xiaolong ran <ranxiaolong...@gmail.com> wrote: > Hello everyone: > > I reorganize the relevant content of this PIP. PTAL again. > > https://github.com/apache/pulsar/wiki/PIP-49:-Permission-levels-and-inheritance > < > https://github.com/apache/pulsar/wiki/PIP-49:-Permission-levels-and-inheritance > > > > In this PIP, I only fix the unreasonable permissions in the current > command and shown in bold. > About specific permission of command, if there are different opinions > about this, pls let me know, thanks. > > -- > > Thanks > Xiaolong Ran > > > > 在 2019年11月8日，下午4:41，xiaolong ran <ranxiaolong...@gmail.com> 写道： > > > > Thanks Sijie, Joe F and Addison Highham feedback. > > > > As Joe said: > > > > > There are no simple answers here other than to understand the effect > of the command. > > > > So in here, we can use sijie proposal, we only need to fix the > unreasonable permissions in the current command. > > > > I will reorganize this PIP, what do you think about this? > > > > -- > > > > Thanks > > Xiaolong Ran > > > > > >> 在 2019年11月8日，下午3:59，Sijie Guo <guosi...@gmail.com <mailto: > guosi...@gmail.com>> 写道： > >> > >> If the problem is complex enough, can we first reduce the scope of this > PIP > >> to focus on fixing the permissions of individual commands (e.g. schemas > >> don't require super-user permissions)? > >> As you said, there is no simple answers. We can go through the commands > one > >> by one and come up a table of commands and their permissions and > document > >> it. > >> It can help users understand how the permissions work for each command. > >> > >> We can revisit a larger scope till we add the capability of allocation > >> resources at different levels. > >> > >> Does that make sense? > >> > >> - Sijie > >> > >> > >> On Fri, Nov 8, 2019 at 3:22 PM Joe F <j...@apache.org <mailto: > j...@apache.org>> wrote: > >> > >>> There are no simple answers here other than to understand the effect > of the > >>> command. > >>> > >>> The resource limit/control command always addresses an object. But > giving > >>> control of that command to the object owner, just because the command > >>> addresses an object, will break all controls about resource > utilization in > >>> a shared system. A filesystem like model may look simple and elegant > but > >>> is fraught with all kind of unintended consequences if implemented in > >>> Pulsar (Even in the filesystem rm, mv and chown, while all addressing > a > >>> file, treats the file owner differently) > >>> > >>> This is a complex, and complicated effort, and my concern is that > this PIP > >>> does not even come close to the scope of the work that is required. > Some > >>> of them may be impossible to do (as allocating certain resources to > >>> namespace as compared to tenant) till such capabilities are added to > the > >>> system. And some begs fundamental questions - when you start managing > a > >>> namespace like a tenant, does it even make sense to have that > namespace? > >>> Should't that namespace be a tenant in the first place? Why have a > >>> namespace admin at all? > >>> > >>> Joe > >>> > >>> > >>> > >>> On Thu, Nov 7, 2019 at 8:16 PM Dave Fisher <wave4d...@comcast.net > <mailto:wave4d...@comcast.net>> wrote: > >>> > >>>> I’m not diving in but thinking about the logical implication of this > >>>> dichotomy. For any object’s attributes some ought to be controlled by > >>>> object level permissions and others by sysadmin permissions. How can > >>>> developers tell? > >>>> > >>>> Best Regards, > >>>> Dave > >>>> > >>>> > >>>> Sent from my iPhone > >>>> > >>>>> On Nov 7, 2019, at 8:02 PM, Joe F <j...@apache.org <mailto: > j...@apache.org>> wrote: > >>>>> > >>>>> This proposal has the same issues as the previous one . In general > it > >>> is > >>>>> not correct to think of commands as being controlled by owner of the > >>>>> object on which the command operates. Eg: It will be an error to > >>> assing > >>>>> control of all namespace commands to the namespace owner > >>>>> > >>>>> For eg: set subscription-dispatch-rate operates on a subscription > rate > >>>> and > >>>>> set-max-producers-per-topic These operate on namespaces. A naive > >>> approach > >>>>> is to think that this would be controlled by the namespace owner. > But > >>>>> essentially both these are resource management operations. That > should > >>>> be > >>>>> controlled by the system admin, unless you want to deal with every > >>>>> namespace owner having the power to destroy your SLAs fo the cluster. > >>>>> > >>>>> I just picked 2 examples to indicate the drawback of approaching > >>>>> permissions in the proposed manner. > >>>>> > >>>>> There are many such cases in the proposal, too many to list out > here. I > >>>>> suggest completely ditching this approach of equating objects with > >>> admin > >>>>> capability of object owner > >>>>> > >>>>> Joe > >>>>> > >>>>> > >>>>>> On Wed, Nov 6, 2019 at 2:14 AM xiaolong ran < > ranxiaolong...@gmail.com <mailto:ranxiaolong...@gmail.com> > >>>> > >>>>>> wrote: > >>>>>> > >>>>>> Hello all committers: > >>>>>> > >>>>>> About this PIP, do you have any other good ideas or propose. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> Thanks > >>>>>> Xioalong Ran > >>>>>> > >>>>>> > >>>>>>>> 在 2019年10月30日，下午7:49，xiaolong ran <ranxiaolong...@gmail.com > <mailto:ranxiaolong...@gmail.com>> 写道： > >>>>>>> > >>>>>>> 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%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. > >>>>>> > >>>>>> > >>>> > >>>> > >>> > > > >
