[BUG] Change of behavior between KoP 0.3.0 (2.6.2) and 2.7+ using SASL #415
Comments
|
I don't understand well. Could you give a more detail explanation on how two clients exchange data? |
By "two clients exchange data", I just mean messages sent by a producer app are received by a consumer app. The test apps I run are basic and very similar to your Sarama/Confluent integration tests. The big difference is that my test apps have SASL configured. I can share my test apps with you if it will help. In my test case the producer has a different SASL username and password than the consumer. In 0.3.0 if the producer app and the consumer app have different SASL username, then the consumer will not receive messages from the producer. |
|
If you need log files, config or any other data please let me know. |
|
I get it. Currently the SASL/PLAIN mechanism for KoP only checks if the role has the permission for the specific namespace (username). However, the client could produce/consume to another namespace since there we have no checks for if the username that represents the namespace is what the topic belongs. I'll take a look at how to fix it when I'm free. |
Add authorization to handleTopicMetadataRequest(#236 ). Fix #415 and #571 ## Motivation When client fetch metadata need check topic permission, so we need add authorization in handleTopicMetadataRequest, and do not perform role verification in authentication. ## Modifications Add a common method in `KafkaRequestHandler#authorize` , this method use `authorizer` to authorization. Modify the authentication behavior, and do not verify the role during authentication, verify the role in fetch metadata(#571 )
…ative#662) Add authorization to handleTopicMetadataRequest(streamnative#236 ). Fix streamnative#415 and streamnative#571 ## Motivation When client fetch metadata need check topic permission, so we need add authorization in handleTopicMetadataRequest, and do not perform role verification in authentication. ## Modifications Add a common method in `KafkaRequestHandler#authorize` , this method use `authorizer` to authorization. Modify the authentication behavior, and do not verify the role during authentication, verify the role in fetch metadata(streamnative#571 )
Add authorization to handleTopicMetadataRequest(#236 ). Fix #415 and #571 ## Motivation When client fetch metadata need check topic permission, so we need add authorization in handleTopicMetadataRequest, and do not perform role verification in authentication. ## Modifications Add a common method in `KafkaRequestHandler#authorize` , this method use `authorizer` to authorization. Modify the authentication behavior, and do not verify the role during authentication, verify the role in fetch metadata(#571 )
Describe the bug
We noticed a change in behavior between KoP 0.3.0 (2.6.2) and 2.7+ using SASL with token authentication (#206?)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The desired behavior is to have SASL credentials prevent cross-talk between Kafka clients.
Additional context
We understand that Kafka is not normally multi-tenant, but we think the behavior seen in 0.3.0 is very useful. We are interested to know what the intentions/goals are here. Is the behavior we rely on with 0.3.0 the intended behavior, a side-effect of the original implementation, etc?
The text was updated successfully, but these errors were encountered: