Managed Service Identity (MSI) allows you to solve the "bootstrapping problem" of authentication.
You can put your secrets in Azure Key Vault, but then you need to put keys into the app to access the Key Vault anyway!
MSI is a new feature available currently for Azure VMs, App Service, and Functions. At the moment it is in public preview.
It solves this bootstrapping problem by creating a dynamic endpoint within your service, through which you can get access tokens to any Azure AD-protected service, as long as you have given the necessary permissions to the automatically generated service principal.
It is amazingly simple to use. Let's check how we could use it from an ASP.NET Core App.
Enabling MSI on a Web App
To enable a Web App to use Managed Service Identity, all you have to do is toggle a switch :)
Just toggle the switch to On and hit Save!
This will actually create a service principal in your Azure AD.
You can then grant this service principal access to Azure resources, like an Azure Key Vault.
Alright, so now we have a service principal which is allowed to get secrets from a Key Vault.
Getting a token for Key Vault
To get an access token, you can use the Microsoft.Azure.Services.AppAuthentication library.
var azureServiceTokenProvider = new AzureServiceTokenProvider(); string token = await azureServiceTokenProvider.GetAccessTokenAsync("https://vault.azure.net");
Wait what? Two lines of code?
Yes, only two lines of code. And we now have an access token for Key Vault.
What happens under the hood
The authentication library makes an HTTP GET request to a local endpoint that has been created dynamically.
For my Azure Web App, this was
Now how did I get that URL?
Easy, MSI injects two environment variables to your app process:
The first is the URL from above. The second contains a secret that must be attached to the request.
The library reads these variables and makes the call to get the access token.
Now of course we do not have MSI available locally.
The Microsoft.Azure.Services.AppAuthentication library allows usage locally as well.
If used outside Azure, it will authenticate as the developer's user. It will try using Azure CLI 2.0 (install from here). The second option is AD Integrated Authentication.
After installing the CLI, remember to run
az login, and login to your Azure account before running the app.
Another important thing is that you need to also select the subscription where the Key Vault is.
So if you have access to more than one subscription, also run
az account set -s "My Azure Subscription name or id"
Then you need to make sure your user has access to a Key Vault (does not have to be the production vault...).
Now you can run the code from above, and it will still work!
Thanks for reading! I think Managed Service Identity is an awesome solution to the bootstrapping problem.
Now you do not need to put any keys/certificates in your app, or even App Settings in App Service apps!