Photo by Jornada Produtora on Unsplash
Azure Key Vault Access Policy vs RBAC
2 min read
Applying the RBAC permission model to protect 🔐 your Azure Key Vault objects should be used in favor of the access policy option.
The vault access policy is applied at the Key Vault scope. Meaning if you had a dozen secrets in your vault, then you're essentially allowing everyone privileges in the policy access to all of those secrets. A workaround to this is to create a separate key vault for each key vault object, applying a policy on each vault. This creates config and permissions management overhead 😣
Alternatively, if you use the RBAC model, then there's no need for a policy. The majority of RBAC roles are applied at either the control or management planes in Azure. However, there are several data plane built-in roles available for the key vault such as the "Key Vault Crypto User" which allows the 'list' of keys 🔑 or the "Key Vault Secrets User" allowing you to 'get' and 'list' secrets. These RBAC controls can be applied at the entire vault scope or on a per-vault object basis thus securing access to each of your keys/secrets/certificates within the vault. This allows for much more granular permissions, decreases config overhead and provides a higher level of protection for your ☁️ assets.
Do you agree? What authorization method works best for you? I'd love to hear your opinion about this. Let me know in the comments!