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

[Copilot]

Description

Formalizes secret handling across environments: User Secrets for local dev, Azure Key Vault with Managed Identity for production. Eliminates risk of committing secrets while enabling zero-config cloud deployment.

Changes

AppHost Integration

• Conditionally loads Azure Key Vault in non-Development environments
• Uses DefaultAzureCredential for passwordless Managed Identity auth
• Requires KeyVault:VaultName config in production, throws early if missing

if (!builder.Environment.IsDevelopment())
{
    var keyVaultName = builder.Configuration["KeyVault:VaultName"] 
        ?? throw new InvalidOperationException("KeyVault:VaultName required");
    
    ((IConfigurationBuilder)builder.Configuration).AddAzureKeyVault(
        new Uri($"https://{keyVaultName}.vault.azure.net/"),
        new DefaultAzureCredential());
}

Project Configuration

• Initialized User Secrets for Visage.Services.Eventing and Visage.Services.Registrations
• Added Azure packages: Azure.Identity v1.17.0, Azure.Extensions.AspNetCore.Configuration.Secrets v1.4.0

Documentation

• SECRETS.md: Local setup, Azure Key Vault config, Managed Identity RBAC (Key Vault Secrets User role), secret naming conventions (Parameters: vs Parameters--), troubleshooting
• README.md: References SECRETS.md in running instructions

Testing

• 5 integration tests validate: UserSecretsId presence, Azure package references, Key Vault config logic, documentation completeness
• Tests use dynamic path resolution via solution file discovery

Deployment Requirements

Production environments require:

1. Azure Key Vault with secrets using double-dash naming (Parameters--auth0-clientsecret)
2. Managed Identity with Key Vault Secrets User role assignment
3. KeyVault:VaultName environment variable

Breaking Changes

None. Existing User Secrets configuration continues working unchanged.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Implement Multi-Environment Secret Management (User Secrets & Azure Key Vault)</issue_title>
<issue_description>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.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Implement Multi-Environment Secret Management (User Secrets & Azure Key Vault) #220

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.