Date:

Share:

5 Ways to Handle Application Configuration & Secrets With Azure ๐Ÿ”

Related Articles

October 25, 20215 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.

to use 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.

Local environment configuration

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 appsettings.json file.

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"
  

Environment-specific configuration values

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 ASPNETCORE_ENVIRONMENT (or 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.

Managing Secrets

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"
  

Check configuration controller

Let’s write a method to show how these configuration values โ€‹โ€‹are evaluated at runtime.

down 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 Secretsvalue. (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

1. Azure DevOps variables

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.


Configuration value is set in Azure DevOps Release Variables

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.


Azure DevOps Web Application Transform for Configuration

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.

2. Azure app settings

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.


Configuration from Azure App settings in Web App Configuration

Light blue key safe

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

  1. 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


    Configuration values โ€‹โ€‹from Azure Key Vault in Azure DevOps using variable groups

    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.


    Mapping a hierarchical configuration value from Key Vault to Azure DevOps

  2. 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.

4. Azure App configuration

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>();
    );

5. Managed identity

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.

God 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.

Photo by Max Bender On Unsplash

Buy me coffee

Source

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Popular Articles