thetumbled commented on code in PR #22564: URL: https://github.com/apache/pulsar/pull/22564#discussion_r1578960282
########## pip/pip-347.md: ########## @@ -0,0 +1,68 @@ + +# PIP-347: add role field in consumer's stat + +# Background knowledge + +- In a typical Pulsar deployment, we set `authenticationEnabled=true` and `authorizationEnabled=true` to enable authentication and authorization. +- When users want to create a subscription in the management platform, we will grant the `consume` permission of topic and the permission of +that subscription to the user's token. so that user can create a subscription successfully. +- We also set config `allowAutoSubscriptionCreation` to be true to allow user creating subscriptions automatically if user's token has the `consume` permission. +But, **auto-creation of subscriptions will not grant the permission of the subscription to the user's token**. +- The permission control flow of subscription: + - we can only grant and revoke the permission of a subscription by the `grant-permission` and `revoke-permission` REST API. + - The permission of subscription is in the namespace level. When a user creates a subscription `sub` for topic `persistent://public/default/test`, + broker will check if user's token has the `consume` permission of `persistent://public/default/test`, if yes, broker will retrieve the permission of all subscriptions under the namespace `public/default` and get the role list of subscription `sub`. + - **If the role list is empty or null, broker allow to create the subscription.** However, the permission of the subscription is still not granted to the user's token. + - If the role list is not empty, broker will check if the role corresponding to the user's token is in the role list. If yes, broker allow to create the subscription. + - If the role corresponding to the user's token is not in the role list, broker will reject the request. + +There is a permission hole in the current design. If a user obtain the `consume` permission of a topic in management platform, he can create infinite subscriptions without notifying the administrator. +For example, user `jack` can obtain the `consume` permission of topic `persistent://public/default/test` and the permission of subscription `sub` in management platform. +At this time, the role list under the namespace `public/default` is +``` +'sub' -> ['jack'] +``` +Then, user `jack` can create other subscriptions `sub1`, `sub2`,... for topic `persistent://public/default/test` without notifying the administrator. The role list under the namespace `public/default` remain unchanged as +``` +'sub' -> ['jack'] +``` +The administrator can't know who is the owner of the subscriptions `sub1`, `sub2`,... + +What is worse, if another user `tom` obtain the permission of subscription `sub1` under the same namespace `public/default` in management platform, that result into the role list under the namespace `public/default` become to +``` +'sub' -> ['jack'] +'sub1' -> ['tom'] +``` +`jack` lose the permission of subscription `sub1` immediately. Because jack do not have the permission of subscription `sub1` really. + +He just uses an unregistered subscription `sub1` owned by nobody to consume the messages. Once there are any people obtain the permission of subscription `sub1`, his task consuming `sub1` will be shutdown immediately. + +# Motivation + +Such kind of permission lost problem cause us lots of problem. We need a tool to find out the owner of these unregistered subscriptions first. + +# Goals +Add a field `role` in the consumer's stat to show the owner of this consumer. + +## In Scope + +- help administrator to find out the owner of the consumer + +## Out of Scope + +Maybe we improve the permission control of subscriptions in the future to fix the permission lost problem described above. + + +# Backward & Forward Compatibility + +Fully compatible. Review Comment: PR https://github.com/apache/pulsar/pull/22579 is a break change, existing tasks may shutdown due to this pr. So we don't enhance the permission control with this pr now, but try to find out all these uncontrolled subscription first, and grant the permission to them at least. In my opinion, the community should fix this problem in case of more and more users facing such kind of problem. But for existing clusters, we should handle them carefully. -- 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-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
