October 25, 2021 –5 Reading minutes
Delivering an app configuration can be tricky.
When working with .NET applications be sure to use the power of configuration and configuration providers to handle any type of configuration. Do not try to reinvent it by adding simplicity and new interfaces.
IConfiguration And built-in vendors for configuration handling.
Here are 5 ways you can handle application configuration when building .NET applications on the Azure infrastructure.
Application development starts on your local computer. So let’s start our configuration there as well.
Configuration values for an application are best defined in
appsettings.json. When building an app I set all possible configuration keys in
Whether the value of the configuration is indeed defined there or not is another matter – sometimes it is, most of the time it is not. However, all the possible keys in one place, helps to understand the possible values that exist.
For demonstration purposes, in this example, let’s define a hierarchical structure of configuration values for us to define using different mechanisms. Let’s start with the section
Demo Which has 6 different keys below it.
All values are set to
appsettings.json So that we know where the value is determined. We will bypass these values from different sources that we will see when we go over the different possible options for defining values.
"Demo": "Key1": "appsettings.json", "Key2": "appsettings.json", "Key3": "appsettings.json", "Key4": "appsettings.json", "Key5": "appsettings.json", "ConnectionString": "appsettings.json"
ASP NET Core supports bypass
appsettings A file based on the environment in which you operate.
For example, when we run the application on our local computer, ASP NET Core refers to it as
Development around the. It is determined through the
launchsettings.json File in the project using the
DOTNET_ENVIRONMENT) Defined asdevelopment‘
By default ASP NET Core also adds a
appsettings.Development.json A file that bypasses configuration values (if specified) in the application settings file.
"Demo": "Key1": "appsettings development", "Key3": "appsettings development", "Key5": "appsettings development"
Definitions above b
appsettings.Development.json Bypasses values for Key1, Key3, and Key5 specified in the appsettings.json file.
The default configuration providers are set so that the environment-specific configuration files override the default
appsettings.json Configuration values.
Application settings files are usually stored as part of the source code and are available in your git repository. This makes it a bad place to store any kind of sensitive information.
To avoid having to transfer configuration files along with sensitive information to the source code repository, you can use the Secrets Manager feature available as part of ASP NET.
To add values to Secrets Manager in a local development environment, you can use the user interface (via Visual Studio) or use the command-line tool.
The values set in the Secrets Manager override those in the application settings file (both global and environment-specific).
The value below b
secrets.json (As part of the Secrets Manager) overrides the value for ‘Connecting string‘.
"Demo": "ConnectionString": "Secrets Manager"
Let’s write a method to show how these configuration values are evaluated at runtime.
MyConfigController Reveals all configuration values under the demo section. It gives the actual values that the application uses at runtime.
Note: This endpoint is for demonstration purposes only and do not add such an endpoint to your real-world app. This is a recipe for disaster.
[ApiController] [Route("[controller]")] public class MyConfigController: ControllerBase public MyConfigController(IConfiguration configuration) Configuration = configuration; public IConfiguration Configuration get; [HttpGet] public Dictionary<string,string> Get() return Configuration .GetSection("Demo") .GetChildren() .ToDictionary(a => a.Key, a => a.Value);
Activating the application and activating the MyConfig An endpoint returns the configuration values as expected. Key 1, Key 3 and Key 5 Deleted by GodDevelopment of application settingsValues and Connecting string By ‘Managing Secrets‘ value. (As shown below in the Swagger response).
Now that the sample app is running, let’s set up a build-layout pipe. This will allow us to automatically deploy the application to different environments (development, testing, production, etc.).
If you are new to the DevOps build-deploy pipeline, check out my YouTube series covering different application deployment scenarios. For this specific
Azure DevOps allows you to define and bypass variables within the build-release pipeline. When creating a release pipe, under the Variables section we can set environment-specific configuration values.
For hierarchical values ’.’ (Dot) serves as a separator. So in this case to set the configuration value for Key1 which is under the demo section, we can set the value in the DevOps pipe as’Demo.Key1‘.
The value can be set for all versions or environment specific (or combine). It is set using domain option. In the chart below, development and a test Stand for independent environments and release Represents all editions.
In this case because it is a Web App deployment job, under the deployment task there is an option to enable ‘File conversion and variable replacement’ and specify the files to be replaced. In this case appssettings.json.
Variables defined in the release pipe that match the names in the configuration file will be automatically replaced with the value / environment they are set for.
Azure resources usually have a Setting configuration where you can configure an application.
Values defined in the app settings are usually available as environment values when running on the Azure infrastructure. In this case because we are deploying the Azure Web application, you can configure it from the Azure Portal manually or through the build / deploy pipeline.
Azure Key Vault is a cloud-hosted service for managing cryptographic keys and secrets like connection strings, API keys and similar sensitive information. Key Vault provides central storage for app secrets. Check out my posts on Key Vault if you’re new to Azure Key Vault and want to learn more.
You can integrate with Key Vault in two ways
Deployment time: In Azure DevOps you can create variable groups and integrate directly with Azure Key Vault and select application-specific secrets for your application.
Below I have a variable group
For hierarchical configuration values, you must explicitly map the properties from Key Vault to a format that DevOps understands. This is because a secret name must start with a letter and contain only 0-9, az, az and.
So in our case, I explicitly mapped ‘Demo – Key 5‘To format’Demo.Key5In the Variables section for the version.
You can also write a script to automate it in your pipeline if necessary.
running time: Applications can also talk to Key Vault at runtime and retrieve values from it. The app can download entries at startup or refresh them periodically or retrieve from Key Vault whenever it needs it.
Want to learn how to manage connecting strings more securely?
Learn how to easily configure Azure Key Vault to manage connection string and other sensitive information for your applications.
Azure App configuration Provides a central management service for application settings and feature flags. This allows you to centralize the application in one place and allow different applications to use it.
For ASP NET application you can use Microsoft.Azure.AppConfiguration.AspNetCore Nuget package for integrating Azure App Configuration with the default configuration provider. Below is a sample code on how you can do this.
public static IHostBuilder CreateHostBuilder(string args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => webBuilder .ConfigureAppConfiguration(config => var settings = config.Build(); var connection = settings.GetValue<string>("Demo:ConnectionString"); config.AddAzureAppConfiguration(connection); ) .UseStartup<Startup>(); );
Managed identities provide application identities that can be used to validate resources in the Azure infrastructure.
Managed identity explicitly removes the need to define connecting strings, secrets, etc. Application resources can be configured so that they can talk to each other and ensure that they are authenticated and licensed and managed by the Azure infrastructure.
In the past, Azure had different ways to validate with different resources. God Azure SDK Brings it all under one roof and provides more unified access to developers when connecting to resources in Azure.
For resources that support Managed Identity, the client’s SDKs also take the
DefaultAzureCredential As part of building their boot code.
Want to learn more about DefaultAzureCredential?
In the past, Azure had different ways to validate with different resources. The Azure SDK brings it all under one roof and provides more unified access to developers when connecting to resources in Azure.
DefaultAzureCredential Receives the token based on the environment in which the application is running. The following types of credentials if enabled will be tested, in order – EnvironmentCredential, ManagedIdentityCredential, SharedTokenCacheCredential, InteractiveBrowserCredential.
Below is a sample code of the user
DefaultAzureCredential To connect to Azure App Configuration
Host.CreateDefaultBuilder(args) .ConfigureAppConfiguration(configuration => configuration.AddAzureAppConfiguration(options => options .Connect(new Uri("https://youtube-demo-test.azconfig.io"), new DefaultAzureCredential()) .UseFeatureFlags(); ); )
As can be seen above, it does not use sensitive information to create an Azure App Configuration connection. All he uses is the resource URL and the
DefaultAzureCredential A class, which does all the heavy duty.
We’ve seen different options for storing configuration values when building .NET applications running the Azure infrastructure. Based on your team and type of application, you can select and choose different options shown above.
Mix and match options if that’s what’s right for you.
But always make sure you store sensitive information securely and never check it for source control.