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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
