Skip to main content

Control Azure Users Access using Role-Based Access Control

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.

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. 

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.


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 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 …

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…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.