Introduction
Storing secrets in appsettings.json is not recommended for production applications. With .NET, you can connect your application to Azure Key Vault in two common ways:
By adding Azure Key Vault as a configuration provider.
By using
SecretClientdirectly to retrieve secrets.
1. Azure Key Vault as a Configuration Provider
The first approach adds Azure Key Vault to the application's configuration pipeline:
var builder = WebApplication.CreateBuilder(args);
builder.Configuration.AddAzureKeyVault(
new Uri(builder.Configuration["KeyVault:Uri"]!),
new DefaultAzureCredential());
For example, a secret named:
Database--Password
is automatically mapped to the configuration key:
Database:Password
You can then bind this configuration to a strongly typed options class:
builder.Services.Configure<DatabaseOptions>(
builder.Configuration.GetSection("Database"));
public sealed class DatabaseOptions
{
public string Password { get; set; } = string.Empty;
}
This approach works well when your secrets are part of the application's configuration and you want to access them using the Options pattern, such as IOptions<T>.
2. Direct Access Using SecretClient
The second approach is to use the Azure SDK directly through SecretClient:
builder.Services.AddSingleton(sp =>
new SecretClient(
new Uri(builder.Configuration["KeyVault:Uri"]!),
new DefaultAzureCredential()));
A service can then retrieve a secret whenever it is needed:
public sealed class SecretService(SecretClient client)
{
public async Task<string> GetAsync(string name)
{
var secret = await client.GetSecretAsync(name);
return secret.Value.Value;
}
}
This approach is useful when secrets need to be retrieved dynamically. It is also a good choice when you need to work with specific secret versions or perform operations such as creating, updating, or deleting secrets.
Conclusion: Choosing the Right Approach
Both approaches provide a secure way to integrate Azure Key Vault with your application. The right choice mainly depends on how your application needs to use the secrets.
For most application configuration scenarios, adding Azure Key Vault to IConfiguration and using the Options pattern is the better choice. It keeps the code clean, follows the standard .NET configuration approach, and prevents Key Vault-specific code from spreading across different business services.
Use SecretClient when secrets need to be retrieved dynamically at runtime or when your application needs more advanced Key Vault operations, such as retrieving a specific secret version, creating or updating secrets, or managing secret metadata.
A few practical recommendations:
Never store sensitive values in
appsettings.jsonor source control.Use Managed Identity with
DefaultAzureCredentialin Azure-hosted applications instead of storing credentials to access Key Vault.Register
SecretClientas a singleton. Azure SDK clients are designed to be long-lived and reused.Use the Options pattern for strongly typed application settings instead of repeatedly reading raw configuration values.
Add an abstraction over
SecretClientif your application needs custom caching, centralized secret resolution, or more complex secret-management logic.Avoid retrieving the same secret repeatedly when the value can be safely cached.
Generally, use configuration binding for application settings and SecretClient for dynamic secret-management scenarios. The goal is not just to keep secrets secure, but also to keep the application clean, maintainable, and easy to test.
Happy Coding!
Summary
Azure Key Vault can be integrated into .NET applications either as a configuration provider or through the SecretClient SDK. The configuration provider is ideal for application settings that fit naturally into the .NET configuration system and Options pattern, while SecretClient is better suited for dynamic secret retrieval and advanced Key Vault operations. Choosing the appropriate approach helps build secure, maintainable, and production-ready applications.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.