KannarFr commented on issue #6428: [Issue 5720][authorization provider] (WIP) Add more granularity URL: https://github.com/apache/pulsar/pull/6428#issuecomment-592921663 Hi, Here we are defining an authz provider interface not the authz provider. We want to provide the way to authz every cases as multitenancy stuff. In my case all authorized info will be defined in the role String which will be a token containing authorized information. Like this token has produce operation authorized on this namespace or this topic. In the case you are illustrating we just want that the PulsarAuthzProvider (which is the default for now) handles some default cases as you mentioned. And sure we could define default bindings in configuration file. This stuff will come in other PR (I guess), currently I just want to impl the granularity possibilities without breaking changes for current default PulsarAuthzProvider. Le sam. 29 févr. 2020 à 02:44, joefk <[email protected]> a écrit : > @KannarF > > I think every permissions should be granted by authz provider. > Some of them are not grantable. How did your arrive at that conclusion? > That is a very simplistic view of the system. After going through PIP-49 > and the discussions about that, what is your take? > > As, you state in the description of your PR.. > > And the biggest part of the task: go through every usage of > validateSuperUserAccess and validateAdminAccessForTenant and check if they > can be replaced with finer grain access > Can you share your findings for that? I did not see any > > My concern is this. How can I, as a Pulsar operator (NOT a tenant) decide > which of these operations I will delegate to my tenants for finer control ? > > Operators should not be put in a position where if they were to deploy > this authz provider, they would have to go and turn off/on certain actions > for all fine-grained resources every time someone creates a namespace or > topic. And the things you are proposing to delegate here in this proposal > are an operators nightmare for a large cluster. Hence my ask. Put the list > of the things that can be delegated into a config file, so that operators > can decide ONCE when they DEPLOY Pulsar, about what can be potentially > delegated. Don't hardcode it into the server, and create runtime > maintenance work for operators > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/apache/pulsar/pull/6428?email_source=notifications&email_token=ABZLQJMY5MQQXPQAXPIWBH3RFG4YLA5CNFSM4K4ES5QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENKYPUA#issuecomment-592807888>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABZLQJKYUH3RYTKDCFSZTUTRFG4YLANCNFSM4K4ES5QA> > . >
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
