On Wed, Oct 30, 2019 at 10:11 AM xiaolong ran <ranxiaolong...@gmail.com> wrote: > > 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?
I think having the intermediate step of namespace admin is good. For topics, we need to revisit several of these. But the questions are anyway tricky: Should someone who has "consume" access to a topic also have access to this topic stats? On one hand it might make sense, though the topic stats also include info for other unrelated subscriptions, which one might not want to be visible. > 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? I think both views are valid there, though always augmenting is a bit easier to implement and reason about. Super-user itself was being treated a bit different in that it's also used for broker-to-broker communication. For geo-replication, a broker needs to be able to connect to any other broker and publish on any topic. > 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. I think this should start by categorizing the actions/operations instead of focusing on the individual handlers.
