krishvishal opened a new issue, #4518: URL: https://github.com/apache/iggy/issues/4518
Follow-up to #3549. ## Summary Produce, Fetch, offsets and CreateTopics act as the bridge's Iggy user for every client. Only DeleteTopics and AlterConfigs test `manage_topics`. CreateAcls (30) and DeleteAcls (31) are not served. DescribeAcls answers only with SASL on, and only for the caller. Who hits it: - Deployments where teams must not read each other's topics. Today any authenticated client reads and writes all that the bridge user can, and nothing reports it. - `kafka-acls --add` and `--remove`, the Strimzi User Operator, Terraform `kafka_acl` and `kafka_quota`, JulieOps, and MirrorMaker 2 ACL sync. ## Open question How does the gateway act for a user on each request: with an Iggy way to act for a user on one session, or with one Iggy session per principal? ## Scope - [ ] Carry the principal to the data plane, as `gateways/kafka/docs/AUTHENTICATION.md` intends - [ ] Map Kafka operations to Iggy permissions, and CreateAcls and DeleteAcls to permission changes. The mapping loses detail, so define what is refused - [ ] Client quotas (48 and 49) only on request - [ ] Update `gateways/kafka/docs/ACL_MAPPING.md` ## Acceptance criteria - [ ] A principal without read permission on a topic gets `TOPIC_AUTHORIZATION_FAILED` (29) on Fetch - [ ] `kafka-acls --add` grants a permission that the next request honors ## References - `gateways/kafka/docs/AUTHENTICATION.md`, `gateways/kafka/docs/ACL_MAPPING.md` - #4340, "Out of scope": requests still run as the bridge's service account -- 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]
