Secrets are sensitive values—such as passwords, cryptographic keys, connection strings, and API keys—that can put systems at risk if exposed. Unlike ordinary environment-specific configuration, they require controlled access. section 13.4
Keep secrets out of appsettings.json and checked-in source. Repository access is a threat vector, and a leaked password can require rotating credentials and cleaning up Git history. section 9.4.2
Provide secrets according to the deployment context:
- In production, have the deployment pipeline retrieve secrets from a secure store and make them available to the application; Kubernetes provides secrets to pods. section 9.4.2
- For local development, initialize .NET Secret Manager with dotnet user-secrets init. Its project GUID can be checked in; the referenced secret file stays on the developer’s machine. section 9.4.2
- Environment variables can supply secrets, including in Azure App Services, but they are no longer recommended for Kubernetes because they are less secure than Kubernetes secrets. section 9.4.2
Listing 9.13 Adds the connection string to Secret Manager for ManningBooksApi project
dotnet user-secrets set "ConnectionStrings:Catalog" "DataSource=manningbooks.db;cache=shared"
Store a local connection string with the .NET Secret Manager command rather than placing it in appsettings.json. section 9.4.2
Listing 9.14 Getting connection string from secret through configuration
var builder = WebApplication.CreateBuilder(args);
var config = builder.Configuration; #1
builder.Services.AddDbContext<CatalogContext>(options =>
{
var connStr = config.GetConnectionString("Catalog"); #2
options.UseSqlite(connStr);
});
Read the stored connection string through application configuration when configuring the database context. section 9.4.2
