Securing Kafka against DDoS attacks.

Instruction: Discuss measures to protect a Kafka cluster from DDoS attacks and other malicious activities.

Context: This question probes the candidate's knowledge of network security as it pertains to Kafka, highlighting considerations for securing Kafka deployments in hostile environments.

Updated

Official answer

Use layered protection that matches Kafka's network protocol and the actual threat model. Keep brokers and controller listeners private where possible, restrict reachable networks and ports, and separate administrative access from application traffic. Do not expose a controller listener to ordinary clients.

Use TLS with the required peer verification, an appropriate authenticated identity mechanism, and least-privilege authorization. Protect and rotate credentials. Authentication and ACLs constrain identity/actions but do not prevent an attacker from saturating a network link or consuming handshake resources.

Configure Kafka quotas and connection controls deliberately. Producer/consumer bandwidth quotas are measured in bytes per second, and request quotas account for request-processing resources; they are not a universal messages-per-second limit. Broker/listener connection and connection-creation controls address another resource dimension. Apply identities and defaults carefully so a client cannot evade an intended quota merely by choosing another untrusted client ID. Check the deployed version's exact settings and behavior.

For traffic that can reach a public network boundary, use upstream network filtering or a DDoS service that explicitly supports the Kafka TCP endpoints, ports, routing and TLS arrangement. A generic HTTP CDN/reverse proxy is not automatically a suitable Kafka front end. Broker quotas act too late to protect an already saturated upstream link.

Monitor connection/authentication failures, request rates, throttling, network saturation and broker/controller health. Maintain an incident runbook for isolating abusive identities/paths while preserving legitimate traffic and internal replication. Test limits with authorized bounded load, keep software patched and verify recovery. These controls reduce exposure and impact; they do not guarantee immunity to every denial-of-service event.

Sources

Kafka security overview; Kafka quotas; broker connection controls.

Related Questions