In this article, let’s quickly try to understand role based access control in Azure.

What is it ?

Cloud provides all the infrastructure for hosting the applications. Not only application’s code, but application’s data is also stored in the cloud.

Hence, any issue causing any problem to deployed code or the application’s data may cause applications to malfunction and may tear down reputations of organizations. Hence, managing access to cloud resources is very critical for any organization.

Azure role based access control (aka Azure RBAC) helps to define

• who can access the resources in cloud
• what operations can they perform on those resources
• what areas of cloud they have access to

What can we do with it ?

Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.

Authorization is very wide topic and many times the authorization model implemented for an organization depends on the nature of applications and business.

If you are new to Azure RBAC, then below are some examples for how Azure RBAC can help:

• If your application uses virtual machines and virtual networks, then you may have one group of users who takes care of managing virtual machines their sizes and accesses, while other group of users may only focus on networking aspects of the solutions and have access to virtual networks in Azure
• If your resources are organized into different resource groups, where each resource group corresponds to dev, test and production, then you can group the users so that developers can have access to dev and test resource groups, while only limited people have access to production environment
• Allow only DBAs to manage SQL databases and database schema, while developers can only access the data

How does it work ?

There are three main concepts in Azure RBAC which are important to understand how the access management is enforced.

Security Principal

Security principal is an object that represents a user, group, service principal or managed identity that is requesting access to Azure resources.

User is an individual who has a profile in Azure Active Directory.  Groups is a set of users in Azure AD. If you assign any role to the group, all the users in that group will get accesses defined by that role.

Service principal is a security principal which is created for applications, so that those applications can access Azure resources.

Managed identity is the identity created in Azure AD and it is automatically managed by Azure.

Role Definition

A role encapsulates a set of permissions. Azure has several built-in roles, some of them are:

• Owner, has full access and also can delegate access to other users
• Contributor, can create and access azure resources, but cannot grant access to others
• Reader, can just view the existing resources
• User Access Administrator, can manage the access to Azure resources

If you feel these built-in roles are not sufficient for your purpose, then custom roles can also be created.

Scope

Scope defines set of resources that the access applies to.

So, when you assign a role to a security principal it defines what level of access is allowed. At the same time, if you assign specific scope, then this scope would decide which set of resources would be accessible to the security principal.

There are below scopes available in Azure and they are organized in parent-child relationship:

• Management Scope
• Subscription
• Resource Groups
• Resources

Role Assignment

Role assignment is the process of attaching a role to a security principal.

Multiple roles can also be assigned to a security principal. If multiple roles are assigned, then the resulting access is union of the roles and scopes.

For ex. if you have reader access on a resource group, but you also have contributor role on subscription level, then the you will have contributor role everywhere in the given subscription. So the reader access does not have any effect in this example.

Similar to role assignment, there is also something called as Deny assignments, which defines the set of permissions which are not allowed to be performed.

Azure RBAC in Action

Below are the steps which may provide you overview of how the Azure RBAC works.

• A security principal acquires token for Azure Resource Manager. This token includes all information about management groups of the principal.
• As and when required, security principal can initiate REST API call to Azure Resource Manager, and token is attached in the request.
• Azure Resource Manager retrieves all role assignments and deny assignments which are associated with the Azure resource in question
• Azure Resource Manager then narrows down the role assignments and deny assignments, which apply to the current security principal
• Azure Resource Manager then decides if the current security principal is allowed to perform the concerned action
• Azure Resource Manager first checks role assignments. If the role assignment does not allow the action, then REST API request is denied.
• Next, Azure Resource Manager checks deny assignments. If the deny assignments does not allow access, the access is denied.
• Otherwise access to resource is granted.

Pricing

Azure RBAC feature is free and included in the Azure subscription.

I have tried to cover all basic information about Azure RBAC in this article. I hope you enjoyed it. Let me know your thoughts.