1.1 – Kafka Security Fundamentals & Threat Model

Overview

This module establishes the foundational mental model for Kafka security. Before diving into encryption, authentication, and authorization mechanisms, you must first understand:

• Why Kafka security matters in production deployments
• What attack surfaces exist in a Kafka cluster
• Where security threats originate
• How security layers work together

By the end of this module, you will understand the threat landscape and the layered security approach that Kafka provides.

This module provides high-level security context only. Specific mechanisms (TLS, SASL, ACLs) are covered in depth in their dedicated modules.

Why Kafka Security Matters

The Problem: Default Kafka is Insecure

Out-of-the-box Kafka has NO security:

• No encryption: All data travels in plaintext over the network.
• No authentication: Any client can connect to brokers without proving identity.
• No authorization: Any connected client can produce to any topic, consume from any topic, or delete topics.

Real-World Consequences:

1. Data Breach: Sensitive data (PII, financial records) exposed to network sniffers.
2. Unauthorized Access: Malicious actors can consume confidential event streams.
3. Data Corruption: Rogue producers can inject poison records into topics.
4. Service Disruption: Unauthorized clients can delete topics, pause partitions, or overload brokers.
5. Compliance Violations: Failure to meet GDPR, HIPAA, PCI-DSS, SOC 2 requirements.

Analogy: Running Kafka without security is like leaving your front door unlocked with a sign saying "Please don't steal anything."

Production Kafka Requires Security

Industry Standard Practice:

• Encryption: All data in transit must be encrypted (TLS/SSL).
• Authentication: All clients must prove their identity (SASL, mTLS).
• Authorization: Clients can only access resources they're permitted to (ACLs, RBAC).
• Audit Logging: All security events must be logged for compliance.

Business Drivers:

• Regulatory Compliance: GDPR, HIPAA, PCI-DSS mandate encryption and access control.
• Multi-Tenancy: Isolate topics/consumer groups per team/department.
• Zero Trust Architecture: Never trust, always verify (common in cloud-native deployments).

Industry-Specific Security Requirements

Kafka security requirements vary significantly by industry. Understanding your industry's compliance landscape helps prioritize security controls.

Financial Services

Use Cases:

• Real-time payment processing
• Fraud detection and prevention
• Trading platform event streams
• Transaction settlement

Data Sensitivity:

• Credit card numbers (PAN)
• Account balances and transaction history
• Customer PII (Social Security Numbers, DOB)
• Trading signals and positions

Regulatory Requirements:

• PCI-DSS Level 1 compliance (if processing card payments)
• SOX (Sarbanes-Oxley) for financial reporting
• GLBA (Gramm-Leach-Bliley Act) for consumer privacy
• FFIEC (Federal Financial Institutions Examination Council) guidance

Mandatory Security Controls:

• ✅ Encryption: TLS 1.2+ for all traffic (client-broker, inter-broker)
• ✅ Authentication: Strong SASL (SCRAM-SHA-512 or Kerberos, not PLAIN)
• ✅ Authorization: Fine-grained ACLs per application
• ✅ Audit Logging: Log all produce/consume operations for forensics
• ✅ Data Masking: Mask sensitive fields (e.g., card numbers) in non-prod environments
• ✅ Encryption at Rest: Encrypt Kafka log files on disk

Key Challenge: High-frequency trading requires low latency, but security adds overhead. Solution: Use hardware-accelerated encryption (AES-NI).

Healthcare

Use Cases:

• Patient monitoring (IoT medical devices)
• Electronic Health Records (EHR) streaming
• Real-time clinical decision support
• Claims processing

Data Sensitivity:

• PHI (Protected Health Information): diagnoses, prescriptions, lab results
• Patient demographics (name, address, SSN)
• Medical device telemetry

Regulatory Requirements:

• HIPAA (Health Insurance Portability and Accountability Act)
• HITECH (Health Information Technology for Economic and Clinical Health Act)
• BAA (Business Associate Agreement) required for third-party Kafka hosting

Mandatory Security Controls:

• ✅ Encryption: TLS encryption for PHI in transit
• ✅ Authentication: Multi-factor authentication for admin access
• ✅ Authorization: Role-based access (doctors, nurses, billing staff have different permissions)
• ✅ Audit Logging: Log every access to PHI (who viewed what, when)
• ✅ Data Retention Policies: Enforce minimum retention (6 years for Medicare) and maximum retention (don't keep data longer than necessary)
• ✅ Breach Notification: Alert system for unauthorized PHI access

Key Challenge: Medical IoT devices may not support strong authentication. Solution: Use gateway pattern with mTLS.

Internet of Things (IoT) / Telemetry

Use Cases:

• Connected vehicles (telematics)
• Smart home devices
• Industrial sensors (IIoT)
• Wearable devices

Data Sensitivity:

• Location data (GPS coordinates, travel patterns)
• Usage patterns (when devices are on/off, user behavior)
• Biometric data (heart rate, sleep patterns from wearables)

Regulatory Requirements:

• GDPR (if EU users): Requires consent for data collection, right to deletion
• CCPA (California Consumer Privacy Act)
• IoT Cybersecurity Improvement Act (US federal law for government IoT)

Mandatory Security Controls:

• ✅ Device Authentication: Each device has unique credentials (not shared passwords)
• ✅ Encrypted Communication: TLS for device-to-cloud communication
• ✅ Authorization: Devices can only write to their own topics (e.g., device-{id}/telemetry)
• ✅ Rate Limiting: Prevent compromised devices from flooding Kafka
• ✅ Certificate Management: Automate certificate rotation for millions of devices

Key Challenge: Resource-constrained devices (low CPU, memory). Solution: Use lightweight MQTT-to-Kafka bridge with authentication offload.

E-Commerce / Retail

Use Cases:

• Real-time inventory updates
• Order processing pipelines
• Customer behavior tracking (clickstream)
• Personalization engines

Data Sensitivity:

• Customer PII (name, email, address)
• Payment information (if stored)
• Purchase history

Regulatory Requirements:

• PCI-DSS (if processing payments)
• GDPR (if EU customers)
• COPPA (Children's Online Privacy Protection Act, if users under 13)

Mandatory Security Controls:

• ✅ Encryption: TLS for customer data
• ✅ Authentication: SASL for internal services
• ✅ Authorization: Marketing team can read clickstream, but not payment data
• ✅ Data Anonymization: Remove PII from analytics topics

Key Challenge: Black Friday / Cyber Monday traffic spikes. Solution: Pre-provision security capacity (TLS overhead during peak load).

Summary: Security Requirements by Industry

Key Takeaway: Security is not one-size-fits-all. Your industry dictates minimum security controls. Always consult compliance teams before designing Kafka security architecture.

Kafka Attack Surfaces

A Kafka deployment has multiple attack surfaces where threats can originate:

┌─────────────────────────────────────────────────────────────┐
│                    Kafka Cluster                            │
│                                                               │
│  ┌────────────┐      ┌────────────┐      ┌────────────┐   │
│  │  Broker 1  │◄────►│  Broker 2  │◄────►│  Broker 3  │   │
│  └──────▲─────┘      └──────▲─────┘      └──────▲─────┘   │
│         │                    │                    │          │
│         │                    │                    │          │
└─────────┼────────────────────┼────────────────────┼────────┘
          │                    │                    │
          │ (1) Client-Broker  │                    │
          │     Communication  │                    │
          │                    │                    │
     ┌────▼────┐          ┌───▼────┐          ┌───▼────┐
     │Producer │          │Consumer│          │ Admin  │
     └─────────┘          └────────┘          └────────┘
          │                    │                    │
          │ (2) Network        │                    │
          │     Sniffing       │                    │
          └────────────────────┴────────────────────┘

     ┌─────────────────────────────────────────────┐
     │ (3) Inter-Broker Communication              │
     │     (Replication, Controller, Metadata)     │
     └─────────────────────────────────────────────┘

     ┌─────────────────────────────────────────────┐
     │ (4) External Integrations                   │
     │     (Kafka Connect, Kafka Streams, ksqlDB)  │
     └─────────────────────────────────────────────┘

     ┌─────────────────────────────────────────────┐
     │ (5) Operational Access                      │
     │     (SSH to brokers, JMX, ZooKeeper/KRaft)  │
     └─────────────────────────────────────────────┘

Attack Surface 1: Client-Broker Communication

Risk: Clients (producers, consumers) connect to brokers over the network.

Threats:

• Eavesdropping: Attacker intercepts data in transit (e.g., credit card numbers in events).
• Impersonation: Attacker pretends to be a legitimate producer and injects malicious records.
• Unauthorized Access: Rogue consumer reads sensitive topics (e.g., user PII).

Mitigation (covered in later modules):

• Encryption: TLS/SSL (Module 2.1)
• Authentication: SASL (Module 3.x)
• Authorization: ACLs (Module 4.x)

Attack Surface 2: Network Sniffing

Risk: Kafka traffic travels over the network (LAN, WAN, internet).

Threats:

• Man-in-the-Middle (MITM): Attacker intercepts and modifies messages between client and broker.
• Packet Sniffing: Attacker captures unencrypted traffic with tools like Wireshark.

Mitigation:

• TLS Encryption: Encrypt all client-broker traffic (Module 2.1)
• Network Segmentation: Isolate Kafka network from public networks (Module 5.2)

Attack Surface 3: Inter-Broker Communication

Risk: Brokers communicate with each other for replication, controller metadata, and cluster coordination.

Threats:

• Rogue Broker: Attacker adds a malicious broker to the cluster, stealing replicated data.
• Replication Snooping: Attacker intercepts replication traffic to read all topics.

Mitigation:

• Inter-Broker TLS: Encrypt broker-to-broker traffic (Module 2.2)
• Mutual TLS: Brokers authenticate each other (Module 3.1)

Attack Surface 4: External Integrations (Connect, Streams, ksqlDB)

Risk: Kafka Connect, Kafka Streams, and ksqlDB applications are clients that access Kafka.

Threats:

• Connector Compromise: Attacker gains access to Kafka via a poorly secured connector.
• Streams Application Hijacking: Attacker deploys a rogue Streams app to read/write data.

Mitigation:

• Client Authentication: All external apps must authenticate (Module 3.3)
• ACLs: Limit Connect/Streams app access to specific topics/groups (Module 4.x)

Attack Surface 5: Operational Access

Risk: Operators need access to brokers for management (SSH, JMX, ZooKeeper/KRaft).

Threats:

• SSH Compromise: Attacker gains shell access to broker and steals log files.
• JMX Exploitation: Attacker modifies broker configs via JMX.
• ZooKeeper/KRaft Compromise: Attacker manipulates cluster metadata.

Mitigation:

• SSH Hardening: Disable password auth, use SSH keys (Module 5.1)
• JMX Authentication: Secure JMX with authentication (Module 5.1)
• ZooKeeper ACLs: Protect ZooKeeper metadata (Module 5.1)
• KRaft Security: Secure KRaft quorum (Module 5.1)

Attack Surface 6: Broker-ZooKeeper Communication (Legacy)

Risk: In pre-KRaft deployments, brokers communicate with ZooKeeper for cluster metadata, controller election, and configuration storage.

Threats:

• ZooKeeper Compromise: Attacker gains access to ZooKeeper and modifies cluster metadata (e.g., changes partition assignments, deletes topics).
• Metadata Snooping: Attacker intercepts broker-ZooKeeper traffic to read partition assignments, controller IDs, replica configurations.
• Split-Brain Scenario: Attacker manipulates ZooKeeper data to cause multiple brokers to believe they are the controller.
• Data Injection: Attacker writes malicious metadata to ZooKeeper, causing brokers to behave incorrectly.

Example Attack:

Attacker compromises ZooKeeper node
    │
    ├─► Modifies /brokers/topics/orders metadata
    │   (changes replica assignment)
    │
    └─► Kafka controller reads corrupted metadata
        │
        └─► Controller reassigns partitions to non-existent brokers
            │
            └─► Topic becomes unavailable (all ISR replicas offline)

Mitigation:

• ZooKeeper TLS: Encrypt broker-ZooKeeper communication (covered in Module 5.1)
• ZooKeeper SASL: Authenticate brokers to ZooKeeper using Kerberos or Digest-MD5 (covered in Module 5.1)
• ZooKeeper ACLs: Restrict which Kafka brokers can read/write specific ZooKeeper znodes
• Network Segmentation: Isolate ZooKeeper on a private network, not accessible from public internet
• KRaft Migration: Eliminate ZooKeeper entirely by migrating to KRaft mode (covered in Module 6.1)

KRaft vs. ZooKeeper Security Comparison:

Note: In KRaft mode (Kafka 3.0+), this attack surface is completely eliminated, significantly simplifying security posture. New deployments should use KRaft; existing deployments should plan ZooKeeper removal.

Kafka Threat Model

Threat Actors

Common Attack Scenarios

Scenario 1: Unencrypted Data Exfiltration

Attack Flow:

1. Attacker gains access to the same network as Kafka cluster (e.g., compromised VM in AWS VPC).
2. Attacker runs packet sniffer (e.g., tcpdump, Wireshark).
3. Attacker captures all Kafka traffic in plaintext.
4. Attacker extracts sensitive data (PII, credit card numbers, API keys).

Prevention:

• Enable TLS encryption (Module 2.1)
• Use network segmentation (Module 5.2)

Scenario 2: Unauthorized Topic Access

Attack Flow:

1. Attacker obtains network access to Kafka brokers (e.g., misconfigured firewall).
2. Kafka has no authentication enabled (default).
3. Attacker runs kafka-console-consumer to read all topics.
4. Attacker exfiltrates sensitive data.

Prevention:

• Enable SASL authentication (Module 3.x)
• Enable ACLs to restrict topic access (Module 4.x)

Scenario 3: Malicious Record Injection

Attack Flow:

1. Attacker gains access to Kafka cluster (no authentication).
2. Attacker writes poison records to critical topics (e.g., payment events).
3. Downstream consumers process malicious data, leading to data corruption or service disruption.

Prevention:

• Enable SASL authentication (Module 3.x)
• Enable ACLs to restrict producer access (Module 4.x)
• Use schema validation (Schema Registry) to reject invalid records

Scenario 4: Topic Deletion

Attack Flow:

1. Attacker gains cluster admin access (no authentication).
2. Attacker runs kafka-topics --delete --topic critical-topic.
3. Topic and all data are deleted, causing service outage.

Prevention:

• Enable SASL authentication (Module 3.x)
• Enable ACLs to restrict Delete operations (Module 4.x)
• Disable delete.topic.enable in production (Module 5.1)

Scenario 5: Man-in-the-Middle (MITM) Attack

Attack Flow:

1. Attacker positions themselves between client and broker (e.g., ARP spoofing).
2. Client connects to broker without TLS.
3. Attacker intercepts and modifies messages in transit.

Prevention:

• Enable TLS encryption (Module 2.1)
• Use certificate validation to prevent MITM (Module 2.3)

Security Layers in Kafka

Kafka security is structured in five layers, each addressing a specific threat:

┌─────────────────────────────────────────────────────────┐
│ Layer 5: End-to-End Security & Operational Practices   │
│   • Secure deployment blueprints                       │
│   • Security checklists                                 │
│   • Monitoring & incident response                      │
└─────────────────────────────────────────────────────────┘
                        ▲
                        │
┌─────────────────────────────────────────────────────────┐
│ Layer 4: Operational Security & Hardening              │
│   • Broker hardening                                    │
│   • Network segmentation                                │
│   • Secrets management                                  │
└─────────────────────────────────────────────────────────┘
                        ▲
                        │
┌─────────────────────────────────────────────────────────┐
│ Layer 3: Authorization (Access Control)                │
│   • ACLs (Access Control Lists)                         │
│   • RBAC (Role-Based Access Control)                    │
│   • Resource permissions                                │
└─────────────────────────────────────────────────────────┘
                        ▲
                        │
┌─────────────────────────────────────────────────────────┐
│ Layer 2: Authentication (Identity)                     │
│   • SASL/PLAIN, SASL/SCRAM                              │
│   • SASL/GSSAPI (Kerberos)                              │
│   • SASL/OAUTHBEARER                                    │
│   • Mutual TLS (mTLS)                                   │
└─────────────────────────────────────────────────────────┘
                        ▲
                        │
┌─────────────────────────────────────────────────────────┐
│ Layer 1: Encryption (Transport Security)               │
│   • TLS/SSL for client-broker communication             │
│   • Inter-broker encryption                             │
│   • Certificate management                              │
└─────────────────────────────────────────────────────────┘

Layer 1: Encryption (Transport Security)

Purpose: Protect data in transit from eavesdropping and tampering.

Mechanisms:

• TLS/SSL: Encrypts all traffic between clients and brokers.
• Inter-Broker TLS: Encrypts replication and controller traffic.

Covered in Module 2 (Encryption & Transport Security).

Key Point: Encryption alone does NOT prevent unauthorized access. A client can still connect and read data if authentication is disabled.

Layer 2: Authentication (Identity)

Purpose: Verify the identity of clients and brokers.

Mechanisms:

• SASL/PLAIN: Username/password authentication (not recommended for production).
• SASL/SCRAM: Secure salted challenge-response authentication.
• SASL/GSSAPI (Kerberos): Enterprise authentication with centralized identity.
• SASL/OAUTHBEARER: OAuth-based authentication (modern, cloud-native).
• Mutual TLS (mTLS): Certificate-based authentication (client presents a cert).

Covered in Module 3 (Authentication Mechanisms).

Key Point: Authentication proves WHO you are, but not WHAT you can do. You need authorization (ACLs) for that.

Layer 3: Authorization (Access Control)

Purpose: Control what authenticated clients can do (read, write, delete).

Mechanisms:

• ACLs (Access Control Lists): Kafka's native authorization model.
• RBAC (Role-Based Access Control): Confluent Platform's enterprise authorization (built on ACLs).

Covered in Module 4 (Authorization & Access Control).

Key Point: ACLs are applied AFTER authentication. An authenticated client can only perform operations allowed by ACLs.

Layer 4: Operational Security & Hardening

Purpose: Secure the Kafka cluster infrastructure and operational practices.

Practices:

• Broker Hardening: Disable insecure listeners, configure secure defaults.
• Network Segmentation: Isolate Kafka from public networks, use firewalls.
• Secrets Management: Store credentials in Vault, AWS Secrets Manager, etc.

Covered in Module 5 (Operational Security & Hardening).

Layer 5: End-to-End Security & Operational Practices

Purpose: Combine all security layers into a cohesive, production-ready deployment.

Covers:

• Secure cluster blueprints
• Secure client connection flows
• Common misconfigurations
• Security checklists

Covered in Module 6.1 (Kafka Security End-to-End).

Security vs. Performance Trade-offs

Security mechanisms add overhead. Understanding trade-offs helps you balance security and performance.

TLS Encryption Overhead

Impact: ~5-10% latency increase, ~10-20% throughput reduction (CPU-bound).

Reason: TLS encryption/decryption consumes CPU cycles.

Mitigation:

• Use modern CPUs with AES-NI hardware acceleration.
• Offload TLS to network proxies (e.g., Envoy) if needed.

Decision: Always enable TLS in production. The performance cost is acceptable for the security gain.

SASL Authentication Overhead

Impact: ~1-3ms per connection establishment (one-time cost).

Reason: SASL handshake adds extra round-trips.

Mitigation:

• Use connection pooling to amortize handshake cost.
• Use SCRAM instead of PLAIN for better security without extra latency.

Decision: Always enable SASL in production. The cost is negligible after connection establishment.

ACL Authorization Overhead

Impact: ~0.1-1ms per request (broker checks ACLs before allowing operations).

Reason: Broker must look up permissions for each request.

Mitigation:

• Keep ACL count reasonable (< 10,000 ACLs per cluster).
• Use wildcard ACLs (topic=prefix*) to reduce ACL count.

Decision: Always enable ACLs in production. The overhead is minimal and essential for security.

Summary Table: Security Overhead

Key Takeaway: Security overhead is acceptable and necessary for production deployments. The alternative (no security) is catastrophic.

Operational Complexity Trade-offs

Beyond performance, security adds operational overhead. Understanding these costs helps you plan resources and tooling.

Hidden Costs:

1. Training: Security team must learn Kafka security model (~40 hours initial training).
2. Incident Response: Plan for security incidents (credential leaks, unauthorized access) — requires runbooks and on-call rotation.
3. Multi-Environment Sync: Keep security configs consistent across dev/staging/prod (use GitOps/IaC).
4. Vendor Coordination: If using managed Kafka (Confluent Cloud, AWS MSK), coordinate security changes with vendor SLAs.

Example: Real-World Effort for 50-Broker Cluster:

• Initial Security Setup: ~80-120 hours (TLS certs, SASL config, initial ACLs, monitoring)
• Ongoing Maintenance: ~20-30 hours/month (cert rotation, ACL changes, security audits, incident response)

Key Point: Security overhead is operational, not just technical. Budget for:

• Dedicated security engineer or part-time security focus for platform team
• Tools and automation (Vault, Cert-Manager, Terraform)
• Training and documentation
• Incident response planning

Recommendation: Start security planning before production launch. Retrofitting security to an insecure cluster is 10x harder than building it in from day one.

Development vs Production Security

Common Dilemma: Security adds complexity. Should you enable it in dev environments?

Pro Tips for Dev Environments:

1. Use Docker Compose with Pre-Configured SSL: Avoid manual certificate generation overhead. Example: Confluent's cp-demo project provides ready-to-run secure Kafka.

   git clone https://github.com/confluentinc/cp-demo
   cd cp-demo
   ./scripts/start.sh  # Starts Kafka with TLS + SASL + ACLs
   

2. Simplified Local Testing: For solo dev, use Testcontainers or embedded Kafka without security:

   @Container
   KafkaContainer kafka = new KafkaContainer(DockerImageName.parse("confluentinc/cp-kafka:7.5.0"));
   // No TLS, SASL, or ACLs needed for unit tests
   

3. Staging as Security Gatekeeper: Never deploy to production without staging security validation. Common staging tests:

   • Can clients with invalid credentials connect? (Should fail)
   • Can consumer read unauthorized topic? (Should fail)
   • Does certificate expiration trigger alerts? (Should succeed)

Warning: If you never test with security enabled in dev/staging, you'll face a painful surprise in production when:

• Authentication errors appear for the first time
• ACL misconfigurations block legitimate traffic
• Certificate expiration causes outages
• Performance degrades due to TLS overhead (should have been benchmarked in staging)

Trade-off Table:

Key Takeaway: The security gap between dev and production is where most outages happen. Minimize that gap by enabling security in staging at minimum.

Security Principles for Kafka

1. Defense in Depth

Definition: Use multiple layers of security, so if one layer fails, others still protect.

Example:

• Layer 1: TLS encryption (prevents eavesdropping)
• Layer 2: SASL authentication (prevents impersonation)
• Layer 3: ACLs (prevents unauthorized operations)
• Layer 4: Network segmentation (prevents lateral movement)

Rationale: A single compromised credential won't lead to full cluster compromise.

2. Principle of Least Privilege

Definition: Grant clients only the minimum permissions required for their function.

Example:

• Producer app: Write-only to orders topic, no read/delete permissions.
• Consumer app: Read-only from orders topic, no write/delete permissions.
• Admin user: Full cluster permissions, but only accessible via bastion host.

Rationale: Limits blast radius if a client is compromised.

3. Zero Trust Architecture

Definition: Never trust, always verify. Assume breach and enforce identity at every layer.

Example:

• Every client must authenticate (no "trusted network" assumption).
• Every operation must be authorized (no implicit permissions).
• All traffic must be encrypted (even within VPC).

Rationale: Common in cloud-native deployments where network boundaries are fluid.

4. Audit Everything

Definition: Log all security events for forensics and compliance.

What to Audit:

• Authentication attempts (success and failure)
• Authorization denials
• Topic creation/deletion
• ACL changes

Tools: Kafka Audit Logs, SIEM (Splunk, ELK), CloudTrail (AWS).

Rationale: Enables incident response and meets compliance requirements (GDPR, HIPAA).

What This Module Does NOT Cover

To maintain focus, this module intentionally excludes technical implementation details:

❌ TLS Configuration: Covered in Module 2.1
❌ SASL Mechanisms: Covered in Module 3.x
❌ ACL Syntax: Covered in Module 4.x
❌ Broker Hardening: Covered in Module 5.x
❌ Security Checklists: Covered in Module 6.1

This module provides the mental model. Subsequent modules provide the mechanisms.

Key Takeaways

1. Default Kafka is insecure: No encryption, authentication, or authorization out-of-the-box.
2. Five attack surfaces: Client-broker, network, inter-broker, external integrations, operational access.
3. Five security layers: Encryption → Authentication → Authorization → Hardening → End-to-End.
4. Common threats: Eavesdropping, impersonation, unauthorized access, MITM, data deletion.
5. Security overhead is acceptable: ~5-10% performance cost for TLS/SASL/ACLs is industry standard.
6. Defense in depth: Use multiple security layers to mitigate cascading failures.
7. Least privilege: Grant minimum required permissions to clients.
8. Audit everything: Log all security events for compliance and forensics.

What's Next?

• Module 2.1: TLS/SSL Encryption Between Clients & Brokers (encryption layer)
• Module 3.1: SASL Overview & Handshake Flow (authentication layer)
• Module 4.1: ACL Model & Permission Semantics (authorization layer)
• Module 6.1: Kafka Security End-to-End (putting it all together)

Further Reading

• Kafka Security Documentation
• Confluent Security Best Practices
• NIST Cybersecurity Framework
• OWASP Top 10

End of Module 1.1