When working with Umbraco in a cloud environment, it's common to use Azure Key Vault for managing secrets securely. However, during local development, you might want to bypass specific keys to use local configurations instead. A simple way to achieve this is by customizing the KeyVaultSecretManager to exclude certain keys when running in a development environment.
To filter out specific secrets from Key Vault during development, you can implement a DevelopmentKeyVaultSecretManager:
internal sealed class DevelopmentKeyVaultSecretManager(string? excludedKeys) : KeyVaultSecretManager
{
public override Dictionary<string, string> GetData(IEnumerable<KeyVaultSecret> secrets)
{
var keys = excludedKeys?.Split([','], StringSplitOptions.RemoveEmptyEntries) ?? [];
return base.GetData(secrets).Where(secret => !keys.Contains(secret.Key)).ToDictionary();
}
}
To integrate this into your Umbraco project, modify the Program.cs file to conditionally register Azure Key Vault, filtering out excluded keys during local development:
var excludedKeys = builder.Configuration.GetValue<string>("KeyVault:ExcludedKeys");
if (builder.Environment.IsDevelopment())
{
builder.Configuration.AddAzureKeyVault(
new Uri(builder.Configuration["KeyVault:Uri"]),
new DefaultAzureCredential(),
new DevelopmentKeyVaultSecretManager(excludedKeys));
}
else
{
builder.Configuration.AddAzureKeyVault(validUri, credential);
}
⚠️ Warning: Connecting to a different database should only be done for debugging purposes and preferably with a local database to avoid unintentional modifications to production or shared environments.
To exclude the Umbraco database connection string from Key Vault during local development, you can define the ExcludedKeys setting in appsettings.Development.json:
{
"KeyVault": {
"ExcludedKeys": "ConnectionStrings:umbracoDbDSN"
}
}
This ensures that the local connection string is used instead of being retrieved from Azure Key Vault. This way you can debug with your a local database instead of the one configured in KeyVault.
This approach is not limited to database connections. You can also use it to switch external API endpoints between different environments. For example, during development, you might want to test against a staging API rather than the production API. By excluding API-related secrets from Key Vault, you can define them in your local configuration files, ensuring your development setup remains flexible and mirrors real-world scenarios without interfering with live environments.