This post was most recently updated on January 12th, 2022.2 min read.
So, a while ago I posted about a fairly simple way to write your code for fetching secrets (and other confidential stuff) from Azure Key Vault in such a way, that it would work the same way both in Azure and on your local dev box. I find this pretty important, as it reduces the need for weird workarounds and fallbacks in your code, and at the same time enables you to harness the Azure Key Vault for that sweet spot of “good enough security without breaking your back or the bank”.
That post was apparently a bit of a hit. I am happy to see that so many of you are struggling with the same things as me!
Wait, that didn’t come out correctly, did it? 😅 Anyway, the article is linked below!
But… There’s a bit of a problem with the solution. You’ll get Visual Studio complaining about deprecated dependencies – and for a fair reason! Microsoft.Azure.Services.AppAuthentication has been deprecated in favor of a more recent library, Azure.Security.KeyVaults.Secrets.
So, time to upgrade, right? 😉
Well, it turns out, upgrading isn’t that difficult. You get rid of the old stuff, add the new stuff, and change a couple of lines.
You’ll replace the “old” Microsoft.Azure -dependencies – namely, KeyVault and AppAuthentication – with more modern “Azure.Security.KeyVault.Secrets” and “Azure.Identity”.
I’m getting the feeling that naming stuff is hard for Microsoft, too…
With that out of the way, see the steps below:
Time needed: 15 minutes.
How to migrate from Microsoft.Azure.Services.AppAuthentication to Azure.Security.KeyVault.Secrets
- Fix your dependencies
Remove these NuGet packages:
And add these:
For me, the versions were 4.2.0 and 1.5.0 (respectively), in case that interests you :)
- Change from AzureServiceTokenProvider to DefaultAzureCredentialOptions
Okay, this sounds a bit convoluted, but instead of generating the default AzureServiceToken (which used to use CLI and such if they were available), we’ll define AzureCredentialOptions – and instantiate a new DefaultAzureCredential with them!
Something like shown below:
(the disallowed and allowed ways – or “days”, pardon my typo in the screenshot above – to authenticate should be fairly self-explanatory)
- Change from KeyVaultClient to SecretClient
Then pass the KeyVault name (or more like “domain”) and the aforementioned DefaultAzureCredential (with your options) to new SecretClient() instead of a KeyVaultClient
- Figure out a configuration that works for you
This might require some retries – my screenshot (in step 2) shows what works for me (I’m disallowing most ways to authenticate, and then leaving the ones that are available for me), but YMMV.
Note, that you’re setting true/false for “exclusion switches”. So, to disable a kind-of-a-credential set the value to true.
And with that, you should be good! At least once, some migration/upgrade task was actually quite simple :)
Almost the whole upgrade is shown in this single commit to a single file below:
Did it work for you? Let me know in the comments -section below!
- My earlier blog post about the topic: https://www.koskila.net/how-to-authenticate-against-azure-key-vault-both-in-azure-and-local-development-environment/
- Microsoft’s documentation for the migration – I didn’t even realize this exists, as the migration was so easy I didn’t need to see it. But maybe your case is more complicated – here’s the link: