My opinion is that a "PLAINTEXT listener and no authorizer" is valid only for development.

The default is DENY (source: https://github.com/apache/kafka/blob/trunk/metadata/src/main/java/org/apache/kafka/metadata/authorizer/StandardAuthorizer.java#L210-L214)

Idempotent producers and transactions are gated by ACLs (source: https://kafka.apache.org/43/security/authorization-and-acls/#operations-and-resources-on-protocols)

Delegation tokens are a mix of both ACLs and additional checks specifically for tokens i.e. something authenticated with a token cannot create another token. For the purposes of this the answer is yes.

SCRAM/GSSAPI/OAUTHBEARER are recommended.

As far as I am aware nothing enforces TLS for PLAIN (sources: https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/auth/SecurityProtocol.java#L28, https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/auth/SecurityProtocol.java#L32). Everything over PLAINTEXT should be development-only.

For OAUTHBEARER we support client_credentials and client_assertion (source: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1258%3A+Add+Support+for+OAuth+Client+Assertion+to+client_credentials+Grant+Type)

Let's trust cluster peers and KRaft quorum for now. Let's remove references to Apache ZooKeeper. Technically versions 3.9.x still have ZooKeeper, but it isn't on trunk.

@mimaison maybe you know some examples? Or @showuon?

Ideally the THREAT_MODEL.md makes it in as a new page under docs/security, but I am happy to move it as a subsequent step if that formatting will somehow break things. I think it is fair to treat Streams as client library for now (@mjsax maybe you can weigh in here?). Given that we expose REST APIs from Connect I have a feeling we need to go in a bit more depth (@mimaison thoughts?).

@mimaison you may be the best-suited person to answer this question? If not maybe you know who might be?

The configurations which protect against a DoS and their default values are:
socket.request.max.bytes at 100 MiB
queued.max.requests at 500
connection.failed.authentication.delay.ms at 100 ms

We further have the following unset by default ones:
queued.max.request.bytes
max.connections{.per.ip}
max.connection.creation.rate

By default quotas are unset. They can be set on a produce/consume level, on a generic request level, or on the number of mutations processable by the controller.

What is addendum C?

What is the reason that an idempotent producer is grouped with the replication internals? Is the idea here that Kafka has some internal state (i.e. for idempotent producer or for replication) which lives on brokers and is not exposed?

I don't know whether you need an exhaustive list or just an list of examples, but let's also exclude committer-tools

And bin. bin contains the .sh files which we use to start a broker, for example, but if we are assuming that this is out of scope due to it being a responsibility of the operator I don't think we need to look into it either

No, I don't remember there's any in-cluster-peer threats. I think it's safe we trust it.

Do we require the SECURITY.md and THREAD_MODEL.md files? I'd rather have these sections in our documentation directly, also in markdown in the repository. That way it would available on the website and to end users.

I'm a bit confused by the sentences after
Agents that scan this repository should consult SECURITY.mdand the linkedTHREAT_MODEL.md before reporting issues..

Is it trying to be a TLDR of the other files?

The adversary is an **untrusted network client** of a broker (or the Connect REST API);

I'm not sure I understand that sentence.

I agree that the adversary is a client, as in an attack cannot depend on a rogue administrator. Clients only access Kafka components via the network, via Kafka RPCs to brokers and controllers, and HTTP/REST to Connect workers. An attack cannot rely on local access to the brokers, controllers, and Connect workers hosts.

However, I think, an adversary could be a trusted client that breaches its boundaries. For example a client has READ access but manages to perform a WRITE (privilege escalation). I guess it depends what you meant exactly by untrusted.

tools is pretty much the same as Clients library. These are just clients setup to perform specific tasks

What do we mean by parses broker responses? Is that responses from the brokers could be malicious and that clients must handle them gracefully?

Do we really need tho state that if you're allowed to perform an action, being able to perform it is not an issue? Or are we trying to say something else and I don't understand?

I have no idea what this is referring to?

I think it's out of scope, brokers and controllers are assumed to be trusted. If a user manages to make a malicious broker/controller join the cluster they must have already breached a number of other security measures.

As said in https://github.com/apache/kafka/pull/22431/changes#r3356434930, Connect is in a pretty poor state if we don't consider it a client side application.

Regardless we should separate it from the brokers/controllers as it works differently.

Known issues (not considered security issues) include:

• FileConfigProvider and DirectoryConfigProvider don't handle symlinks in their path allowlist validation logic. While we should fix this issue, I don't consider it a security issue as it requires local disk access and the ability to create arbitrary symlinks on Connect workers.
• https://issues.apache.org/jira/browse/KAFKA-20450: Over the years we got a lot of reports for this one. We tidied the code recently but it's not in a release yet. Again not a security issue as it requires disk write access on Connect workers for exploitation.
• Abuse of sasl.server.max.receive.size: The default value of 512kB could (should?) be reduced.
• Abuse of connections.max.idle.ms pre authentication: We same idle period is applied to both authed and unauthed connections. The config defaults to 10mins, it could be shorter pre-auth.