potiuk opened a new pull request, #397: URL: https://github.com/apache/kvrocks-controller/pull/397
**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. This is the companion to the `apache/kvrocks` threat-model PR, covering the **control plane** (its trust surface differs from the data node). It adds `THREAT_MODEL.md` + `SECURITY.md` + `AGENTS.md` so a scan agent can follow `AGENTS.md → SECURITY.md → THREAT_MODEL.md`. Draft-first, mostly inferred (~12 documented / 0 maintainer / ~40 inferred); every `*(inferred)*` claim routes to a numbered **§14** question. The **wave-1** question is the whole ballgame for a control plane: - Does the controller API/UI have **any built-in authentication/authorization**, or is it **network-trust only** (the `config.yaml` shows no API-auth knob and default `addr` is `127.0.0.1:9379`)? If network-trust-only, is fronting it with an operator auth proxy the *supported* posture — so an "unauthenticated admin API" report is `BY-DESIGN` rather than `VALID`? Also flagged: TLS posture, SSRF via node registration, and how managed-node admin credentials are stored. Context: the ASF Security team is preparing the project for an automated agentic security scan we're piloting; a discoverable threat model keeps that scan's output signal-rich. 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]
