You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2021/12/23 11:53:03 UTC

[GitHub] [pulsar] massakam commented on pull request #13463: Revert "[Authorization] Converge authz of ns policies from super-user to tenant-administrator (#13157)"

massakam commented on pull request #13463:
URL: https://github.com/apache/pulsar/pull/13463#issuecomment-1000252494


   @yuruguo
   > The `publish-rate` example you cited may reflect the question whether the tenant administrators complete a reasonable operation with the authz. Perhaps `internalSetMaxTopicsPerNamespace` / `internalSetMaxProducersPerTopic` / ` internalSetMaxConsumersPerTopic` also have this problem although the tenant administrators can operate it at present.
   
   As far as `internalSetMaxProducersPerTopic` and `internalSetMaxConsumersPerTopic` are concerned, it was my colleague who added these features, and initially only superusers were able to perform these operations.  We have added these features because a specific tenant in our company created a large number of clients and caused system instability.
   https://github.com/apache/pulsar/pull/1255/files#diff-8696b1e2ba4ee355256e31b33ccc4f1cab77f1c6c79f7b4ab508b73d43d8ad55R1252
   https://github.com/apache/pulsar/pull/1255/files#diff-8696b1e2ba4ee355256e31b33ccc4f1cab77f1c6c79f7b4ab508b73d43d8ad55R1293
   
   > One solution is to regulate the behavior of tenant administrators. For example, there is an `publish-rate` upper limit for  tenant administrators and it can only be operated by the super user once the upper limit is exceeded.
   
   That looks good to me.
   
   > 2. The role with `lookup topic` authz can set the publish rate to topic, is there a similar problem like the example?
   
   I think so. At the very least, the superuser should be able to set an upper limit.
   
   > 3. Except for rate-related policies in this PR, can other policies be operated by tenant administrators? 
   > Including: `internalSetInactiveTopic`, `internalSetDelayedDelivery`, `internalSetMaxSubscriptionsPerTopic`
   
   I think `internalSetMaxSubscriptionsPerTopic` should only be performed by the superuser. Tenants don't have much motivation to limit the number of subscriptions, and unlimited is better. Only the administrators of the Pulsar instance have the motivation to limit it.


-- 
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.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org