[kafka] Filter requests by API key #36978
Assignees
Labels
Comments
adamkotwasinski
added
enhancement
|
/assign @adamkotwasinski |
mattklein123
pushed a commit
that referenced
this issue
Nov 5, 2024
Commit Message: kafka: close connection when rejectable request appears Additional Description: provides #36978 by making the broker filter check the requests' API key against allow/denylists in the config - if we find a request to reject, we just close the connection. There is also a bonus: this sets up a framework for "_close connection if we don't like the request_" that we can expand upon later. Risk Level: Low Testing: automated (no filtering) + manual (filtering) Docs Changes: Kafka broker .rst Release Notes: n/a Platform Specific Features: n/a --------- Signed-off-by: Adam Kotwasinski <adam.kotwasinski@gmail.com>
update-envoy bot
added a commit
to envoyproxy/data-plane-api
that referenced
this issue
Nov 5, 2024
Commit Message: kafka: close connection when rejectable request appears Additional Description: provides envoyproxy/envoy#36978 by making the broker filter check the requests' API key against allow/denylists in the config - if we find a request to reject, we just close the connection. There is also a bonus: this sets up a framework for "_close connection if we don't like the request_" that we can expand upon later. Risk Level: Low Testing: automated (no filtering) + manual (filtering) Docs Changes: Kafka broker .rst Release Notes: n/a Platform Specific Features: n/a --------- Signed-off-by: Adam Kotwasinski <adam.kotwasinski@gmail.com> Mirrored from https://github.com/envoyproxy/envoy @ c30d173544a6ac6646201f8766eb851c7c9e0bc6
|
Delivered through ability to configure broker filter : https://github.com/envoyproxy/envoy/pull/36979/files#diff-437067755aa99b1d71e1b0acbdc55e296d1a0f617ecb19287f1afa1568d5d5ddR182 |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Title: Filter requests by API key
Description:
Filter requests by API key.
This allows us to provide finer-grained control over what Kafka clients (consumers/producers) can do when they use particular endpoints for the Kafka cluster.
The perfect world would be single Kafka cluster with two sets of listeners where clients can connect - one set dedicated for producers, and one for consumers. Connecting to the wrong one and sending an unsupported request would then deny the forwarding upstream. Response rewriting would take care of advertising two sets of listeners, so the real Kafka addresses would not be propagated to the users.
This allows the proxy to control the access to Kafka without requiring any changes to the upstream cluster's / downstream clients' configuration.
The text was updated successfully, but these errors were encountered: