Aspire Local Vault Posture

Prefer optional local secret sources over mandatory local vaults

• Aspire parameters, .NET user-secrets, and environment variables are good low-friction local override paths.
• They are config-source patterns, not true vaults, but they often solve the actual developer need without new infrastructure.

Call out residual risk honestly

• A local vault still needs bootstrap credentials somewhere.
• Secrets may still pass through env vars, config, logs, or container state.
• Local workstation compromise still defeats any local-only vault.

Examples

• src/UmbracoPrism.AppHost/Program.cs currently keeps the local stack simple: Keycloak container + HTTPS proxy + TestSite/MockBusinessApp wiring, with no vault dependency.
• src/UmbracoPrism.TestSite/DemoTenantSeeder.cs seeds the repo-owned Keycloak demo tenant with prism-dev-secret.
• keycloak/realm-export.json contains the matching demo client secret, showing why a default local vault would not materially improve secrecy for this path.
• src/UmbracoPrism.Core/Models/PrismOidcConfiguration.cs and src/UmbracoPrism.Core/Controllers/TenantManagementController.cs show the real security gap: generic OIDC secrets are still handled as raw values rather than references.

Anti-Patterns

• Making Azure Key Vault a fresh-clone requirement for local Aspire demos.
• Adding a seeded local vault container and calling that “secure by default” when the demo secret is still repo-known.
• Treating a local vault as a substitute for refactoring the tenant model to use secret references/provider-backed resolution.