Secure App Service Access to Key Vault with Managed Identities

The Credential-less Authentication Flow

Before we dive into the Azure portal and your code, let's visualize the end-to-end process. By enabling a managed identity, you are creating a trust relationship between your App Service and other Azure resources, brokered by Microsoft Entra ID.

The process works in a sequence:

1. Enable Identity: You enable a system-assigned managed identity on your App Service. Azure creates a corresponding service principal in Microsoft Entra ID.
2. Grant Permissions: You assign an RBAC (Role-Based Access Control) role, such as "Key Vault Secrets User," to this new identity on your Key Vault. This grants it permission to read secrets.
3. Request Token: When your deployed .NET code tries to access Key Vault using the DefaultAzureCredential class from the Azure Identity library, the SDK makes a request from a local endpoint on the App Service infrastructure to get an access token.
4. Access Secret: The SDK then uses this token to make a REST API call to Key Vault. Key Vault validates the token with Microsoft Entra ID and checks the role assignment. If everything is valid, it returns the secret to your application.

This entire exchange happens without a single password or connection string being stored in your application's configuration files.

Step 1: Configure the Identity and Permissions

The first two steps—enabling the identity and granting it permissions—are configuration tasks you'll perform in Azure. You can do this through the Azure Portal, Azure CLI, or PowerShell. For your first time, the portal is very intuitive, but knowing the CLI commands is valuable for automation and the exam.

The following screenshot shows where you'll enable the identity in the portal.

The video below provides a complete, practical demonstration of creating the App Service, enabling its identity, and then granting it the necessary permissions on the Key Vault.

Step 2: Update Your .NET Application

With the Azure infrastructure configured, the next step is to update your .NET application to leverage this new identity. This involves removing hardcoded secrets and using the Azure SDK to fetch them from Key Vault at runtime.

As a .NET developer, you'll appreciate the simplicity provided by the Azure.Identity library. The key component is the DefaultAzureCredential class. It's a powerful tool that automatically tries several authentication methods in a specific order.

• When your code is running in Azure (e.g., in an App Service with a managed identity), DefaultAzureCredential will automatically detect and use that identity.
• When you run the same code on your local development machine, it will try to authenticate using your Visual Studio, Azure CLI, or PowerShell credentials.

This allows you to write one piece of code that works seamlessly in both your local and deployed environments.

You'll need to install two NuGet packages:

• Azure.Identity: Provides the DefaultAzureCredential.
• Azure.Security.KeyVault.Secrets: Provides the SecretClient to interact with Key Vault.

// In your Program.cs or Startup.cs
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

// ...

var keyVaultUri = new Uri("https://YOUR-KEY-VAULT-NAME.vault.azure.net/");

// DefaultAzureCredential will use the managed identity when deployed to Azure
var client = new SecretClient(keyVaultUri, new DefaultAzureCredential());

// Now you can fetch secrets without any credentials in your code
KeyVaultSecret secret = await client.GetSecretAsync("YourSecretName");
string secretValue = secret.Value;

// Use the secretValue in your application (e.g., as a connection string)

The following video clip walks you through this exact process: removing secrets from appsettings.json and modifying Program.cs to use DefaultAzureCredential.

Step 3: Deploy and Verify

The final step is to deploy your updated application and see it all work together. A powerful way to confirm that the managed identity is working correctly is to observe the application fail before the identity is configured, and then succeed afterward.

The following walkthrough demonstrates this "fail-then-succeed" sequence perfectly.

This sequence provides undeniable proof that the managed identity is handling the authentication, as no code or configuration changes were made between the "fail" and "succeed" states—only Azure infrastructure configuration was changed.

For a detailed, text-based alternative that uses the Azure CLI for configuration, you can review the official Microsoft tutorial.

Conclusion

Congratulations! You have now completed the practical implementation of one of Azure's most important security features. By moving credentials out of your application and into Azure's identity platform, you have significantly improved the security posture of your application.

Here are the key takeaways from this lesson:

• Configuring a managed identity to access Key Vault is a three-step process: enable the identity, grant it permissions via RBAC, and update your code to use DefaultAzureCredential.
• The DefaultAzureCredential class is the cornerstone of this pattern in .NET, as it seamlessly adapts to both local development environments and deployed Azure environments.
• This passwordless pattern is a best practice that eliminates the risk of leaked secrets from configuration files or source code.

This lesson concludes our module on managing secrets. In the next module, we will shift our focus to application performance, starting with how to implement caching strategies using Azure Cache for Redis.