This post was most recently updated on February 10th, 2022.
2 min read.Azure Key Vault is great. But when developing locally, it can be a bit of a pain. You can always circumvent it and create some classical solution, such as simply wrapping all of your key/secret assignments in if-else-clauses that will use local configuration if you’re running locally and only call the Azure Key Vault if you’re in the cloud… But that feels so incredibly early-2000-ish. Isn’t there a better option available?
I mean – obviously, there is! And we’ll see how it works in just a while :)
Problem
Azure Key Vault configuration is incredibly simple if you use Managed Identities – but they’re not available when you’re just debugging your code locally. Using different sources for your keys/secrets is definitely possible, but it adds a bit of complexity to your code and is bothersome to maintain.
If only there was a great way to securely and automatically connect to the Azure Key Vault from both Azure and my local development environment…
Solution
In comes the AzureServiceToken! It uses the Managed Identity if one is available – but will fall back to another method in the following order:
- A managed identity for Azure resources
- Visual Studio authentication
- Azure CLI authentication
- Integrated Windows authentication
With that out of the way, see the steps below:
Time needed: 15 minutes
How to implement Azure Key Vault for local development & Managed Identity?
- Add your dependencies
Add these NuGet packages:
Microsoft.Azure.Services.AppAuthentication
Microsoft.Extensions.Configuration.AzureKeyVault
Versions (for me, anyway) were 1.6.2 and 2.1.1, respectively. These should work for at least .NET Core 3.1 (and probably newer). - Implement authentication
Something like this should work:
// This works in DEV environments (as long as you've run "az login" first) and in Azure as long as Managed Identity has been configured
var azureServiceTokenProvider = new AzureServiceTokenProvider();
var keyVaultClient = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
And the using-statements should be somewhat like this:using Microsoft.Azure.KeyVault;
using Microsoft.Azure.Services.AppAuthentication;
And after this, something like this should work:var secretBundle = await keyVaultClient.GetSecretAsync($"{Environment.GetEnvironmentVariable("KeyVaultName")}/secrets/{keyName}").ConfigureAwait(false);
var secret = secretBundle.Value; - (OPTION 1) Sign in to Visual Studio using the credentials that can access the Key Vault
In case you CAN log in to Visual Studio with just the account that is able to connect to Azure Key Vault, that’s probably the easiest thing to do. That (cached) identity should be used as-is by the Azure Key Vault client.
However, if you need to use multiple accounts in your Visual Studio, this won’t work. Well, in my experience, usually it won’t.
But no worries, as there’s another way to populate the credential cache… - (OPTION 2) Use az CLI to store your preferred account into the credential cache
This is only required if your preferred credential is not your main Visual Studio account.
To perform this step, you’ll need the az CLI – which you can download from here:
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
Then, open a command line and run “az login” with your user.
And you should be good! Yeah – it is pretty much magic. But with modern computing, what isn’t?
References
- The list of authentication methods:
- How to solve keyboard shortcuts not working in Google Chrome on Windows? - September 10, 2024
- Search (and secretly, sync) broken in OneNote? A quick fix! - September 3, 2024
- “Destination Path Too Long” when copying files in File Explorer? Easy workaround(s)! - August 27, 2024