Coding Azure 12: Configuring an Azure Key Vault and Adding Secrets

Your organization has secrets that they don’t want even you to know—but that your application does. Azure Key Vaults can make both you and your organization happy, so here’s how to set one up.

In previous posts, the code I’ve shown for building a secure cloud-native application in Azure that has included user Ids for impersonating Managed Identities and credentials for claiming App Registrations, among other pieces of confidential information that I don’t want to share with everyone who can check out my code (and, quite frankly, that my employer would prefer not to share even with me).

The appropriate place to put anything you want to keep secret is in an Azure Key Vault. Azure provides two types of vaults for you to use: the default/standard Key Vault and the more secure (and more expensive) hardware-protected Managed HSMs vaults. For this post, I’m just going to use the standard Key Vault.

The name “Key Vault” refers to the key-value pairs that Key Vaults use for storing items (text, certificates and—confusingly from a naming point of view—encryption keys). Once you’ve added a key-value item to a Key Vault, the only thing you have to embed into your application is the key tied to the now secret value. Now, anyone who views your code only sees the key used to retrieve the item in the vault and not the secret itself.

Creating a Key Vault

Obviously, to take advantage of this feature, you first need to create a Key Vault. The only things you want to be able to access your secrets are the components of your application. However, since any person or thing that has access to a vault pretty much has access to all the secrets in your vault, you should assume that you’ll need to create a separate Key Vault for each application (or even each microservice) you create.

The Basics

To create a Key Vault, start by entering Key Vault in the search textbox at the top of the Azure Portal page and select Key Vaults when it appears in the dropdown list. On the Key Vaults page, at the left end of the menu across the top of the page, click the + Create menu choice to start the Create a Key Vault wizard.

On the first page of the wizard, you’ll need to assign your Key Vault to a subscription, a region and a resource group. For my case study, I put the Key Vault in the same subscription, region (Canada Central) and resource group (WarehouseMgmt) as the other resources in my application.

You’ll also need to give your vault a name—this name ends up being part of a URL so you can’t use spaces or other URL-unfriendly characters in the name (the page will let you use upper- and lower-case letters in the name, though). I used WarehouseMgmtVault for my vault’s name.

Pricing

Your next choice is pricing and, for a Key Vault, you have only two choices: standard or premium. Premium pricing gives you access to hardware-protected keys (not the same thing as a hardware-protected vault) and higher levels of encryption for your stored secrets, all at a higher cost. Being both cheap and confident that no one is interested in my case study, I picked standard pricing and the default encryption.

Retention

Next, you’ll need to set your vault’s protection against accidental deletes. At the Key Vault level, you can keep deleted Key Vaults around for a specified number of days after they’re deleted. You can’t completely disable this: The minimum number of days is seven and the maximum is 90 (the default). Since my vault for my case study is small (I’ll be storing two keys and, eventually, a certificate), seldom accessed and will probably never be deleted anyway, I took the default 90 days.

On top of that “whole vault” protection level, you also have deletion protection at the key level. With a Key Vault, you don’t actually delete keys—you just replace the current key with a new version. Any previous version of the key is kept around for the vault’s protection period, unless you purge older versions. This versioning allows you to audit any changes to your keys (i.e., someone changing a key to a new value and then changing it back to the original value after doing something nefarious).

If you want, you can prevent any key from being purged by turning purge protection on (if you turn this on, you can’t turn it off). Effectively, this means that you won’t be able to completely erase any key until the last deleted version reaches the end of your delete period. In development, where you’ll probably try out a variety of keys before settling on the ones you need, I would turn purge protection Off so that you don’t have to keep any key you decide you won’t need through the end of your purge period. I would, however, turn On purge protection for any key vault used in production (and you might decide to have it On in both environments).

Finally, by default, you have quite a lot of protection against losing your vault. Your vault has both failover protection within your region and, in almost every region, failover protection to your region’s paired region (the exceptions are those regions that don’t have a paired region—currently that includes Brazil and West US 3, for example). You can give yourself additional protection by downloading individual items to local storage.

Controlling Access

Once you’ve filled out the first page of your wizard, clicking the Next button at the bottom of page will take you to the vault’s Access configuration tab. Leaving the Permission model on Azure role-based access will let you use Managed Identities to control access to the items in the vault (which is what I chose).

I skipped to the end of the wizard at this point by clicking the Review + create button at the bottom of the page. On that last page, clicking the Create button will create your vault.

Adding Items

Your next step is to add one or more items to your vault. Before you can do that, you’ll need to assign the Key Vault Administrator role to some user so that someone has the ability to add/remove/change items in the vault (the person who creates the vault is not granted this permission by default).

That person can be you in development but, in production, it’s important that whoever is managing vault items is not someone who either accesses those items or grants permission to access those items. This is just “Banking Fraud Protection 101”—every activity should involve two people. The person authorized to create items in the vault, for example, should not be a person authorized to use those items to access company data.

I’ll cover adding and retrieving certificates in a later post and just cover adding confidential text in this post. Text values are what Key Vault calls a “secret”—a password, client id or any text that you don’t want to embed in your code—and you add them like this:

1. In your Key Vault’s menu on the left, drill down through Objects and select the Secrets node to open the list of secrets in the vault on the right.
2. At the left end of the menu across the top of the new page, click on the + Generate/Import choice to open a new page.
3. In the new page, leave the Upload options dropdown list at the top of the page set to Manual.
4. In the Name textbox below that dropdown, enter the name of your secret. This name needs to be URL-friendly (i.e., no spaces or URL-unfriendly punctuation marks—I used DbAccessIdentity).
5. In the Secret value textbox below that, enter the value of your secret (I copied and pasted the user id of the Managed Identity that provides access to my Azure SQL database)
6. In the Content type textbox, you can, optionally, include some indication of the type of data that you’re storing in the secret value. This acts as a hint for code reading the secret to help parse your secret (for example, if your secret value is a JSON document, you might put “json” in this textbox). I left it blank.
7. Optionally, you can also set a “not available before date” (called “activation date”) or a “not available after date” (called “expiration date”), or disable the secret from being used at all.

Next Steps

One piece of advice: Many of the ways for accessing keys in the Key Vault allow you to use a prefix for your key values. The most common use case for using prefixes is to distinguish between secrets used in your test system vs. secrets used in your production system (e.g., “100-DbAccessIdentity” for holding the test value and “200-DbAccessIdentity” to hold your production value).

The issue here for me is that the more people who have access to any particular Key Vault, the more likely it is that the secrets in that vault will be comprised. In the same way that you should probably set up separate Key Vaults for each project, it’s probably a good idea to have separate Key Vaults for your development system (managed by developers) and your production system (managed by your Ops team or system administrators). You might also leverage that to use a standard price Key Vault in development and the more expensive HSM, premium priced Key Vault in production.

However, in this series, I’m only interested in how to use my vault’s confidential information in my application. In my next posts I’ll cover how to allow only your application to access your Key Vault and how your server-side and client-side applications can access both secrets and certificates.