-
Threat: Unauthorized Topic Access (Read/Write)
- Description: An attacker gains access to a Kafka topic they are not authorized to read from or write to. They might use stolen credentials, exploit a misconfigured ACL, or leverage a vulnerability in a Kafka client library. The attacker could inject malicious messages (if writing) or steal sensitive data (if reading).
- Impact: Data breach (confidentiality violation), data corruption (integrity violation), potential for downstream system compromise if malicious data is processed.
- Affected Kafka Component: Broker (authorization logic within
kafka.server.KafkaApis
), potentially Zookeeper/KRaft (if ACLs are stored there). - Risk Severity: Critical (if sensitive data is involved) or High (for non-sensitive data).
- Mitigation Strategies:
- Implement strong authentication (SASL/PLAIN, SASL/SCRAM, Kerberos, OAuth).
- Use TLS/SSL encryption for client-broker communication.
- Configure and enforce Kafka ACLs (Access Control Lists) to restrict topic access.
- Regularly review and audit ACL configurations.
- Use principle of least privilege: grant only necessary permissions to clients.
-
Threat: Denial of Service via Message Flooding
- Description: An attacker sends a massive number of messages to a Kafka topic, overwhelming the Kafka brokers and preventing legitimate producers and consumers from functioning correctly. This could be a targeted attack or a result of a compromised Kafka producer.
- Impact: Service outage, data loss (if retention policies are exceeded), performance degradation for all clients using the cluster.
- Affected Kafka Component: Broker (message handling, storage, replication within
kafka.log.Log
and related components), potentially Zookeeper/KRaft (if under heavy load due to metadata updates). - Risk Severity: High.
- Mitigation Strategies:
- Implement producer quotas (using
producer.quota.bytes.per.second.default
and related Kafka configurations). - Monitor broker resource utilization (CPU, memory, disk I/O, network).
- Set up alerts for high message rates and resource exhaustion.
- Use Kafka's dynamic configuration capabilities to adjust quotas in real-time.
- Implement producer quotas (using
Threat: Rogue Broker Injection
-
Threat: Rogue Broker Injection
- Description: An attacker introduces a malicious Kafka broker into the cluster. This rogue broker could intercept, modify, or redirect data, or disrupt the cluster's operation.
- Impact: Data breach, data corruption, denial of service, complete cluster compromise.
- Affected Kafka Component: Entire Kafka cluster, Zookeeper/KRaft (broker registration). The
kafka.server.KafkaServer
class is directly affected. - Risk Severity: Critical.
- Mitigation Strategies:
- Use TLS/SSL with mutual authentication (mTLS) for inter-broker communication.
- Configure
listeners
andadvertised.listeners
correctly within the Kafka broker configuration. - Regularly audit the cluster configuration and broker membership.
- Use a secure configuration management system for Kafka deployments.
- Monitor for unexpected broker additions.
Threat: Zookeeper/KRaft Compromise
-
Threat: Zookeeper/KRaft Compromise
- Description: An attacker gains control of the Zookeeper/KRaft ensemble, which stores critical Kafka metadata (topic configurations, consumer group information, ACLs). This allows the attacker to manipulate the cluster, disrupt service, or steal data.
- Impact: Complete cluster compromise, data loss, denial of service, data breach.
- Affected Kafka Component: Zookeeper/KRaft ensemble, entire Kafka cluster. This is a direct attack on a core Kafka dependency.
- Risk Severity: Critical.
- Mitigation Strategies:
- Secure Zookeeper/KRaft with strong authentication and authorization.
- Use network security controls to restrict access to Zookeeper/KRaft from outside the Kafka cluster.
- Regularly patch and update Zookeeper/KRaft.
- Monitor Zookeeper/KRaft for suspicious activity.
- Implement a robust backup and recovery plan for Zookeeper/KRaft data.
-
Threat: Message Tampering in Transit (Without TLS)
- Description: An attacker intercepts and modifies messages as they are transmitted between producers, brokers, and consumers if TLS/SSL is not used. This could involve a man-in-the-middle attack.
- Impact: Data corruption, integrity violation, potential for downstream system compromise.
- Affected Kafka Component: Network communication between Kafka producers, Kafka brokers, and Kafka consumers.
- Risk Severity: High.
- Mitigation Strategies:
- Use TLS/SSL encryption for all communication (client-broker, inter-broker). This is the primary mitigation.
- Enable client authentication (SASL) in conjunction with TLS.
-
Threat: Data Modification at Rest (Broker Storage)
- Description: An attacker with physical or privileged access to the Kafka broker's storage directly modifies the Kafka data files, bypassing Kafka's internal mechanisms.
- Impact: Data corruption, data loss, integrity violation.
- Affected Kafka Component: Broker's storage (log segments, specifically
kafka.log.LogSegment
files). - Risk Severity: High.
- Mitigation Strategies:
- Use disk encryption (e.g., LUKS) to protect data at rest on the Kafka broker machines.
- Implement strict file system permissions to limit access to Kafka data directories.
- Run Kafka brokers with a non-root user.
- Regularly monitor file integrity.
-
Threat: Unpatched Kafka Vulnerability Exploitation (Broker/Client)
- Description: An attacker exploits a known or zero-day vulnerability in the Kafka broker software or Kafka client libraries.
- Impact: Varies depending on the vulnerability, but could range from denial of service to complete system compromise.
- Affected Kafka Component: Any vulnerable component (broker, client library).
- Risk Severity: Varies (High to Critical).
- Mitigation Strategies:
- Keep Kafka brokers and all Kafka client libraries up to date with the latest security patches.
- Regularly scan for vulnerabilities.
- Subscribe to security mailing lists and advisories for Kafka.
- Implement a robust patch management process.