Add draft project security threat-model document

[potiuk]

Summary

This PR adds an initial draft of a project-level security
threat-model document (draft-THREAT-MODEL.md) so that automated
security scanners running against this repository have a
maintainer-facing reference for which classes of findings are
in-scope vs. out-of-scope for the project.

The document follows the rubric format used by several other ASF
projects piloting improved security-model discoverability for
agentic scanners. Every claim carries a provenance tag:

• (documented) — paraphrased from public artefacts (this repo or
  the project website), cited inline.
• (inferred) — synthesised from code structure or domain
  knowledge; the PMC has not confirmed.
• (maintainer) — confirmed by a CloudStack PMC member in response
  to this draft. (Zero in this initial draft.)

Draft stats:

• ~88 documented claims
• ~64 inferred claims (each maps to a §14 question)
• 38 open questions for maintainers in §14

§14 is the highest-leverage section: answering each question
either promotes one (inferred) tag to (maintainer) or corrects
the underlying claim.

Why "draft-" prefix?

The file is named draft-THREAT-MODEL.md rather than
SECURITY-THREAT-MODEL.md because this is a proposal for the
PMC to review — please correct, reject, or discuss as needed.
Once the PMC ratifies (or substantially edits) the content, the
file can be renamed in a follow-up PR and a discoverability
scaffold (AGENTS.md → SECURITY.md → the model) added so
scanners can mechanically follow the chain.

What this is, and what it is not

This is not a security audit. It is a working triage document
— the reference a triager holds against an inbound report to
decide whether the report is about a CloudStack vulnerability or
about caller misuse / operator misconfiguration / an out-of-scope
concern.

The draft was generated by an automated agentic security scan
being piloted by the ASF Security team; the discoverability work
is independent of any specific scan run.

How to review

1. §14 first. Each answer either confirms one (inferred) tag or
   replaces the inferred claim with the correct one.
2. After that, please skim §3 (out-of-scope) and §13 (triage
   dispositions) — those govern how a vulnerability report would
   be triaged.

Reply edits / corrections inline on the PR, or to the original
security@apache.org thread, whichever fits the PMC's workflow.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 18.76%. Comparing base (7308dad) to head (abd9ab6).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #13293      +/-   ##
============================================
+ Coverage     18.10%   18.76%   +0.65%     
- Complexity    16752    17984    +1232     
============================================
  Files          6037     6164     +127     
  Lines        542796   552900   +10104     
  Branches      66456    67385     +929     
============================================
+ Hits          98291   103766    +5475     
- Misses       433460   437723    +4263     
- Partials      11045    11411     +366     

Flag	Coverage Δ
uitests	3.53% <ø> (+0.01%)	⬆️
unittests	19.96% <ø> (+0.68%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[yadvr]

There's a lot of details in the draft that needs a better set of eyes, so assigning @DaanHoogland @vishesh92 who're also PMC leads on the work.

[potiuk]

Thanks @DaanHoogland @yadvr @vishesh92 — agreed, let's make this (apache/cloudstack) the canonical project-level threat model and have the client/tooling repos inherit from it rather than each carrying a full copy.

Concretely, mirroring what we've done for other multi-repo PMCs:

• apache/cloudstack/THREAT_MODEL.md is the single source of truth for the project-wide model: scope, trust boundaries, the management-server adversary model, in/out-of-scope classes, known non-findings, and triage dispositions.
• The satellite repos (cloudstack-go, -cloudmonkey, -terraform-provider, -kubernetes-provider) get a short discoverability pointer — AGENTS.md → SECURITY.md → this model — plus, only where it adds something, a thin repo-specific addendum (e.g. the Go SDK's own input-trust surface) that references the parent instead of duplicating it.

So let's converge here first. None of the satellite PRs are merged, so re-pointing them to reference this model once its shape is settled is cheap — I'll repurpose those into pointer PRs (or close + reopen) once you're happy with the parent.

On "the fields we need": that's exactly the §14 "Open questions" section — each is a proposed answer for you to confirm, correct, or strike, grouped into waves so you can take a few at a time. Drop answers inline or here and I'll fold them in and promote the provenance tags. Happy to adjust the section set if CloudStack's shape calls for it.

[potiuk]

Friendly ping — @DaanHoogland @vishesh92, whenever you have bandwidth for a read. No rush; happy to walk through any of the §14 open questions or adjust scope/wording.

[DaanHoogland]

Friendly ping — @DaanHoogland @vishesh92, whenever you have bandwidth for a read. No rush; happy to walk through any of the §14 open questions or adjust scope/wording.

@potiuk , is this in response to my Thursday comments? I think I answered most of the questions. Some questions for clarification posed, though. It seems we are almost there.

[potiuk]

@DaanHoogland — yes, sorry, that ping crossed with your review already in flight; nothing was missed on your end. Thank you (and @vishesh92) for the thorough pass — you've answered the bulk of the §14 questions and confirmed the trust-boundary lines, which is exactly what pre-flight needs.

Next on our side: I'll fold your inline answers into an updated revision of the model —

• mark the §14 questions you confirmed as resolved, and drop the ones that were just "yes/confirmed" (e.g. the §856 question, per your note);
• wire the source-of-truth relationship you and @vishesh92 agreed on (1108/1113): THREAT_MODEL.md as the source of truth, with cloudstack.apache.org/security carrying an excerpt + link;
• add "a change in the extension mechanisms implemented by CloudStack" to the conditions-that-would-change-the-model section (1116);
• and capture the two items that are really process/test rather than model gaps: the dependency-update procedure (847 — dependabot not producing viable PRs) and the template download-token timed-availability mitigation (842), noting the latter needs a test to confirm. (On "why didn't code analysis flag it" — that one is a design/process question rather than a code defect, so it wouldn't surface in a static pass.)

Once that revision is up I think we're through pre-flight, as you say. I'll push it and re-request your review.

Best,
Jarek

[potiuk]

Thanks again @DaanHoogland and @vishesh92 — I've pushed a revision folding your review into the model.

What changed:

• Every question you confirmed is now marked RESOLVED in §14 with your answer — throttling (api.throttling.enabled false by default), integration port :8096 default 0, the explicit UI request-size cap (DEFAULT_REQUEST_CONTENT_SIZE = 1048576), the four-logical-network model, simulator/tools/appliance exclusion, data-at-rest delegation, info-leak in-model (regular logs exempt), TOCTOU/TLS/key-reuse confirmations, and the satellite-repo hierarchy (cloudstack-go a dep of the other three).
• §8 P9 no longer implies CloudStack is Java-only — it now states no implementation-language limitation is presumed (ocaml/python/bash on hypervisors, go on the management server), with the memory-safety claims scoped to the JVM components.
• §12 gains "a change in the extension mechanisms" as a revision trigger.

Answers to the three you asked me:

• Q15 (filesystem perms): no, not a CSV of every file — just the four sensitive artifacts (JCEKS keystore, Root CA private key, JaSypt key + IV, db.properties), each with its owning UID + mode. If you or @vishesh92 can drop those owner/mode values, I'll fill them in.
• Q25 ("branch"): that's the branch-predictor / speculative-execution side channel (Spectre-class); I've spelled it out in the doc. Agreed it's out of scope.
• Q30 (constant-time): thanks — recorded as a lack of feature / hardening opportunity (login-password, session-cookie, console-token compares), not a by-design decision.

Still open for @vishesh92 to confirm: Q24 (the same-IP host refusal — does it also include a UID check?) and Q29 (data-at-rest fully delegated to storage/hypervisor). Disposition on Q24 is unchanged pending that.

Re-review whenever convenient — once these settle, pre-flight is complete and we queue CloudStack.

[vishesh92]

@DaanHoogland the PR for this is still pending #13182
Currently when a host with the same IP is added again, we update the details for the existing host. But I don't think should be an issue since only a root admin/operator with access to the host credentials can do this.
I think adding a host directly with a configuration with fail due to missing key/certs required for connecting to the management server.

[vishesh92]

this is correct. delegated to storage layer / hypervisor.

[vishesh92]

The ownership of these files is the root user and the group is cloud. The permissions are read & write for root and read for cloud group.