Loading settings at runtime from key vault

The next possible location for storing app service settings is in an Azure key vault, where the application loads them at runtime. To make this possible, the following has to be in place.

To be able to authorize an application with access to a key vault, the application first has to be able to authenticate itself against the Azure Active Directory (AAD). Of course, this can be done by registering a service principal manually, but this would return a username and password that have to be stored somewhere. Usernames and passwords are secrets, but cannot be stored in the key vault since they are needed for accessing it. This problem of how to keep the key to the vault safe can be solved by using an Azure capability called Managed Identity.

The problem of securely storing secrets but getting another secret in return for accessing them is often referred to as the problem of turtles all the way down. This is an old anecdote to which a link is included at the end of this chapter.

With Azure Managed Identity enabled on an app service, Azure automatically generates a service principal with a non-retrievable username and password. Only at runtime, using specific code, can an application authenticate itself as this principal. Azure will ensure that this will only work for code that is running with the app service that the Managed Identity belongs to.

Now that an application can have its own identity, that identity has to be granted access to the key vault. This can be done in the key vault description in an ARM template, using the following syntax:

{
"type": "Microsoft.KeyVault/vaults",
"name": "[parameters('keyVaultName')]",
"apiVersion": "2015-06-01",
"location": "[resourceGroup().location]",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/', parameters('appServiceName'))]"
],
"properties": {
"enabledForTemplateDeployment": false,
"tenantId": "[subscription().tenantId]",
"accessPolicies": [
{
"tenantId": "[subscription().tenantId]",
"objectId": [reference(concat(resourceId('Microsoft.Web/sites',parameters('appServiceName')),
[line continued] '/providers/Microsoft.ManagedIdentity/Idntities/default'),
[line continued] '2015-08-31-preview').principalId]",
"permissions": {
"secrets": [ "get", "list" ]
}
}
],
"sku": {
"name": "standard",
"family": "A"
}
}
}

In this example, the reference() function is used to retrieve the information of the Managed Identity and uses this to create an access policy on the key vault.

Finally, with the key vault and access to it set up, the application has to retrieve the contents at start up time. To do this, config builders can be used. They are introduced with .NET Core 2.0 (and .NET Framework 4.7.1) and are used in the StartUp class, as shown in the following code snippet:

var tokenProvider = new AzureServiceTokenProvider();
var kvClient = new KeyVaultClient((authority, resource, scope) =>
tokenProvider.KeyVaultTokenCallback(authority, resource, scope));

var configurationBuilder = new ConfigurationBuilder().AddAzureKeyVault(
$"https://{ Configuration["keyVaultName"]}.vault.azure.net/",
kvClient,
new DefaultKeyVaultSecretManager());

Configuration = configurationBuilder.Build();

All types in this code example are available in the NuGet package, Microsoft.Configuration.ConfigurationBuilders.Azure.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.86.138