tuteng commented on PR #19455:
URL: https://github.com/apache/pulsar/pull/19455#issuecomment-1463770662

   > > in many user environments it can be trusted and there is no such risk
   > 
   > Can you clarify what "it" is here? What is the purpose of authorization if 
the environment is trusted?
   
   `it` means is that the client application uses the proxy's super role to 
connect to the cluster
   In a pulsar cluster there are not only super roles, but also non-super 
roles, so authorization is still required, and if a client has been assigned a 
super role, it is of course trusted
   
   Before this change, if a client wanted to connect to the cluster using the 
super role, the role had to be configured in the proxy's superUserRoles, 
otherwise the proxy would not be able to authenticate it, after this change, if 
a client connected to the cluster using the super role, the role could not 
appear in superUserRoles of the proxy and proxyRoles of the broker, otherwise 
the connect also will fail, which seems to be an opposite behavior
   
   I think this is a security enhancement, not a vulnerability (I'm sure you 
agree), but now that this change has been introduced on most major branches.I 
understand it doesn't make sense to use the proxy's superRoles, but it works 
correctly, and if a user performs a minor version upgrade without understanding 
the context, such as upgrading a cluster from 2.10.3 to 2.10.4 (ideally there 
should be no breaking changes), that will result in clients not being able to 
successfully connect to the cluster, which will cause some failures, which have 
actually happened in some users' test environments
   
   I don't think it is a problem to introduce this change in a major release 
(e.g. 3.0) because it will give users enough time to understand it. Minor 
upgrades are frequent, so I don't think it is appropriate to introduce it on a 
minor release and not be configurable, which can very easily lead to 
unpredictable failures


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

Reply via email to