- Manage Azure PowerShell global settings - Fri, Sep 22 2023
- Create and manage append blobs with PowerShell - Wed, Oct 12 2022
- Permanently delete a Key Vault in Azure using PowerShell - Fri, Feb 4 2022
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 Vaults | Actions |
| Key Vault Administrator | Can perform all data operations |
| Key Vault Certificates Officer | Can perform any action on the certificates of a key vault but cannot manage permissions |
| Key Vault Crypto Officer | Can perform any action on the keys of a key vault but cannot manage permissions |
| Key Vault Crypto Service Encryption User | Can perform wrap/unwrap operations on keys |
| Key Vault Crypto User | Can perform cryptographic operations on keys |
| Key Vault Reader | Can 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 Officer | Can perform any action on the secrets of a key vault but cannot manage permissions |
| Key Vault Secrets User | Can 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
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
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
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
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
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
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
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
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
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
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
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.
