The first post of this series described a solution to use an Azure Managed HSM to wrap secrets stored in an Azure Key Vault. The intent of his design was to comply with a given control that required secrets to be encrypted with keys that were generated in a FIPS 140-2 Level 3 validated HSM. In my excitement to publish the post, I completely neglected to discuss the differences in Role Based Access Control (RBAC) required to interact with the Managed HSM versus the Azure Key Vault. Thanks to KrisTurk86 on Twitter for bringing this to my attention! In this post, I’ll describe why the roles between the two services are different.

From the top, Azure manages access to resources through two planes: control and data. The control plane provides the subscriber to instantiate a resource like a virtual machine, a storage account, a key vault, or an instance of a managed HSM. Once the resource is created, operations against the resource are performed through its respective data plane. The Azure control plane and data plane article is a great read if you’re interested in more detail on this topic.

In the case of Key Vault and Managed HSM, they are managed through two different data planes:

  • https://{vault-name}.vault.azure.net for Key Vault
  • https://{hsm-name}.managedhsm.azure.net for Managed HSM

This means that when you’re interacting with either of these services through the Azure Portal, or through any of the programmatic interfaces, the respective REST API calls to each service are being made against one of these two endpoints. To add complexity to this topic, while the endpoints are different, the API accessible to the caller is the same: Key Vault REST API

I imagine the efficiency in mapping the existing Key Vault REST API to the underlying Managed HSM API was significantly higher by the engineering team during implementation. It also provides them the ability to extend the capabilities of the Managed HSM to more than key objects in the future.

Now, how does authorization fit into this?

Up to this point, we identified that the only difference between the Key Vault and the Managed HSM is the data plane REST API endpoint. How does Microsoft map the caller’s request to the authorization model? Through the Resource Provider operation list of course! This list identifies (in theory - remember this post) all of actions a caller can be evaluated for by the RBAC model against a given resource.

For example, there is no differences in the createKey REST API call for key vault or a managed HSM; they are the same. This aligns with the Microsoft.KeyVault/vaults/keys/create/action permission in the list of actions for the Key Vault API as there is no corresponding action for a Managed HSM target. By design, Microsoft is using the same API, simply with a different resource.

When KrisTurk86 mentioned his findings, and after spending time performing this research, it made sense why the Key Vault Adminstrator role I suggested wouldn’t provide the right access. He discovered that the Managed HSM Crypto User and Managed HSM Crypto Officer roles were the two default roles that contained the permitted actions against the Managed HSM. When reviewing the matrix of the default Managed HSM roles, it helped reinforce the nuance of the RBAC for these two resources that are incredibly similar.

Combining the REST API and Azure RBAC references is incredibly helpful in determining least privilege on the platform. As you build out your environment, it’s easy to use the built in roles to get the job done (as happened to me in the previous post) but to define least privilege and improve your security posture requires a focussed effort.