Skip to main content
Hello and welcome back. In this lesson we’ll explain core Kafka security concerns using a concise banking example and show practical controls you can apply. This article covers the common threats and recommended defenses so teams can make informed choices about confidentiality, integrity, and access control for event data.

​
Example scenario

Imagine a banking application that produces events to a Kafka cluster:
  • When a customer logs in, the app produces an event to the topic login-events.
  • When a payment occurs, the app produces an event to the topic card-payment-event.
Various internal consumers (microservices, analytics pipelines, or partner systems) read these topics. Because these topics may contain sensitive customer information, we must answer several security questions:
  • Are events protected while in transit from producers/consumers to brokers?
  • Who is consuming these events and are they authorized to read them?
  • How is the data stored on broker disks protected?

​
Producers and consumers

  • Producers: banking app writing to login-events and card-payment-event.
  • Consumers: internal data consumers that read one or both topics.
From a security perspective you should ensure:
  • Encryption for data in transit (TLS).
  • Strong client authentication and authorization (SASL / OAuth + ACLs or RBAC).
  • Protection of data at rest (disk-level encryption or application-level encryption).

​
Data in transit: TLS (encryption and client auth)

Encrypt connections between clients and brokers using TLS. For mutual TLS, enable client certificate authentication so brokers verify producer/consumer identities. Example server-side configuration snippets (server.properties):
Client-side properties for an SSL/TLS producer/consumer:
Notes:
  • Use strong cipher suites and rotate certificates regularly.
  • Consider standard PKI (internal CA or cloud-managed) to simplify certificate management.

​
Authentication and authorization: SASL, OAuth, ACLs, RBAC

Kafka supports multiple authentication mechanisms:
  • SASL/SCRAM for username/password.
  • SASL/GSSAPI for Kerberos.
  • SASL/OAUTHBEARER for OAuth2 tokens.
Combine authentication with authorization controls (ACLs or RBAC) to enforce least privilege. Example: grant a user produce permission to card-payment-event and consume permission to login-events using kafka-acls.sh:
If you use a managed Kafka (Confluent Cloud, MSK, etc.), you may have RBAC constructs and cloud IAM integration instead of raw ACLs. Best practices:
  • Enforce least privilege per topic and per client.
  • Use short-lived tokens (OAuth) or rotate SCRAM credentials regularly.
  • Log and audit ACL changes and authentication events.

​
Data at rest: disk encryption and application-level encryption

Protect broker storage:
  • Use OS-level disk encryption or cloud provider-managed encryption (e.g., AWS EBS encryption, Azure Disk Encryption).
  • Enable full-disk encryption for on-prem clusters.
  • For extremely sensitive fields, apply application-level or field-level encryption before producing to Kafka.
Remember: encryption-at-rest protects against physical disk compromise, but application-level encryption is required to protect sensitive fields from authorized Kafka consumers that should not see raw values.

​
Schemas and serialization

Use schema registries and structured serialization (Avro, Protobuf) to:
  • Enforce schema compatibility.
  • Prevent accidental schema drift and certain misuse patterns.
However, schema enforcement does not provide confidentiality—serialization is orthogonal to encryption and access control.
The image is a diagram about Kafka Security, highlighting potential security questions related to data in transit, data storage, and consumer access to topics. It includes components like topics "LoginEvents" and "CardPaymentEvent," and consumers.

​
Summary — three primary layers to secure

  1. Data in transit — ensure TLS between clients and brokers and consider client certificate authentication.
  2. Authentication & authorization — ensure only allowed clients can access specific topics (SASL/Kerberos/OAuth + ACLs or RBAC).
  3. Data at rest — ensure stored data on broker disks is encrypted (disk encryption or application-level encryption).

​
Quick security checklist

  • Enable encryption-in-transit (TLS) for all listeners.
  • Require client authentication for production clusters.
  • Use SCRAM/Kerberos/OAuth for client authentication and integrate with IAM where possible.
  • Apply topic-level ACLs or RBAC and follow least privilege.
  • Encrypt broker disks or use provider-managed encryption.
  • Consider application-level encryption for highly sensitive fields.
  • Enforce schemas (Avro/Protobuf) to reduce data-quality issues and accidental misuse.
  • Enable logging and auditing for authentication and ACL changes.
When designing Kafka security for sensitive data, combine encryption-in-transit, strong authentication/authorization, and encryption-at-rest. Consider least-privilege access for consumers and evaluate whether additional protections (such as field-level encryption or tokenization) are required for highly sensitive fields.
Specific Kafka features and configurations you can use to implement each layer of protection will be covered in a future article. References and further reading

Watch Video