My last post ended with a promise to explain the management plane vs. data plane split in practical terms. The short story? There are two separate permission systems — one for managing resources, one for accessing data — and they don't talk to each other. The good news: you already understand this model. You just don't recognize it yet.
The Pattern You Already Know
In SQL Server, we have server-level permissions and database-level permissions. A login can exist at the server level but have zero access to any database. A user can exist in a database but not map to any login. They are separate layers, and you need both configured correctly for anyone to be able to do anything.
Cloud works the same way — just with different names and a portal that hides all the pieces.
| SQL Server | Cloud Equivalent | What It Controls |
|---|---|---|
| Server-level | Management plane | Can you see it? Configure it? |
| Database-level | Data plane | Can you use it? Read/write data? |
When someone says 'I have Contributor access but can't read the blob' — that's like having a SQL Server login with no database user mapped. You can connect to the instance, but you can't touch the data. Different layer, same pattern.
Why the Naming Hurts
The problem isn't the model. The problem is the names.
In SQL Server, db_datareader lets you read data. db_datawriter lets you write data. These names make sense. In Azure, Contributor sounds like it should let you contribute... something. Maybe data? Nope. It lets you contribute configuration changes to the resource. Want to contribute actual data? You need Storage Blob Data Contributor.
Here's the mental model that helped me:
Management plane roles answer: 'What can you do to this resource?'
Create it, delete it, configure it, see it in the portal, change its settings.
Data plane roles answer: 'What can you do with this resource?'
Read files, write data, execute queries, upload documents.
The Practical Combinations
Let's get specific. For Azure Blob Storage — the scenario from my last post — here's what each combination actually gets you:
| ARM Role | Data Role | Result |
|---|---|---|
| Reader | none | Can see storage account in portal, no data access |
| none | Storage Blob Data Contributor | Can read/write via CLI or API, invisible in portal |
| Reader | Storage Blob Data Reader | Can see in portal, read-only data access |
| Reader | Storage Blob Data Contributor | Can see in portal, full data access |
| Contributor | none | Can configure storage account, no data access |
| Contributor | Storage Blob Data Contributor | Full configuration + full data access |
Notice the pattern: Reader + Storage Blob Data Contributor is often the sweet spot for end users. They can find the resource and work with the data, but they can't accidentally reconfigure or delete the storage account itself.
Azure SQL Has the Same Split
This isn't just a storage thing. Azure SQL Database has the same model:
| Layer | Role Example | What It Does |
|---|---|---|
| Management | SQL DB Contributor | Manage servers/databases in portal, firewall rules, scaling |
| Data | Entra ID user + db role | Connect and run queries, read/write data |
A user with SQL DB Contributor can manage databases in the portal — change performance tiers, adjust backup retention — but if they're not added as a user inside the database, they can't run SELECT * FROM Customers. Same pattern. Management vs Data.
The Five-Second Diagnostic
When someone says "I have the right permissions but I'm getting Access Denied", ask two questions:
1. Can they see the resource in the portal?
No → Missing management plane role (ie., Reader)
2. Can they see it but not use it?
Yes → Missing data plane role (ie., Storage Blob Data Contributor)
No comments:
Post a Comment