| title | Kafka Streams Security Model | |||
|---|---|---|---|---|
| description | Apache Kafka Streams Security Model | |||
| weight | 10 | |||
| tags |
|
|||
| aliases | ||||
| keywords | ||||
| type | docs |
This page extends the Apache Kafka security model to Kafka Streams. From the cluster's perspective a Streams application is an ordinary Kafka client and inherits the broker's authentication, authorization, and transport-encryption model through the same ssl.* and sasl.* client configs.
- Streams is a client library, not a service. It runs inside your application's process, so its security boundary is the application's; there is no separate Streams network surface to secure.
- A Streams application authenticates as a single principal. That principal needs ACLs covering its source topics, its internal repartition/changelog topics (typically
<application.id>-*), and the consumer group<application.id>. - Local state lives on disk. State stores and their changelogs are only as protected as the host filesystem and the broker's at-rest story; Kafka does not encrypt them.
In line with the core model's classification, the following are not, on their own, security vulnerabilities:
- Application-level issues in a Streams topology. Streams runs inside the user's application, so bugs in user-supplied processors, state handling, or topology code fall within the application's trust boundary, not the broker's.
- Local state being readable on the host. State stores and changelogs on disk are protected by the host filesystem, not by Kafka; reading them requires local access that is outside the model.