Background
Managing Azure access plans is something I constantly find both newer and more senior developers/admins constantly getting tripped on. It is imperative to understand how the difference access planes in Azure work and why they are structured the way they are. This is important for both administrating/managed and environment as well as it is a frequent test topic on multiple Microsoft Azure exams.
For context this is why even with Azure Owner permissions, one still can’t read Azure Key Vault secrets. Or why Contributors can’t read Cosmos DB data. The most common use case that folks get stumped on is Azure Key Vault, so it is with that in mind we will focus on the difference and why they exist.
Managed Plane
Multiple Azure resources make the difference between a management and a data plan. In traditional IT example is SQL Server. SQL users can be permissions to execute stored procedures, access the master database; however, still not have access to the data that resides in the database. This type of scenario relates to the access available within the management plane.
For Azure Key Vault RBAC roles one can see the difference between which roles explicitly give someone access to read secret values vs maintaining the Key Vault operations.
Data Plane
The Data Plane refers to the ability to read the data, i.e. secrets in this case. The Data plane for Key Vaults, in a well architected Azure environment, should be limited to production, ideally to only application identities, to read secret values stored in a Key Vault.
Wrinkles
The main things that trip individuals up with these concepts is how do Azure RBAC roles scoped at the subscription play into this equation. Majority of the time roles such as owner and contributor are at the management plan, not the data plan. Regularly developers and admin will discover they can’t read secrets in a Key Vault even when hey have owner permissions and immediately think something is wrong. This is inaccurate, in fact it is by design.
If it helps, I always go back to anything that involves the maintaining (updating, permissions, deleting, adding) is a management plan. Anything that can pertains to viewing information or in the case of Key Vault can be used to then turn around and get additional data (i.e. database connection strings, passwords), then this is a data plan access level. When in doubt always, always always, start with the Management Plane permissions first. Then change to data as requested. This is based on the principle of Minimum Required Access. Damage can occur if giving someone read access to the secretes of a Key Vault. They then could get those secrets and do such activities as connect to a database using a password stored in Key Vault.
Conclusion
Just because you have owner/contributor access doesn’t mean you can have access to data. Think, should VM administrators be able to view the SQL data on a database that is running on a VM machine? The answer should be no as they don’t need that access. The same can be said within Azure. Thus, be sure to grant just the minimal required access first.