Implement Multi-Environment Secret Management (User Secrets & Azure Key Vault)

[indcoder]

To improve security and developer experience, we need to formalize how our Aspire solution handles sensitive information (API keys, connection strings, etc.). The goal is to ensure that developers have a frictionless "inner-loop" while maintaining high security and zero-config deployment in production.

We will adopt the User Secrets pattern for local development and Azure Key Vault with Managed Identity for cloud environments.

🎯 Objectives
Eliminate the risk of accidentally committing secrets to source control.

Enable "passwordless" authentication in Azure using Managed Identities.

Ensure the AppHost correctly maps secrets to service projects regardless of the environment.

📋 Proposed Tasks
[ ] Local Initialization: Initialize User Secrets for all service projects and the AppHost using dotnet user-secrets init.

[ ] AppHost Integration: Configure Program.cs in the AppHost to conditionally add Azure Key Vault.

Logic: If the environment is not Development, pull secrets from the vault.

[ ] Service Discovery for Secrets: Ensure that services can resolve their specific secrets through the Aspire WithReference() syntax.

[ ] Managed Identity Setup: Document the RBAC (Role-Based Access Control) requirements for the Azure Key Vault (e.g., "Key Vault Secrets User" role).

[ ] Documentation: Create a SECRETS.md or update the README.md to guide new developers on how to set up their local .dotnet/user-secrets values.

🛠 Technical Implementation Detail
The implementation should leverage the built-in .NET Aspire Azure integrations. This allows the application to switch providers based on the environment without changing the business logic of the microservices.

// AppHost/Program.cs example
var builder = DistributedApplication.CreateBuilder(args);

// Only attempt to connect to Azure Key Vault in production/staging
if (!builder.Environment.IsDevelopment())
{
var secrets = builder.AddAzureKeyVault("vault-name");
builder.AddProject<Projects.ApiService>()
.WithReference(secrets);
}
else
{
// Locally, the ApiService will automatically use its own User Secrets
builder.AddProject<Projects.ApiService>();
}

✅ Acceptance Criteria
[ ] No plain-text secrets exist in any appsettings.json file.

[ ] A developer can clone the repo, add their local User Secrets, and run the app successfully.

[ ] The AppHost successfully starts in "Production" mode (simulated locally) only when a valid Key Vault is provided.

[ ] Deployment manifests (via azd) correctly include the Key Vault resource.