This is an automated email from the ASF dual-hosted git repository.
clolov pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/kafka.git
The following commit(s) were added to refs/heads/trunk by this push:
new a5c31c4ac6f MINOR: A starting point for a formal security model
(#22398)
a5c31c4ac6f is described below
commit a5c31c4ac6fa5d9f8144da25c7034eb1fb7d51e8
Author: Christo Lolov <[email protected]>
AuthorDate: Fri Jun 12 19:19:15 2026 +0100
MINOR: A starting point for a formal security model (#22398)
This starting point has been inspired by other security models of Apache
projects such as [Apache
Tomcat](https://tomcat.apache.org/security-model.html) and [Apache
Spark](https://spark.apache.org/docs/latest/security.html).
Reviewers: Mickael Maison
<[email protected]>
---
AGENTS.md | 31 ++++++
SECURITY.md | 38 +++++++
docs/security/security-model-connect.md | 93 ++++++++++++++++++
docs/security/security-model-streams.md | 42 ++++++++
docs/security/security-model.md | 169 ++++++++++++++++++++++++++++++++
5 files changed, 373 insertions(+)
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 00000000000..d38382e94ba
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,31 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Agent Guide for Apache Kafka
+
+This file is read by automated agents (security scanners, code analyzers,
+AI assistants) operating on this repository.
+
+## Security
+
+See [SECURITY.md](./SECURITY.md) for how to report a vulnerability and for
links
+to the Apache Kafka security model under [docs/security/](./docs/security/).
+
+Agents that scan this repository should consult `SECURITY.md` and the linked
+security model before reporting issues. In particular, the core model defines
+what is in and out of scope, how reports are classified, and a list of known
+non-findings; each component page adds its own known non-findings.
\ No newline at end of file
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 00000000000..e488fe050ff
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,38 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# Security Policy
+
+## Reporting a Vulnerability
+
+Report suspected security vulnerabilities privately to
`[email protected]`,
+following the [ASF security process](https://www.apache.org/security/). Do
**not**
+open public GitHub issues or pull requests, file public JIRA tickets, or post
to
+mailing lists for unpatched vulnerabilities.
+
+Disclosed CVEs and their affected version ranges are published at
+[kafka.apache.org/cve-list](https://kafka.apache.org/cve-list).
+
+## Security Model
+
+What is in and out of scope, how reports are classified, and the list of known
+non-findings are documented in the Apache Kafka security model under
+[docs/security/](./docs/security/):
+
+- Core model:
[docs/security/security-model.md](./docs/security/security-model.md)
+- Kafka Connect:
[docs/security/security-model-connect.md](./docs/security/security-model-connect.md)
+- Kafka Streams:
[docs/security/security-model-streams.md](./docs/security/security-model-streams.md)
diff --git a/docs/security/security-model-connect.md
b/docs/security/security-model-connect.md
new file mode 100644
index 00000000000..613d7535cfe
--- /dev/null
+++ b/docs/security/security-model-connect.md
@@ -0,0 +1,93 @@
+---
+title: Kafka Connect Security Model
+description: Apache Kafka Connect Security Model
+weight: 9
+tags: ['kafka', 'docs', 'security']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+This page extends the [Apache Kafka security model](security-model) to Kafka
Connect. A worker authenticates to the Kafka cluster over a configured
`SASL_SSL`/`SSL` listener exactly like any other client, so everything the core
model says about authentication, authorization, and transport encryption to the
brokers applies unchanged. What follows covers only what Connect adds on top —
chiefly its own control plane, the REST API, and the fact that it runs
user-supplied code.
+
+## Things You Need To Know
+
+- **Connect inherits the broker's client security model.** Authentication to
the brokers, broker-side authorization, and transport encryption are exactly as
described in the [core security model](security-model). This page only
describes what Connect layers on top.
+- **The REST API is unauthenticated by default.** Out of the box, anyone who
can reach the REST port can create, reconfigure, stop, or delete any connector.
Because connectors and plugins run arbitrary code, REST access lets a caller
run anything the worker's installed plugins allow.
+- **Connect plugins run arbitrary code.** Connectors, converters,
transformations, predicates, and REST extensions loaded from `plugin.path`
execute in the worker JVM with its privileges. Install only plugins you trust.
+- **The REST API is a shared control plane with no per-connector isolation.**
There is no notion of connector ownership: any caller allowed onto the API can
act on every connector and read its configuration.
+- **A worker authenticates to Kafka as a single principal.** By default all
connectors on a worker share that principal's identity and ACLs; Connect does
not give each connector a distinct Kafka identity. A connector can override the
internal clients' configuration — including credentials — unless
`connector.client.config.override.policy` restricts it (see Authorization
below).
+- **In distributed mode, Connect stores its state in Kafka topics.** Connector
configurations (including any inlined secrets), source offsets, and status live
in the `config.storage.topic`, `offset.storage.topic`, and
`status.storage.topic`; protect them with ACLs as you would any sensitive
topic. In standalone mode, offsets are kept in a local file
(`offset.storage.file.filename`) instead, so its protection is the host
filesystem's responsibility.
+
+## The REST API and the Network Boundary
+
+The REST API is configured with the `listeners` property (for example
`http://host:port` or `https://host:port`); if unset it defaults to `http` on
port 8083. In distributed mode the REST API is *also* the inter-worker
transport — a request received by a follower is forwarded to the leader — so it
is simultaneously a user-facing management interface and an internal control
channel. `rest.advertised.host.name`, `rest.advertised.port`, and
`rest.advertised.listener` control the URL other w [...]
+
+Operators should:
+
+1. Never expose the REST API to untrusted networks or users; bind it to a
management network or front it with a reverse proxy.
+2. Use `admin.listeners` to separate the admin endpoints from the regular
listeners, or set it to empty to disable them where they are not needed. If
`admin.listeners` is not set, the `/admin` endpoints are attached to the
default listeners.
+3. Prefer an `https` listener so that both user traffic and inter-worker
forwarding are encrypted.
+
+## Authentication
+
+Connect enables no authentication on the REST API by default. There are two
common ways to add it:
+
+- **Reverse proxy.** Terminate authentication (mTLS, OIDC, basic auth, etc.)
in a proxy in front of the workers and allow only the proxy to reach the REST
port.
+- **REST extension.** Register an authentication extension via
`rest.extension.classes`. The built-in `BasicAuthSecurityRestExtension`
performs JAAS-based HTTP basic authentication against a configured
`LoginModule`. The reference `PropertyFileLoginModule` is **not** intended for
production, as it stores credentials in cleartext; production deployments
should configure a `LoginModule` that authenticates against a real credential
store.
+
+REST authentication only establishes *who is calling*; it does not, on its
own, authorize that caller on a per-connector basis (see Authorization below).
Separately, the worker's authentication *to the Kafka brokers* uses the
standard `ssl.*`/`sasl.*` client configs described in the [core
model](security-model).
+
+## Authorization
+
+This is the weakest part of Connect's security posture, and operators must
plan around it:
+
+- **No per-connector authorization on the REST API.** Once a caller is allowed
onto the REST API it can act on *any* connector — reading another connector's
configuration and stopping or deleting it. Authentication extensions gate
access to the API as a whole, not to individual connectors.
+- **Client config overrides are enabled by default.**
`connector.client.config.override.policy` defaults to `All`, so a connector
configuration can override the worker's internal Kafka client settings. Since
4.2.0 it is recommended to set this to `Allowlist` (which becomes the default
in 5.0) and permit only the keys you actually need. Overrides that load classes
— such as `sasl.jaas.config` and `sasl.login.class` — are by design a
code-execution vector, so only allow them when only trus [...]
+- **One principal for all connectors.** Because the worker authenticates to
Kafka as a single principal, ACLs cannot distinguish one connector from
another. Partition that principal's ACLs by topic prefix per connector and
grant it only the access its connectors require.
+
+The practical consequences are that you cannot grant Connect REST API access
to anyone you would not trust as a cluster administrator, and if multiple
distrusting users or teams need Connect you should give each its own Connect
cluster rather than sharing one.
+
+## Encryption in Transit
+
+Two independent channels need TLS:
+
+- **Worker-to-Kafka.** Configured with the standard `ssl.*` client properties,
exactly as in the [core model](security-model).
+- **REST API (and inter-worker).** Enable an `https` listener. By default the
REST server reuses the worker's `ssl.*` settings; to configure the REST
endpoint independently of the Kafka client, use the `listeners.https.*`
prefixed properties (when the prefix is used, the unprefixed `ssl.*` settings
are ignored for the REST server). The same settings secure inter-worker
forwarding in distributed mode.
+
+## Secrets in Configuration
+
+Connector configurations frequently contain credentials for external systems.
As in the [core model](security-model), reference them indirectly through a
`ConfigProvider` rather than inlining them, and set `allowed.paths` on the
file-based providers to constrain which directories they can read. Two
Connect-specific caveats:
+
+- **Config providers are resolved through the shared REST API.** A caller who
can guess or enumerate a provider alias can resolve its full value, so a
provider is only as isolated as the REST API in front of it.
+- **What goes in the config topic depends on how secrets are supplied.** A
secret placed directly in a connector configuration is written to
`config.storage.topic` as an ordinary Kafka record, and is therefore only as
protected as that topic's ACLs and the brokers' at-rest story. A
`ConfigProvider` reference keeps the secret itself out of the topic — only the
template string (`${alias:fields}`) is stored, not the resolved value. Note,
however, that this does not hide the secret from REST [...]
+
+## Plugins
+
+Connect loads connectors, converters, single-message transforms, predicates,
`ConfigProvider`s, and REST extensions from `plugin.path`. All of them run in
the worker JVM with its full privileges, so installing a plugin is equivalent
to granting it arbitrary code execution on the worker. Install only plugins
from sources you trust, and treat the ability to influence which plugins load —
or to set class-loading connector configs — as administrator-level access.
+
+## Known Non-Findings
+
+In line with the [core model's classification](security-model), the following
follow from Connect's design and are not, on their own, security
vulnerabilities:
+
+- **File-based connectors granting disk access.** Adding the file connectors
to a worker effectively grants read/write access to the worker's local disk.
This is the connector's intended function, not a flaw.
+- **Local-disk-only weaknesses in the file-based config providers.** Issues
that require an attacker to already have local disk access on a Connect worker
— for example the ability to create arbitrary files or symlinks — are not
security issues, because such access is outside Connect's trust boundary.
Path-validation robustness in these providers may still be hardened
independently.
+- **`PropertyFileLoginModule` storing cleartext credentials.** The reference
`PropertyFileLoginModule` shipped with the basic auth extension is documented
as test-only; production deployments are expected to supply a real
`LoginModule`. Its cleartext storage is therefore expected behaviour rather
than a defect.
diff --git a/docs/security/security-model-streams.md
b/docs/security/security-model-streams.md
new file mode 100644
index 00000000000..8508ce5c9a1
--- /dev/null
+++ b/docs/security/security-model-streams.md
@@ -0,0 +1,42 @@
+---
+title: Kafka Streams Security Model
+description: Apache Kafka Streams Security Model
+weight: 10
+tags: ['kafka', 'docs', 'security']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+This page extends the [Apache Kafka security model](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.
+
+## Things You Need To Know
+
+- **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.
+
+## Known Non-Findings
+
+In line with the [core model's classification](security-model), 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.
diff --git a/docs/security/security-model.md b/docs/security/security-model.md
new file mode 100644
index 00000000000..b7f96add11a
--- /dev/null
+++ b/docs/security/security-model.md
@@ -0,0 +1,169 @@
+---
+title: Security Model
+description: Apache Kafka Security Model
+weight: 8
+tags: ['kafka', 'docs', 'security']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+## Things You Need To Know
+
+- **Security is off by default.** A freshly-installed Apache Kafka cluster
accepts unauthenticated `PLAINTEXT` connections on every listener and applies
no authorization. This is appropriate only for closed test environments.
Production deployments **must** explicitly configure authentication,
authorization, and transport encryption before being exposed to any untrusted
network.
+- **Apache Kafka assumes a trusted operator.** Anyone with shell access to a
broker, controller, or the underlying disks can read every topic, forge any
principal, and rewrite ACLs. The security model protects messages in transit
and arbitrates client access — it does not defend brokers from their own
administrators.
+- **Apache Kafka assumes a trusted broker fleet.** Brokers and KRaft
controllers exchange records, replication state, and metadata over the
inter-broker and controller listeners. Any host that can authenticate on those
listeners is effectively part of the cluster's trust boundary.
+- **Apache Kafka trusts its JVM and classpath.** JARs on a process's classpath
run with that process's full privileges. Placing code on the classpath — or
configuring a component to load it — is equivalent to trusting that code; the
model assumes no hostile JARs are present.
+- **Pluggable interfaces grant code execution.** Every Apache Kafka component
exposes pluggable interfaces (authorizers, (de)serializers, connectors,
transforms, config providers, and similar) that are loaded by class name and
run with the host process's privileges. Configuring one is equivalent to
running its code, so only install and use plugins that you fully trust.
+- **The data plane and the control plane have different exposure.**
Producer/consumer traffic, the Admin API, and JMX each have distinct
authentication and authorization stories. Operators must configure them
independently — securing one does not secure the others.
+- **Apache Kafka does not encrypt data at rest.** Log segments, index files,
and snapshots are written as plain bytes. At-rest confidentiality is the
responsibility of the underlying filesystem, block device, or message-level
encryption performed by producers.
+- **Reporting vulnerabilities.** Suspected security issues should be reported
privately to `[email protected]` per the [ASF security
process](https://www.apache.org/security/). Do not file public JIRA tickets,
GitHub issues, or mailing-list posts for unpatched vulnerabilities.
+
+## Listeners and the Network Boundary
+
+Apache Kafka brokers expose one or more **listeners**, each with an
independent security configuration selected by
`listener.security.protocol.map`. The four protocols are:
+
+| Protocol | Authentication | Encryption |
+|------------------|------------------------|------------|
+| `PLAINTEXT` | None | None |
+| `SSL` | Optional mTLS | TLS |
+| `SASL_PLAINTEXT` | SASL | None |
+| `SASL_SSL` | SASL (+ optional mTLS) | TLS |
+
+`inter.broker.listener.name` and `controller.listener.names` select which
listeners carry replication and KRaft traffic respectively. A common pattern is
to keep these on a dedicated internal listener (`SASL_SSL` or `SSL`) that is
firewalled off from clients, so that a compromise of a client-facing listener
cannot impersonate a broker.
+
+Operators should:
+
+1. Bind external listeners only to interfaces reachable by intended clients.
+2. Treat `advertised.listeners` as part of the security configuration —
clients connect to whatever the broker advertises after the initial metadata
fetch.
+3. Never expose the controller listener to client networks.
+
+## Authentication
+
+Apache Kafka supports two complementary authentication mechanisms; either may
be used, and both can be combined on a `SASL_SSL` listener.
+
+### TLS Client Authentication (mTLS)
+
+When `ssl.client.auth` is `required` on a TLS listener, the client's X.509
certificate is verified against the broker's truststore. The authenticated
principal is derived from the certificate's distinguished name via
`ssl.principal.mapping.rules` (or a custom `KafkaPrincipalBuilder`).
+
+mTLS is the recommended mechanism for broker-to-broker and
controller-to-broker traffic, because it requires no shared password material
and rotates with the rest of the PKI.
+
+### SASL
+
+Apache Kafka ships with five SASL mechanisms, enabled per-listener via
`sasl.enabled.mechanisms`:
+
+- **`GSSAPI`** — Kerberos. Recommended for environments that already operate a
KDC; principals and credentials are managed externally.
+- **`SCRAM-SHA-256` / `SCRAM-SHA-512`** — Salted challenge/response with
credentials stored in the cluster metadata. Credentials are managed with
`kafka-configs.sh --alter --add-config 'SCRAM-SHA-512=...'`.
+- **`OAUTHBEARER`** — OAuth 2.0 bearer tokens, suitable for integration with
an identity provider. The default unsecured implementation is for testing only;
production deployments must configure a JWKS endpoint and validator.
+- **`PLAIN`** — Username/password sent in cleartext over the SASL channel.
Acceptable only inside a `SASL_SSL` listener; never use it with
`SASL_PLAINTEXT`.
+
+#### Delegation Tokens
+
+Once a client has authenticated via SASL or mTLS, it can request a short-lived
**delegation token** that is then used as a `SCRAM-SHA-256` credential for
subsequent connections. Delegation tokens are intended for distributed
frameworks (Spark, Flink, Connect workers) that need to fan out to many tasks
without distributing the original credential. Tokens inherit the requester's
principal and ACLs, expire on a fixed schedule
(`delegation.token.expiry.time.ms`), and can be invalidated by th [...]
+
+## Authorization
+
+Authentication establishes a `KafkaPrincipal`; authorization decides what that
principal may do. Authorization is performed by the configured
`authorizer.class.name`. Apache Kafka ships
`org.apache.kafka.metadata.authorizer.StandardAuthorizer` for KRaft clusters.
+
+ACLs are tuples of `(principal, host, operation, resource pattern,
permission)`. Resources are typed (`Topic`, `Group`, `Cluster`,
`TransactionalId`, `DelegationToken`, `User`) and patterns may be `LITERAL` or
`PREFIXED`.
+
+Defaults worth understanding:
+
+- If no authorizer is configured, **all authenticated principals have full
access**. Configuring authentication without an authorizer provides identity
but no authorization.
+- If an authorizer is configured but no ACLs match, access is **denied**. The
exception is the principals listed in `super.users`, which bypass ACL checks
entirely; treat that list as you would a root password.
+- `allow.everyone.if.no.acl.found=true` reverses the default-deny behaviour
for resources that have no ACLs at all. It is a transitional aid for adding
authorization to existing clusters and should not remain set in steady state.
+
+ACLs are managed with `kafka-acls.sh` or the AdminClient
`createAcls`/`deleteAcls` APIs, which are themselves gated by ACLs on the
`Cluster` resource.
+
+## Encryption in Transit
+
+TLS is configured per-listener via the standard `ssl.*` properties
(`ssl.keystore.*`, `ssl.truststore.*`, `ssl.protocol`, `ssl.cipher.suites`,
`ssl.enabled.protocols`). Recommendations:
+
+- Disable TLS versions below 1.2; prefer 1.3 where the JDK supports it.
+- Use distinct keystores for the inter-broker listener and any client-facing
listener so that a leaked client-facing key cannot impersonate a broker.
+- Set `ssl.endpoint.identification.algorithm=https` on clients (the default
since 2.0) so that the broker's certificate must match its hostname.
+- Rotate keystores using the dynamic broker configuration mechanism
(`kafka-configs.sh --entity-type brokers --alter --add-config ...`) to avoid
restarts.
+
+Kafka Connect, MirrorMaker 2, and Kafka Streams all consume the same `ssl.*`
and `sasl.*` client configs — securing the broker is necessary but not
sufficient.
+
+## Encryption at Rest
+
+Apache Kafka does not encrypt log segments, indexes, snapshots, or controller
metadata on disk. Operators who require at-rest confidentiality have three
options, in increasing order of cost:
+
+1. **Filesystem or block-device encryption** Transparent to Kafka; protects
against disk theft and misdirected backups but not against anyone with broker
login.
+2. **Message-level encryption.** Producers encrypt payloads (and optionally
headers) before `send()`; consumers decrypt. Keys are managed by an external
KMS. This is the only option that protects records from broker operators, but
it precludes broker-side features that read payloads (e.g. Streams aggregations
on the encrypted field).
+3. **Tiered storage** with a remote store that performs its own encryption.
+
+## Audit Logging
+
+Apache Kafka emits authorizer decisions to the `kafka.authorizer.logger` log4j
logger. Setting this logger to `INFO` records every denied request; `DEBUG`
records every allowed request as well. In regulated environments this log
should be shipped to durable, append-only storage off-broker. There is no
built-in tamper-evident audit trail.
+
+The request log (`kafka.request.logger`) provides finer detail on individual
API calls and is useful for forensic investigation, but it is verbose and not
enabled by default.
+
+## Secrets in Configuration
+
+Broker, client, and Connect properties files contain keystore passwords, SASL
credentials, and similar secrets. Apache Kafka supports indirect references
through `ConfigProvider` implementations (`FileConfigProvider`,
`DirectoryConfigProvider`, or custom providers). Use them rather than embedding
cleartext secrets in version-controlled configuration. For the file-based
providers, set `allowed.paths` to the specific directories that hold those
secrets so that a malicious or mistaken confi [...]
+
+## Component-Specific Notes
+
+- **JMX.** Kafka processes, such as brokers, clients, Connect and Streams,
expose operational metrics over JMX. JMX is an administrators/operators-only
interface and must never be exposed to actual users. It is unauthenticated by
default and should either be disabled, bound to localhost with an exporter
alongside, or configured with `com.sun.management.jmxremote.authenticate=true`
and TLS.
+
+The components built on top of the Kafka clients have their own security
models, covered on separate pages:
+
+- [Kafka Connect](security-model-connect)
+- [Kafka Streams](security-model-streams)
+
+## Development and Test Tooling
+
+Not everything shipped in the Apache Kafka source tree is part of the
production attack surface. Some components exist only to develop, test, and
release Kafka itself, and are explicitly out of scope for the security model —
they are expected to run only in trusted development and CI environments, and
issues in them are generally not treated as security vulnerabilities.
+
+- **Trogdor.** Trogdor is a test framework that injects faults and runs
workloads by design, including arbitrary user-supplied commands. It is intended
to run only in development environments; the project does not consider command
execution through Trogdor a security issue.
+- **System tests and release tooling.** The `tests/` system-test harness and
the scripts under `release/` are operator/developer tooling for building,
testing, and publishing Kafka. They are not components of a running cluster.
+
+When assessing the attack surface of a deployed cluster, scope it to the
brokers, KRaft controllers, the client and inter-broker/controller listeners,
the Admin API, and JMX — not the development tooling above.
+
+## Supported Versions and Artifacts
+
+Only the currently supported releases and `trunk` are in scope for security
reports; issues that reproduce only on an end-of-life release should be
reproduced against a supported version first.
+
+The published Docker images are a special case. They are free of known CVEs on
their release day, but the project does not rebuild already-released images, so
over time their base layers and bundled dependencies accumulate CVEs that are
not specific to Apache Kafka. Those accumulated CVEs are therefore out of
scope; operators are expected to rebuild or patch images for long-running
deployments.
+
+## Classifying Reports
+
+To keep triage consistent, a reported issue is treated as exactly one of:
+
+- **A vulnerability** — it breaks one of the security properties above for an
adversary that is in scope, such as an unauthenticated or unauthorized network
client.
+- **A hardening suggestion** — no stated property is broken, but a safer
default or an added guard would reduce the blast radius of misuse.
+- **Out of scope** — it requires capabilities the model already treats as
trusted (operator-supplied configuration, keystores, ACL administration), an
adversary the model does not cover (a trusted operator, peer broker, or
controller), or an unsupported component (see Development and Test Tooling
above).
+- **By design** — it concerns a property the model explicitly disclaims, such
as at-rest confidentiality or isolation from a trusted operator.
+
+## Known Non-Findings
+
+The following follow directly from the model above and are not, on their own,
security vulnerabilities:
+
+- **Unauthenticated or unencrypted access to a default cluster.** Security is
off by default; an open `PLAINTEXT` listener with no authorizer is a deployment
choice, not a defect.
+- **A trusted principal performing an authorized operation.** Admin and
inter-broker actions by a principal that holds the relevant ACLs — or by a
`super.users` entry — are expected behaviour.
+- **Findings in development and test tooling.** Issues in `tools`, `bin`,
Trogdor, `tests`, and similar are out of scope (see Development and Test
Tooling above).
+- **Kafka Streams application-level issues.** Streams runs inside the user's
application, so its security boundary is the application's, not the broker's
(see the [Kafka Streams security model](security-model-streams)).
+
+## Reporting Security Issues
+
+Suspected vulnerabilities should be sent to `[email protected]`.
Please do not disclose the issue publicly until the PMC has had time to
investigate, prepare a fix, and coordinate a release. The current list of
disclosed CVEs and affected version ranges is published at
[kafka.apache.org/cve-list](https://kafka.apache.org/cve-list).
