Centralized Configuration Management using Azure App Configuration: Local Debugging When Using Managed Identities to Access Azure App Configuration

Centralized Configuration Management using Azure App Configuration Series

• Introduction
• Using Managed Identities to Access Azure App Configuration
• Setting Up Dynamic Refresh for Configuration Values
• Setting Up Offline Caching
• Implementing Custom Offline Cache
• Using Azure Key Vault Side-by-Side
• Local Debugging When Using Managed Identities to Access Azure App Configuration (This Article)

In some of the previous articles on Using Managed Identities to Access Azure App Configuration and Using Azure Key Vault alongside Azure App Configuration we used Managed identities to access these azure resources. Managed identities are a credentials free way of accessing Azure resources backed by Azure Active Directory and is a best practice when accessing Azure resources from your applications.

But if you notice when we use the Azure.Identity library and ManagedIdentityCredential to access these resources, when you try to run the application locally do debug, the application won’t run and throw an exception when trying to access Azure App Configuration and Azure Key Vault. This is because we are only supporting the use of Managed Identities. The best option to use when it comes to TokenCredential implementation is to use the DefaultAzureCredential implementation.

Using DefaultAzureCredential

The DefaultAzureCredential implementation determines the appropriate credential type depending on the environment the application is running on. It supports, the authentication with a Service Principle and using its Client ID and Secret and supports using Managed Identities both System-Assigned and User-Assigned managed identities. So, this means we can use the DefaultAzureCredential in our implementation and when running it locally for debugging we can use a Service Principle for authentication and then when running on the Azure Cloud, use a Managed Identity to access the resources we need. Giving us the flexibility, we need.

It’s simple to make the update to our existing Music Store application. Look at the code sample below.

using Azure.Identity;
using Microsoft.Extensions.Configuration.AzureAppConfiguration;

namespace MusicStore.Web
{
  public class Program
  {
    ...
    public static IHostBuilder CreateHostBuilder(string[] args) =>
      Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder => {
          webBuilder.UseStartup<Startup>();
        })
        .ConfigureAppConfiguration((context, config) => {
          var settings = config.Build();
          var appConfigEndpoint = settings["AppSettings:AppConfiguration:Endpoint"];
          var userAssignedIdentityClientId = settings["AppSettings:Identity:ClientId"];

          if (!string.IsNullOrEmpty(appConfigEndpoint))
          {
              var endpoint = new Uri(appConfigEndpoint);

              // Create the token credential instance with the client id of the Managed Identity
              var credentialOptions = new DefaultAzureCredentialOptions {
                ManagedIdentityClientId = userAssignedIdentityClientId
              };

              config.AddAzureAppConfiguration(options =>
              {
                options
                  // Use managed identity to access app configuration
                  .Connect(endpoint, new DefaultAzureCredential(credentialOptions))
                  ...
                  // Configure Azure Key Vault with Managed Identity
                  .ConfigureKeyVault(vaultOpt =>
                  {
                      vaultOpt.SetCredential(new DefaultAzureCredential(credentialOptions));
                  })
                  ...
              });
          }
        });
  }
}

I’ve created an instance of DefaultAzureCredentialOptions class and set the ManagedIdentityClientId property to the client ID of the User-Assigned Managed Identity. Then I am passing in the credentialOptions instance into DefaultAzureCredential and then passing it into App Configuration Connect() method and Key Vault SetCredentials() method.

Create Service Principle on Azure AD

We need a service principle to run the application locally. So what I’ve done is create a new Azure AD App Registration and then create a Secret for that the registered application.

Then I can copy over the Client ID, Tenant ID and the Secret created and set these as Environment variables in my local development machine.

Using Visual Studio to Set the Environment Variables

We can use go to the Visual Studio Project Properties and in the Debug section set Environment Variables. We need to set the following variables.

• AZURE_CLIENT_ID – Client id of the Azure AD application
• AZURE_CLIENT_SECRET – Secret created in the Azure AD application
• AZURE_TENANT_ID – Tenant id of the Azure AD directory

Once you have done that it should look something like this

Now when you run the application locally, you can see that it is using the Service Principle and are able to access both Azure App Configuration and Azure Key Vault from your development machine. And then if you publish the application into say, Azure App Services it will use the User-Assigned Managed Identity to seamlessly access the Azure resources.

Summary

In this article we looked into how we can use DefaultAzureCredential instance to have the flexibility of using Managed Identities on the Cloud and running the application in your local development machine easily to debug your application.