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

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.51EF 6.0.2VS2013
It seems that there …

Fundamental Books of a Software Engineer (version 2018)

More then six years ago I wrote a blog post about fundamental books that any software engineer (developer) should read. Now it is an excellent time to update this list with new entries.

There are 5 different categories of books, that represent the recommended path. For example, you start with Coding books, after that, you read books about Programming, Design and so on.
There are some books about C++ that I recommend not because you shall know C++, only because the concepts that you can learn from it.

Coding

Writing solid codeCode completeProgramming Pearls, more programming pearls(recommended)[NEW] Introduction to Algorithms

Programming

Refactoring (M. Fowler)Pragmatic ProgrammerClean code[NEW] Software Engineering: A Practitioner's Approach[NEW] The Mythical Man-Month[NEW] The Art of Computer Programming

Design

Applying UML and Patterns (GRASP patterns)C++ coding standards (Sutter, Alexandrescu)The C++ programming language (Stroustrup, Part IV)Object-oriented programming (Peter Coad)P…

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…