Problem
Cluster and client traffic currently assumes a trusted network. Connections do not authenticate the remote party, encrypt traffic, or authorize administrative and data operations.
Any party that can reach exposed ports may impersonate a node, observe or modify traffic, create or delete topics, publish records, consume data, or disrupt consensus and replication.
A 1.0 release must either implement a production security boundary or explicitly restrict deployment to an isolated trusted network. Documentation alone does not protect deployments that expose these listeners unintentionally.
Scope
Address the boundaries independently:
- Client identity and encrypted client-to-broker sessions.
- Mutual node identity for membership, consensus, replication, and repair traffic.
- Authorization for administrative operations and topic-level produce and consume access.
- Credential provisioning, rotation, revocation, and expiry.
- Safe bootstrap and node-join authentication.
- Audit events for authentication and authorization failures.
Acceptance criteria
- Every externally reachable stream is encrypted in transit when security is enabled.
- Cluster nodes mutually authenticate before accepting control-plane or data-plane messages.
- A node identity is bound to its configured cluster membership identity.
- Client requests are associated with an authenticated principal.
- Administrative, produce, and consume operations enforce configurable authorization.
- Credentials can rotate without taking the entire cluster offline.
- Failed authentication cannot consume unbounded connection or parsing resources.
- Secure defaults and the trusted-network-only development mode are clearly separated.
- Operational documentation covers bootstrap, rotation, recovery, and certificate or credential expiry.
Validation
- Attempt node impersonation, client impersonation, unauthorized operations, replay, and downgrade.
- Rotate credentials during active production and replication traffic.
- Test expired and revoked identities and mixed secure/insecure configuration.
- Fuzz unauthenticated handshakes and enforce resource limits.
- Verify failure diagnostics do not disclose sensitive credential material.
Problem
Cluster and client traffic currently assumes a trusted network. Connections do not authenticate the remote party, encrypt traffic, or authorize administrative and data operations.
Any party that can reach exposed ports may impersonate a node, observe or modify traffic, create or delete topics, publish records, consume data, or disrupt consensus and replication.
A 1.0 release must either implement a production security boundary or explicitly restrict deployment to an isolated trusted network. Documentation alone does not protect deployments that expose these listeners unintentionally.
Scope
Address the boundaries independently:
Acceptance criteria
Validation