Skip to main content

Control Azure Users Access using Role-Based Access Control

Problem
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.

Options
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.

Ideal solution
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:
  • Subscription
  • Resource Group
  • Resource
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. 

Conclusion
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.

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too