Add a draft security threat model + discoverability files (THREAT_MODEL.md, SECURITY.md, AGENTS.md)

[potiuk]

This is a proposal for the Solr PMC to review — please correct, reject, or discuss as needed. The maintainers are the decision-makers; nothing here is a requirement.

This adds a v0 draft threat model (THREAT_MODEL.md) for the Solr Operator plus the conventional AGENTS.md → SECURITY.md → THREAT_MODEL.md discoverability chain, so an automated agentic security scanner can mechanically find the project's security model.

Context. The ASF Security team is preparing Apache Solr's repositories for an automated agentic security scan. Discoverability (the scanner being able to follow AGENTS.md → SECURITY.md → model) is the one hard gate — without it a scan can't run. The Solr search server (apache/solr) already has its model merged; this PR is the equivalent for the operator, whose attack surface is entirely different (a privileged Kubernetes controller, not a search engine). The model cross-references apache/solr's THREAT_MODEL.md for everything on the managed-Solr side.

This is a v0 draft — mostly *(inferred)*. The Security team drafted it from the repo's own public artefacts (CRD types, the operator ClusterRole, main.go flag defaults, the Helm values, the auth/TLS docs) using the threat-model-producer rubric. Every claim carries a provenance tag; every *(inferred)* tag routes to a matching question in §14 Open questions. The fastest way to review is to react to §14 (a one-line confirm / correct / strike per question) rather than compose from scratch — we then fold your answers in and the tags become *(maintainer)*.

A few concrete things the draft flags for your confirmation (all §14): the all-namespaces watch + cluster-wide ClusterRole default; tls-skip-verify-server=true (operator→Solr cert verification off by default); the bootstrap security.json passwords being generated with math/rand rather than crypto/rand; and the confused-deputy surface where a namespace tenant's CR fields drive the privileged operator. These are proposed dispositions, not assertions — your call.

Scope note: the Solr Operator was one of the repos flagged for scope confirmation in the scan enrollment. If the PMC would rather not include the operator in this cycle, just close the PR and we'll drop it — no problem. If you'd rather own the model yourselves, close it and we'll wait.

Questions / pushback welcome. Happy to adjust structure, file placement, or wording to match project house style.

[HoustonPutman]

Ok these are the comments I have. Not sure exactly what I'm supposed to do from here. Do I make the changes then merge? Including saying that it was reviewed by me (I see a section mentioning no review has been done)

[potiuk]

Thanks, Houston — this is exactly the maintainer input the draft needed, and all five are clear corrections. I've folded them into the PR:

• SECURITY.md → contact is now security@solr.apache.org.
• THREAT_MODEL.md → notes the operator can be installed namespace-scoped (not only cluster-wide); the ClusterRole / Role distinction is fixed at both call-sites (Role when watching specific namespaces); and your out-of-scope item — pass-through Kubernetes options copied verbatim onto the dependent StatefulSet/Service/Pod/etc. — is added to §3.

On the "no review has been done" note: that's a provenance marker — draft claims start tagged *(inferred)* until a maintainer confirms them. Your review is exactly that confirmation, so I've flipped the claims you reviewed to *(maintainer)* and credited your 2026-07-15 review in the status line + provenance legend.

So from here it's yours: a final look and merge whenever you're happy — that's the one thing that gets the Operator discoverable for the scan. You don't need to make any further edits unless you spot something else. Thanks again — the namespace-scoped and RBAC corrections especially are the kind of thing only a maintainer would catch.