Azure Key Vaults are essential components for storing sensitive information such as passwords, certificates, and secrets of any kind. Because the data stored in Key Vaults is sensitive, only authorized users or applications should be able to access them. At that point, we have two options to manage access control: traditional vault access policies and new role-based access control (RBAC). In this post, we will be looking at the new RBAC model on Azure Key Vaults and how we can manage access with RBAC using PowerShell.

Vault access policies vs. RBAC permission model ^

Previously, the biggest downside of managing Key Vault access was the need to configure two things to give someone access to secrets, keys, or certificates in a particular Key Vault. First, we had to grant permissions on the Key Vault resource in Azure using access control (IAM); then we had to create a separate access policy in the Key Vault granting the user the appropriate permissions on objects such as keys, secrets, and certificates.

This model does not give us granular access management on individual secrets, certificates, or keys. This means that when someone has Read access on secrets specified in a Key Vault access policy, they can access all the secrets in that Key Vault.

With the new Azure RBAC permission model, we can now control each object independently by managing object-level permissions using the following new RBAC roles. These built-in roles can only be used with the new RBAC permission model.

New Built-in Roles for Key VaultsActions
Key Vault AdministratorCan perform all data operations
Key Vault Certificates OfficerCan perform any action on the certificates of a key vault but cannot manage permissions
Key Vault Crypto OfficerCan perform any action on the keys of a key vault but cannot manage permissions
Key Vault Crypto Service Encryption UserCan perform wrap/unwrap operations on keys
Key Vault Crypto UserCan perform cryptographic operations on keys
Key Vault ReaderCan read key vaults metadata and get object information on certificates, keys, and secrets such as listing but cannotread any sensitive data on secrets, keys, or certificates
Key Vault Secrets OfficerCan perform any action on the secrets of a key vault but cannot manage permissions
Key Vault Secrets UserCan read secret data

Creating a new Key Vault with the RBAC permission model ^

We will be using the following command to create a new Key Vault with the RBAC permission model. There is a new parameter, EnableRbacAuthorization, which configures the Key Vault to use RBAC authorization instead of traditional vault access policies.

New-AzKeyVault -Name TheNewKeyVault002 -ResourceGroupName KeyVaults -Location "East US" -EnableRbacAuthorization
Creating a new Key Vault using the EnableRbacAuthorization parameter

Creating a new Key Vault using the EnableRbacAuthorization parameter

Once created, we can see that the permission model is set as "Azure role-based access control," and creating an individual access policy is no longer allowed.

Azure role based access control as the permission model

Azure role based access control as the permission model

Updating an existing Key Vault to use the RBAC permission model

We can also update an existing key vault to use the RBAC permission model using the following PowerShell command:

Update-AzKeyVault -Name TheNewKeyVault001 -ResourceGroupName KeyVaults -EnableRbacAuthorization $true

To change RBAC permissions, we need the Microsoft.Authorization/roleAssignments/write permission, which automatically comes with the Owner and User Access Administrator roles.

Although we can update the permission model on a Key Vault, creating a new Key Vault with the RBAC permission model is still the best practice; since the current access policies on the Key Vault will no longer be used, this may result in permission issues. When you manually change the permission model on a Key Vault in Azure Portal, you get the following warning highlighting that the existing users and applications that are currently allowed access will be affected.

Warning on updating the permission model

Warning on updating the permission model

Assigning users permissions on individual secrets, keys, or certificates

Now, let's create a new Key Vault secret with the below.

Set-AzKeyVaultSecret -VaultName TheNewKeyVault001 -Name SuperSecret -SecretValue ("NotSecretAnymore" | ConvertTo-SecureString -AsPlainText -Force)
Creating a new secret in a Key Vault

Creating a new secret in a Key Vault

We can now assign a user an appropriate Key Vault role on that specific secret. First, to get the built-in Key Vault roles, we can use the following:

Get-AzRoleDefinition | where{$_.name -like "*key vault*"} | ft name, id
Listing built in Key Vault Roles in Azure

Listing built in Key Vault Roles in Azure

To assign the user the "Key Vault Administrator" role on the secret "SuperSecret," we will run the next command. "ObjectID" in the following command represents the object ID of the user, which can easily be found in the user properties in Azure AD.

New-AzRoleAssignment -Scope "/subscriptions/xxxxxxxx-xxxx-48fe-a058-00xxxxxxxxxx/resourceGroups/KeyVaults/providers/Microsoft.KeyVault/vaults/TheNewKeyVault001/secrets/SuperSecret" -ObjectId "0bdd72be-8e01-4357-8bdc-2d9969e800b6" -RoleDefinitionName "Key Vault Administrator"
Creating a new role assignment on an individual secret

Creating a new role assignment on an individual secret

So, the user is now on the access list of the individual secret, "SuperSecret," with the "Key Vault Administrator" role.

Access control list of a secret

Access control list of a secret

Now, the user "test@towershell.com" should be able to access the secret. If the user does not have at least "Key Vault Reader" access on the Key Vault itself, then the user will not be allowed to list the secrets in the Key Vault but will still be able to access the secret directly using PowerShell. This is because the role assignment is made on the secret object and not on the entire Key Vault.

$secret = Get-AzKeyVaultSecret -VaultName TheNewKeyVault001 -Name supersecret
$ssPtr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secret.SecretValue)
$secretValueText = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($ssPtr)
$secretValueText
Accessing a Key Vault secret using PowerShell

Accessing a Key Vault secret using PowerShell

Now let's use another secret named "AnotherSuperSecret," but this time the user that has been allowed access on the first secret will not have permission on this one.

Trying to access a secret without permission

Trying to access a secret without permission

As expected, the user cannot access the second secret, as no permissions are allowed.

Similarly, we can do the same on keys and certificates by assigning users with the appropriate roles on a specific key or certificate using the correct scope.

To assign a user the "Key Vault Certificates Officer" role on a specific certificate, we can use the following:

New-AzRoleAssignment -Scope "/subscriptions/ xxxxxxxx-xxxx-48fe-a058-00xxxxxxxxxx /resourceGroups/KeyVaults/providers/Microsoft.KeyVault/vaults/TheNewKeyVault001/certificates/TestCertificate" -ObjectId "0bdd72be-8e01-4357-8bdc-2d9969e800b6" -RoleDefinitionName "Key Vault Administrator"
A new role assignment on an individual certificate

A new role assignment on an individual certificate

And to assign a user the "Key Vault Certificates Officer" role on a specific key, we can use this:

Subscribe to 4sysops newsletter!

New-AzRoleAssignment -Scope "/subscriptions/ xxxxxxxx-xxxx-48fe-a058-00xxxxxxxxxx /resourceGroups/KeyVaults/providers/Microsoft.KeyVault/vaults/TheNewKeyVault001/keys/NewKey1" -ObjectId "0bdd72be-8e01-4357-8bdc-2d9969e800b6" -RoleDefinitionName " Key Vault Crypto Officer"
A new role assignment on an individual key

A new role assignment on an individual key

Conclusion ^

Key Vaults are essential and need to be secured as much as possible by implementing strong permission management. Azure now allows us to use the new RBAC permission model to assign permissions granularly and flexibly to users or applications with new built-in roles on individual secrets, certificates, or keys.

+2
avatar
0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account