potiuk opened a new pull request, #22431: URL: https://github.com/apache/kafka/pull/22431
**This is a draft proposal for the Kafka PMC to review — please correct, reject, or discuss as needed.** Nothing here is a requirement; the maintainers are the decision-makers, and this describes Kafka *as the PMC says it is*. This PR adds `THREAT_MODEL.md` + `SECURITY.md` + `AGENTS.md`, wiring `AGENTS.md -> SECURITY.md -> THREAT_MODEL.md`. Framing: Kafka is a *configurable platform* — it provides mechanisms (SASL/mTLS auth, an ACL authorizer, TLS, quotas) and the **operator chooses** which listeners use them; a broker can run wide open (PLAINTEXT, no authorizer) or fully locked down. The **untrusted network client** is the adversary; the operator and trusted cluster peers / metadata quorum are out of model. Draft-first, mostly inferred (~16 documented / 0 maintainer / ~58 inferred); every `*(inferred)*` claim routes to a numbered **§14** question. The **wave-1** rulings decide `VALID`-vs-misconfiguration: - Is running the **default PLAINTEXT listener with no authorizer** a *supported* posture (network-trust), so an "unauthenticated broker" report against defaults is by-design — or should it be `VALID`? - Under StandardAuthorizer, is the default `allow.everyone.if.no.acl.found` "no ACL ⇒ deny"? - Does the **Connect REST API** require authentication by default, and how should connector-config URL handling (SSRF) be treated? Scope note: this covers the broker + Connect; Kafka Streams is treated as a client library (in-app trust), and tools/shell/trogdor/tests are out of the runtime model. Context: the ASF Security team is preparing the project for an automated agentic security scan we're piloting. Drafted via the [threat-model-producer](https://gist.github.com/potiuk/da14a826283038ddfe38cc9fe6310573) rubric. If you'd rather author it yourselves, close this PR and we'll regroup. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
