Introduction into managing Application Secrets in Azure AppConfiguration Service with .NET Core

1. Introduction into managing Application Secrets in Azure App Configuration Service with .NET Core (current post)
2. Managing Application Secrets in Azure App Configuration Service with .NET Core Code Walkthrough (next)

Whether you are writing an ASP.NET Core website or a new .NET Core based application that will be run somewhere in the cloud you are almost always confronted with the question of where to reliably and securely store the application secrets.

With the introduction of Microsoft.Extensions.Configuration Microsoft has introduced an extensible configuration model that can be extended by different configuration providers. Those configuration providers by default allow to load application specific settings like appsettings.json or appsettings.{Environment}.json with the FileConfigurationProvider, Secret Manager that stores settings in the development environment using an identity provided by the entry assembly, Environment Variables using the Environment Variables Configuration Provider or via Command-line arguments using the Command-line Configuration Provider.

Generally, the appsettings files work well for storing and retrieving non-sensitive data that can be committed to the source code repository. When it comes to storing and retrieving sensitive data such as passwords, access tokens, personally identifiable data or other sensitive connection data like connection strings the appsettings approach falls short. As a default solution, most developers then fall back to using Environment variables which are clumsy to manage and hard to refresh (requires IDE or editor restart). Furthermore, Environment variables are generally stored in plain, unencrypted text. If the machine or process is compromised, environment variables can be accessed by untrusted parties (1).

For local development the Secret manager provides a good alternative to store sensitive data during development. The Secret Manager seperates the data from the project tree and the data can be associated with a specific project or shared across several projects without needing them to check into source control. The Secret Manager though is not trusted stored because it doesn’t encrypt the stored secrets and when the user profile is not synchronized the secrets have to be defined on all machines (for example if you have a laptop and a workstation) where the project is built, executed and tested.

For storing and testing Azure test and production secrets Microsoft recommendation was to use the Azure Key Vault configuration provider. With the key vault provider sensitive information is stored in the highly secure Azure Key Vault service. The approach allows you to combine it with Managed identities for Azure resources to authenticate the app to Azure Key Vault with Azure AD authentication without credentials stored in the application code. KeyVault though does not provide higher level functionality like

• Managing and distributing of hierarchical configuration data for different environments and geographies
• Dynamic configuration changes without redeploying or restarting an application
• Feature management

If such functionality was desired it had to be built with custom infrastructure on top of KeyVault. With the recently introduced App Configuration Service in Azure (currently in preview) these days are over! The service offers the following benefits:

• A fully managed service that can be set up in minutes.
• Flexible key representations and mappings.
• Tagging with labels.
• Point-in-time replay of settings.
• Comparison of two sets of configurations on custom-defined dimensions.
• Enhanced security through Azure-managed identities.
• Complete data encryptions, at rest or in transit.
• Native integration with popular frameworks.

The .NET integration for the App Configuration service amazing. You can use it in ASP.NET Core, .NET Core and as well as Azure Function applications. If you can target .NET Framework 4.7.1 or higher there is even a full framework integration available that leverages the good old App.config via the Configuration Manager.

In the next installment I will walk through a .NET Core application using the Generic Host leveraging the App Configuration service to manage and dynamically reload secrets.

(1) You don’t have to search to far to find an example. A pull request that contains code reading Environment variables within a unit test automatically executed by a build environment might already be enough.