authorize tenant level and namespace level access from the authorization provider

[Geal]

Is your feature request related to a problem? Please describe.
I am currently writing an authentication provider and an authorization provider, and the authorization API only provides the isSuperUser method for admin level usage. There is no way to authorise a client depending on the affected tenant or namespace. In my use case, I want my clients to have their own tenant, and be able to give limited access to some namespaces to their developers.

Describe the solution you'd like
Adding new methods to AuthorizationProvider:

• for tenant level access (different from superuser access: can't create, delete or update a tenant, but manage every namespace under the tenant): CompletableFuture<Boolean> canManageNamespace(NamespaceName namespaceName, String role, NamespaceOperation operation, AuthenticationDataSource authenticationData)
  • NamespaceOperation is an enum that can be any of the namespace management tasks, like create, delete, grant-permissions, etc. The default implementation could ignore it, but other providers could manage more granular access (like, I can affect subscriptions, but not quotas and affinity). I think some operations should still require superuser access, like set-clustersor unload?
  • the default implementation would check that either we're a super user, or the role is in the list returned by tenant.getAdminRoles()
  • maybe a separate function for list, since it would not take a namespace name as argument?
• for namespace level access: CompletableFuture<Boolean> canManageTopic(TopicName topic, String role, TopicOperation operation, AuthenticationDataSource authenticationData)
  • same as tenant level access, TopicOperation is an enum listing all the possible operations
  • same as tenant level access, the default provider would ignore the operation argument, and check that either we're a super user, or the role is in the list returned by tenant.getAdminRoles()

Add corresponding methods to PulsarWebResource. Right now it only has validateSuperUserAccess and validateAdminAccessForTenant. We must modify validateAdminAccessForTenant to add the operation, and add validateAdminAccessForTopic
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

Describe alternatives you've considered
I do not know any alternative way to get more granular admin access authorization

[jiazhai]

Hi Geal, there was a discussion of role and authorize in pulsar dev mail list. And also a PIP is here: https://github.com/apache/pulsar/wiki/PIP-49%3A-Permission-levels-and-inheritance

Would you please check if these could help your case.

[Geal]

I agree with the thread, the current access levels are problematic for multi tenant systems. The underlying point I'd like to add is that there should be check for individual operations or resources, not just for super user, tenant admin (we already have the canProduceAsync function and others that work like that).

[tuteng]

It seems too heavy to implement such fine-grained permission management in pulsar. I think it can be implemented in an external system, such as pulsar-manager https://github.com/apache/pulsar-manager. This external service can be used to proxy all HTTP requests and complete all permission management. I have considered the above fine-grained authorization management before. This is the PIP of pulsar-manager's permission management https://github.com/apache/pulsar-manager/wiki/Authentication-and-Authorization-in-Pulsar-Manager. I think you can consider implementing this feature based on this. @Geal

[Geal]

How heavy would it be? From what I see, that would mean:

• adding the various methods to AuthorizationProvider, with the basic implementation calling isSuperUser under the hood
• going through the admin API and adapt the levels. I see 12 calls for validateAdminAccessForTenant and 17 calls for validateSuperUserAccess (outside of tests). It's largely doable

I could probably get the same feature throught the manager, but it is very surprising to me that a multitenant system could not expose basic management features to tenants without admin access

[sijie]

@jiazhai @tuteng

I think the issue is asking for interfaces to be added to AuthorizationProvider. The default implementation can remain the same. The interfaces allow external parties to customize their own authorization implementation.

The authorization provider can be enhanced into an extensible interface. What an authorization provider provides is if a role is able to apply a verb/action to a given resource.

The resources are:

• tenant
• namespace
• namespace_policy
• topic
• subscription
• functions
• connectors

For each resource, there are certain verbs and actions available for operating those resources. The authorization provider provides an implementation to check if a role is allowed to apply a certain verb over a resource.

If we can abstract the authorization provider, it allows people to customize its own authorization provider implementation to allow finer granularity access controls.

For the default implementation, Pulsar has, we can keep it as is due to the concerns raised around PIP-49.

Does that make sense?

[jiazhai]

Thanks for @KannarFr 's help on this issue.

[zymap]

@KannarFr Thanks for your help.

Currently, @KannarFr had added the basic interface of the authorization provider. We need to make sure all the places that called for validating the auth support the new way to validate.

Here a list about that:

• ServerCnx
• v2 / Brokers
• v2 / BrokerStats
• v2 / Clusters
• v2 / Functions
• v2 / Namespaces
• v2 / NonPersistentTopics
• v2 / PersistentTopics
• v2 / ResourceQuotas
• v2 / SchemaResource
• v2 / Tenants
• v2 / Worker
• v2 / WorkerStats
• SourcesBase
• SinksBase

KannarFr has done a part of those at #6428 .

[KannarFr]

Hi @zymap,

The way to add these features is done on #6428. It comes with its usage on Namespaces & ServerCnx.