authorize tenant level and namespace level access from the authorization provider

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

[KannarFr]

Hi @zymap,

The way to add these features is done on https://github.com/apache/pulsar/pull/6428. It comes with its usage on Namespaces & ServerCnx.

[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?