Let's create a key vault through the Azure portal. If you have the key vaults icon on the Azure services ribbon at the top of the page, click that, or type key vault into the search bar. I have no vaults, so I'll click the create key vault button in the middle of the page, but you can add additional key vaults by clicking the create button on the top left. The creation process starts the same as with most resources by selecting or creating a resource group and selecting an Azure region. I use the existing resource group KeyVault_RG and stick with the East US region.

The Key vault name has to be universally unique within the vault.azure.net domain, as it forms an endpoint URL used by apps and services that access the vault's keys, secrets, and certificates via APIs.

I'll stick with the standard pricing tier, but if you need to support hardware security module backed keys, select the premium tier.

Soft delete is no longer an option, as in it's enabled by default. Soft delete means vaults or vault resources are hidden rather than permanently erased when deleted. Vault data is, by nature, critical, so you want to protect it against accidental or malicious deletion. This is particularly important in the case of encryption keys, as losing the key is the same as losing the data it encrypts.

Next, we have the days to retain a deleted key vault before it is permanently erased, meaning after the specified number of days, the deleted vault will automatically be permanently deleted. Purge protection, when disabled, overrides the soft delete functionality allowing you manually and permanently delete a soft-deleted vault. While we're on the subject, let's look at the purging process. Using the magic of video time travel, let's look at permanently deleting a vault I previously created. Go to the key vaults' home page and click manage deleted vaults. On the manage deleted key vaults blade select the subscription associated with the vaults you want to delete. I have two soft deleted vaults. After selecting at least one vault, you can either recover or permanently delete it. I'll purge both of the key vaults. Naturally, you'll have to confirm the purge. Ok, back to creating a vault. 

Click next to set up the access policy. You can configure vault permissions using vault access policies or Azure's role-based access control. Vault access policy is the default, and I'm listed as the user principal at the bottom under access policies with key, secret, and certificate permissions. You can add access policies for other users at this stage with the create access policy button. Selecting Azure RBAC as a permission model will remove access policies. 

You can grant access to virtual machines, resource manager, and Azure disk encryption here. These are common consumers of key vault resources. Virtual machines use certificates to verify themselves as legitimate, disk encryption uses keys to encrypt and decrypt disks, and Azure resource manager can pull secrets from the key vault to integrate into template deployments.

Next is networking, but there is nothing key vault specific on this page, and I'm going to go with the defaults of enable public access and allow access from all networks. Click next to set up any billing tags and then next again for review and create. Ok, that's what I set up, so let's create the key vault.

Now that's finished, let's go to the vault. Let's look more closely at access policies. Here we have the user that created the vault. Selecting the user and clicking edit shows us precisely what the user can and can't do. You'd think as the vault creator all the permission boxes would be checked. But on closer inspection, we can see operations performed solely in the data plane, i.e., ones that a human user wouldn't perform, like cryptographic operations, are unchecked. I'm not going to save changes to my access policy permissions. Under access control, RBAC, there are key vault-specific predefined roles. When we drill into a key vault role, the typical permissions are listed under actions. 

Data actions detail certificate and key-specific actions. Take note – these roles and permissions only work if the vault has been set up using RBAC. I set this vault using access policies. If you want to change a vault from policy to RBAC access, you can do it under access configuration. Changing a vault's access method is not a trivial task and should be well-planned, taking into account all resources and users accessing the vault.

You can create an Azure key vault via PowerShell with the New-AzKeyVault command specifying a vault name, resource group, and location. Compared to creating a vault through the portal, it will come as no surprise that such a minimal set of parameters leaves us with a few loose ends, like no access policy. Now we could go into the portal and set up the policy, but let's use the Set-AzKeyVaultAccessPolicy command. The parameters are the vault name, user principal name, and the permissions to set. 

The permissions parameters are in the form of permissions to, followed by the permissions target. So permissions to keys, permissions to secrets, permissions to certificates, and permissions to storage. Passthru returns an object the command worked on, but this command just returns confirmation text. The permissions themselves are self-explanatory text, like create, list, set, and delete. Back in the portal, we can see the newly added access policy.

Microsoft has recently introduced full RBAC permissions control to Azure Key Vault. We saw that option when creating the first key vault. The main issue with controlling access to vault resources with access policies is the lack of granularity. For example, when you grant read access to secrets, it's to all secrets. There is no way to restrict access to a subset of secrets without creating another vault for those secrets. RBAC lets you set access permissions per resource. 

I've created another vault using RBAC with two secrets, and I only want a user to see one of them. First, I'll assign the Key Vault Reader role, which can read vault metadata but not vault resources values, to the user hallamsql. I'll switch browser tabs to the hallamsql user, who doesn't have permission to view the RBAC vault. Once the role has been put into effect, hallamsql can see the vault, but as expected, can't see the secrets' values. Going back to me as the key vault admin user, I'll assign the key vault secrets user role to hallamsql on the ABitSecret resource. Again, after waiting for the role to take effect, hallamsql can view the secret's value. The hallamsql user still cannot read the MoreSecret resource, which is correct.