chore(security): add draft threat model and SECURITY.md for security-model discoverability

[potiuk]

This is a draft proposal for the Kvrocks PMC to review — please correct, reject, or discuss as needed. Nothing here is a requirement; the maintainers are the decision-makers, and this document describes Kvrocks as the PMC says it is.

This PR adds THREAT_MODEL.md + SECURITY.md and a Security section in AGENTS.md, so an automated scan agent can mechanically find the model via AGENTS.md → SECURITY.md → THREAT_MODEL.md.

It is draft-first and mostly inferred (~16 documented / 0 maintainer / ~50 inferred). Every *(inferred)* claim routes to a numbered question in §14 Open questions — the fastest review is to walk §14 (three short waves) and answer in-thread; we then promote the tags to *(maintainer)*.

The wave-1 rulings are load-bearing:

• Is running without requirepass (the default) a supported posture relying on bind/network controls, or must operators set it before exposing the port — i.e. is an unauthenticated-access report BY-DESIGN or VALID?
• Same for TLS-off on an untrusted network — operator responsibility or a claimed gap?
• Are replication / cluster peers trusted (out of the adversary model) or should a malicious peer be in scope?

apache/kvrocks-controller is in scope for the scan too; per §14 q10 it will get its own model (its trust surface — the cluster control plane — differs), which we'll open as a separate PR.

Context: the ASF Security team is preparing the project for an automated agentic security scan we're piloting; a complete, discoverable threat model keeps that scan's output signal-rich. We drafted this via the threat-model-producer rubric. If you'd rather author it yourselves, close this PR and we'll regroup.

[potiuk]

Thanks @PragmaTwice — pushed a revision folding your answers in: replica-cluster peers are trusted (out of model); strict per-namespace keyspace confinement with admin-only metadata; Lua confined to the namespace (no host access); no per-namespace encryption claimed; requirepass-unset / TLS-off documented as operator-must-restrict-access; no intrinsic DoS guarantee beyond configured limits; and AUTH constant-time compare as a VALID-HARDENING item. I also documented the pub/sub-doesn't-respect-namespaces known limitation explicitly (namespacing it = hardening). A few residual sub-items are left as §14 questions (pre-AUTH command semantics, whether non-admins can run EVAL/FUNCTION, AUTH throttling, a fuller non-findings list). WDYT?

[PragmaTwice]

Questions answered.

[potiuk]

Thanks @PragmaTwice — all your answers are folded in, and every §14 question is now resolved / *(maintainer)*:

• Auth gate (§8.3 / §6): commands refused pre-AUTH once a token is configured.
• Namespace isolation: strict keyspace confinement; pub/sub the only cross-namespace exception (§14.4).
• Lua scripting: namespace-confined, no host access (§14.5).
• Resource line + AUTH hardening: configured-limits contract; constant-time compare = VALID-HARDENING; throttling is operator responsibility (§14.7/§14.8).
• Data-at-rest: no per-namespace encryption claimed (§14.6).
• §11a: your list stands, no additions (§14.9).
• Scope: this model covers apache/kvrocks; kvrocks-controller keeps its own (#397) (§14.10).

I've replied on and resolved the open threads. The model is the PMC's to merge whenever — thanks for the thorough review.