As a customer I want to be able to restrict user access and rights to Azure Resources that are under the same Azure Subscription.
The requirement can be extended a little more by specifying that a user needs to be able to view and access only Azure Resources that he is allowed. He shall be able to create or modify resources only specific resources.
If possible, all resources that user access or create should be under a predefined subnet.
There are multiple approaches to a request like this. Even if Role-Based Access Control is a powerful mechanism to control access, the way how we can restrict access is limited and doesn't allow us to restrict fully the user as we need.
A classical approach is to allow user to run ARM (Azure Resource Management) scripts only through a custom component that is hosted by us. Having full control on this component we can implement any kind of logic and business restriction. The downside of a solution like this is complexity and cost. In the end is doesn't make sense to reinvent the wheel.
When people are learning about Role-Based Access Control they are focusing on groups and roles and they are forget about a powerful feature of it - Assignable Scope.
By specifying the scope, we can specify that a set of rights are applicable for a user/group/application for only a limited number of resources.
In this moment, the scope allow us to control access at the following granularity:
- Resource Group
For us, the solution is combination of specific role on top of a restricted scope. We need to give to a user access only to a specific resource group.
At the beginning we shall create all resource groups that we need under our subscription. For each resource group we need to create a user group that gives limited access to user under the scope of the resource group. Once this is done we just need to assign to our users the user groups that we want - giving them access to one or more resource groups.
In this moment there is no mechanism to limit access at subnet level. This cannot be enforced directly. By using different VNETs for each resource groups we would have control at network layer also. Even if this could be done easily, it would add an extra-complexity layer that might not be necessary.
Role-Based Access Control in combination with assignable scopes give us the possibility to control user access not only at subscription level, but also at resource group/resource level.
One of the limitation of access control is that we cannot give to user read and management rights to a resource without deletion rights.
The available roles that we have control are Owner, Contributor and Reader. When we create a custom role we have the control to specify a list of actions, but in general deletion and management are combined.