Part 2: Managing role-based access control (RBAC) access to Azure Key Vault Secrets

Previously, we discussed two specific Azure Key Vault RBAC roles (Key Vault Reader and Key Vault Secrets User roles)and how those two roles apply to the Azure Key Vault resource and individual secret resources. It would be a good idea to review that discussion if you haven’t done so.

In part two, our discussion will focus on the operational aspect of how we manage user access. We know that Azure Administrators are the natural candidates for managing access given they have the role assignment permissions. However, this may not always be the case as they may not really know who should have access. For example, we may want to expose secrets such as passwords to members of the Dev teams. This may be handled by a few DevOps team members who have these specific responsibilities rather than the Subscription Azure Admin.

For the DevOps members, they will need access to configure secrets. There is now a third role which is the Key Vault Administrator role. According to the docs, this role has the ability to “perform all data plane operations on a key vault and all objects in it, including certificates, keys, and secrets”. Now that we understand all the necessary roles, we would want to take a look at the “how”.

If we refer to the docs from Microsoft, the recommended practice is to manage Azure resource access via Azure Active Directory AAD groups. The advantage with AAD Group is that we can assign one or more owners to an AAD group who can then assign members to the group they own themselves. This provides a self-service way and remove Azure Admins from the picture. The Azure Admin then has to assign the AAD group to the appropriate roles on the Azure Key Vault resource and individual secrets.

Let’s review an example implementation. Here, we have created three AAD groups. Based on the AAD group name, you can probably infer we have 2 Applications with secrets, as well as a Azure Key Vault reader group.

The Readers group contains App 1 and App 2 groups.

The “dleekv Readers” group is assigned the role of Key Vault Reader. This means all members of the 2 App specific AAD groups will be able to “list” all secrets.

Individually, each secret can have one or more App groups assigned with the Key Vault Secrets User role.

The result here means owner(s) of AAD group will have able to assign users and those users will have access to their assigned secrets.

My example shows users are assigned the Key Vault Reader role. However, as a reminder, in the first part of this discussion, we also know that we can also simply assign the Key Vault Secrets user role and the user would still be able to view the secret using Azure CLI or other means as long as the user is aware of the secret name and Azure Key Vault name.

There are other means of sharing time limited, just-in-time, or via approval process access via Privilege Identity Management or PIM for short. If you are interested, more information can be found here in the Microsoft docs. For now, I do hope you have enjoyed this reading and learned something new today.