Coding Azure 13: Securing Access to Your Key Vault to Your Application

Even you shouldn’t be allowed to see the secrets in your Azure Key Vault. Which means that creating a Key Vault is only useful if you limit access to its secrets to just one thing: your application.

Some things about your application shouldn’t be shared with anyone: database passwords, credentials for claiming App Registrations and more. The right answer is to put those secrets in an Azure Key Vault and, in my previous post, Coding Azure 12: Configuring an Azure Key Vault and Adding Secrets, I walked through the process of setting up a Key Vault and storing text strings (“secrets” in the Key Vault world) and certificates in that vault.

Once your Key Vault is created, however, you also want to limit permission to read your Key Vault to only those App Services within your application that need access. That’s the topic of this post.

For the case study I’m using for this series, the applications that need access to my Key Vault are:

• A backend Web Service that needs a Managed Identity id in order to access an Azure database
• A client-side frontend that needs the id for an App Registration that lets the frontend call the Web service
• A server-side frontend that needs the credential to claim its App Registration that lets it call the Web service

Controlling Access to the Key Vault

To control access to your Key Vault in a cloud-native Azure app, you assign your vault a system-assigned Managed Identity and give that Managed Identity the permissions it needs to read secrets from the Key Vault.

You could also use a user-assigned Managed Identity with your App Service and give that identity the permissions it needs to access the fault. However, by default, the App Service will only use a system-assigned identity. So, if you want to use a user-assigned identity, then you must use either an Azure CLI or Powershell command to have your App Service use a user-assigned identity (or embed the Managed Identity’s id in your code). That seems to me like something that would easily be omitted and, as a result, I’m going to use a system-assigned identity.

To have your App Service generate a system-assigned Managed Identity, first surf to your App Service in the Azure Portal and, in the menu on the left, drill down through Settings to select Identity. In the System assigned tab that appears in the page on the right, set the Status toggle to On to activate a system-assigned Managed Identity for your service. Because this identity is system-assigned, you’ll need to repeat this process if you delete and recreate your App Service (unless you use templates, as I described in an earlier post, Coding Azure 11: Recreating and Deploying Azure Resources with ARM and Bicep Templates.

Next, you need to give that new identity the permissions it needs to read items from your vault. To do that, click the Azure role assignments button that appears lower on the Identity page to open a new page. On that page, at the left end of the menu across the top of the page, click the + Add role assignment menu choice to open a panel on the right.

In that panel, from the Scope dropdown list, select Key Vault. Below that, select the appropriate subscription from the Subscription dropdown list (in most cases, this will be the subscription you used with the rest of the resources in this application). From the Resource dropdown list, select your vault (WarehouseMgmtVault, in my case).

From the Role dropdown list, you’ll want to select one of these three roles:

• Key Vault Secrets User: Can read text secrets stored in the vault
• Key Vault Certificate User: Can read certificates stored in the vault
• Key Vault Crypto User: Can use encryption keys stored in the vault to encrypt and decrypt values

For the three cases I’m covering in this post, I’m always reading a secret, so I pick the Key Vault Secrets User role. In a later post, I’ll set up one of my App Registrations to require the application to provide a certificate in order to claim the registration (and the permissions that go with it), so I’ll put off discussing certificates until then. In my case study application, I don’t need to retrieve encryption keys, so I don’t need to assign that permission to any of my case study’s applications.

After picking a role, click the Save button at the bottom of the page to save your choice, close the panel and return to the list of roles you’ve given your App Service (it can take a few minutes for new role assignments to take effect, so don’t panic if a new role assignment doesn’t appear immediately).

Currently, this panel will let you assign roles to the system-assigned identity but won’t let you remove role assignments. If you do add a role that you later want to remove, you’ll need to do that from your vault’s Access Control (IAM) page’s View access page.

Now you’ve configured your App Services to access your Key Vault, either client-side or server-side applications running in that App Service can pull those values from the vault. In my next posts, I’ll show you how to do that.