Skip to content

Latest commit

 

History

History
101 lines (79 loc) · 7.33 KB

File metadata and controls

101 lines (79 loc) · 7.33 KB

Threat Model Analysis for apache/kafka

  • 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.
  • 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 and advertised.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

    • 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.