Recently a customer expressed concern that an owner of an Azure resource group automatically gains access to the data within the services contained in the resource group. In this case, the customer was specifically referring to data in Azure Data Lake Storage Gen 1 but this concept applies to Azure Storage and some of the other data-oriented services in Azure as well. The customer’s comment prompted me to look into available alternatives. This is by no means a detailed security post…rather, I’m trying to share a few nuggets of what I learned.
Key points to take away from this post:
The built-in Owner role is, by design, unrestricted for both management operations as well as data operations. *See option 3 below where it looks like this behavior is changing.*
You cannot 'break' the inheritance model of resources in Azure.
If resource group owners are not allowed to see data, these are the following choices I’m aware of currently:
Remove owner permissions from the resource group level, or
Isolate the resource into its own resource group so it can be managed separately, or
Investigate using the new "DataActions" and "NotDataActions" properties within RBAC role structure to separate management operations from data operations (currently in preview at the time of this writing)
Default Behavior of an Owner in a Resource Group Allows Access to Data
Let's first cover what happens by default. Say I have a resource group with a way cool name of "SecurityTestRG" and I've granted "Wayne Writer" ownership permissions to the resource group. And within the resource group I have a storage account called "strgtest96." As we'd expect, the owner permissions are inherited by the storage account:
And with that, Wayne Writer is able to view, edit, and delete any of the data that has been uploaded to that storage account by virtue of his owner permissions at the resource group level:
Allowing owners unrestricted access to both the management plane and the data plane is by design. However, if you have a group of people who should be able to administer (own) everything contained in the resource group, but you don’t want them to automatically see all the data, what are the options?
Cannot Break the RBAC Inheritance Model in Azure
The first thing you might be inclined to try is to just remove the owner permission for the one resource within the resource group that has data, so that you can specify security for it differently. However, that doesn’t work:
When you try to delete a role assignment that’s been inherited, as shown above, you get an error message: “Inherited role assignments cannot be removed. Please open up the associated resource and remove the role assignments from there.”
In Azure’s RBAC model, we can add additional permissions at lower levels (i.e., like for a resource itself within the resource group), but we cannot remove an assignment that’s been inherited.
An additional note about subscription level owners & administrators: Any owner you specify at the subscription level will be inherited by all resource groups and resources across the subscription—it’s a very high privilege role. The same inheritance behavior also applies to the Azure service administrator (but not the other co-administrators—they would have to be specified as subscription owners).
Options for Handling Security Differently
Option 1. You could remove the owner permission from the resource group (that is the suggestion presented within the error message shown above). However, let’s say there are 10 resources in this resource group and the other 9 of them can inherit the owner permission without issue. In that case, do we really want to have to manage security for every single resource separately? That might introduce risk and inconsistency. Though if there aren’t very many resources within a resource group, that might work ok.
Option 2. You could isolate the resource into its own ‘sensitive’ resource group so it can be managed separately. This allows the other 9 resources to stay in the main resource group with normal RBAC, and just segregates this one resource. Depending on how you handle automation and deployments, having separate resource groups could add complications (because the general rule for resource groups is to group resources together that are related & have the same lifecycle). Also, it still precludes you from being able to own the resource yet not see data—this segregation would work if contributor or a custom role meets your needs, and if you don’t have subscription-level owners specified which also inherit no matter what.
Option 3. There is new functionality in preview that looks promising which will allow us to handle security for management operations and data operations separately, as shown here:
The above scenario indicates that Alice, a high level owner, doesn’t actually see the data. This is still in preview and I haven’t gotten it to work correctly yet, but I’m keeping an eye on this. You can find more info here: https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions. I’m guessing this security enhancement is inspired by GDPR and/or customer needs for more granularity of permissions, so I’m excited to see where this is headed.
Finding More Information
Azure Storage Security Guide <—This is a good read re: management plane and data plane