Add Aspire-native Chaos integration design

[Brent Rusinow (brrusino)]

Description

Adds the design specification for an Aspire-native, runtime-controlled Chaos integration backed by the existing proxy layer.

The design keeps Chaos out of AppHost source and publish output. Applying a policy through the CLI, Dashboard/MCP, or Aspire.Hosting.Testing is the explicit Run-mode consent boundary. It defines:

• typed, inferred fault profiles and policy payloads;
• resource and caller scoping through the Aspire application model;
• stable proxy routing, lifecycle, telemetry, and failure behavior;
• CLI, Dashboard, MCP, and testing experiences; and
• the MVP support matrix for http/v1, cosmos-gateway/v1, storage/v1, and app-configuration/v1.

The MVP requires identical profile schemas, fault semantics, and eligibility behavior whether an upstream is emulated or deployed to Azure. A location-specific failure blocks MVP release rather than producing an emulator-only subset.

Validation included Markdown structure and table checks, repository citation validation, contradiction searches, git diff --check, and independent architecture reviews.

Security considerations

This is a design-only change and does not open listeners or alter runtime behavior. The proposed implementation would terminate local TLS and mediate requests that can contain production-capable bearer tokens, SAS values, SharedKey authorization, certificates, and decrypted content. The specification requires explicit real-resource consent, validated trust on both proxy legs, process isolation, no credential/header/body logging, bounded plaintext lifetime, and loud rejection when those guarantees cannot be met. The implementation will require threat modeling and security review.

Fixes # (issue)

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[Copilot]

Copilot wasn't able to review any files in this pull request.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19160

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19160"

[Adam Ratzman (adamint)]

I think the Azure profiles need another design pass before this can be implemented: the startup, consent, routing, and authentication assumptions currently conflict. I left the concrete blockers inline.

[Copilot]

Copilot wasn't able to review any files in this pull request.

[Brent Rusinow (brrusino)]

Addressed all eight findings in f22745e0d. The spec now uses post-start acknowledged apply, existing-command consent, caller-network-aware routing with preserved authority, enforceable Cosmos capture, CLI-side JSON preprocessing, typed leases, and one shared rate-limit counter per policy. Publish stays chaos-free, and no AppHost/source opt-in was added.

[Copilot]

Copilot wasn't able to review any files in this pull request.

[Brent Rusinow (brrusino)]

Follow-up from the proxyless endpoint discussion: 6ca9d2b49 makes effective proxyless paths explicitly runtime-ineligible for Chaos in MVP. The spec preserves normal direct endpoint/reference behavior, never silently converts or mediates a proxyless path, and keeps this as a path-eligibility rule rather than demoting any of the four required MVP profiles. Future caller-scoped support remains possible but isn't promised here.

[Brent Rusinow (brrusino)]

Adam Ratzman (@adamint) I think your summary comment went out with the same batch as the inline ones, so it probably predates the revisions. I took a pass at all eight in f22745e0d (plus 6ca9d2b49 for the proxyless exclusion) — startup is now pass-through at start with listeners established pre-start and policy applied live after, original authority is preserved with localhost rewriting called out as ineligible, and container callers get a network-reachable address rather than loopback.

Two I don't want to represent as fixed, since they're positions I took rather than problems I solved:

Cosmos enforceability — the spec asks that no outbound Cosmos path exist outside the mediated Gateway listener and treats that as a gate, but it doesn't say how we'd get there. I left it as a stated obligation instead of claiming DCP can detect a bypassing client, since it can't. If that's not the right way to carry an open question in a spec here, happy to change it.

MCP consent — I framed the boundary as "an actor authorized to invoke existing resource commands may invoke this mutating command" and explicitly disclaimed per-principal auth. CLI add-policy has a confirmation gate, MCP doesn't. That felt like the honest read, but it's your call whether it's acceptable.

No rush on my end, and I'm not assuming this is ready — mostly want to know whether the shape is right before anyone spends more time on it. Also still finding my footing in this repo, so if I've got conventions wrong anywhere, tell me and I'll fix it.