Azure Role-Based Access Control (RBAC)

In our previous post, you were introduced to the basic concepts of cloud and also given a brief understanding about one of the most popular cloud service providers - Microsoft Azure. In this post and the subsequent posts, we are going to deep dive into Azure and understand some of its core features and services.

Suppose the IT infrastructure of your organization has been already hosted in Azure, the next important aspect of your infrastructure is to determine who gets to access what and how do I seamlessly implement it in Azure. This is where Azure Role-Based Access Control (RBAC), an in-built feature of Azure and our topic for today comes in handy. We are going to explain in detail what is Azure RBAC and how it helps in managing the access controls for your Azure services.

Table of Contents

1. What is Azure RBAC
2. Key concepts of RBAC
3. Role assignments
4. Practical implementation of RBAC
5. Final Thoughts

1. What is Azure RBAC?

Azure RBAC is a built-in authorization system that helps in access management of Azure resources. Generally, RBAC is used for restricting network access based on the roles of individuals within an organization. It lets users have access to the information that is required to complete their job and restrict them from accessing information that does not pertain to them.

Now that we have defined what RBAC is, let us understand a few basic Azure terminologies which we will use throughout our post.

1.1 Azure Subscription

Azure subscription is a logical bundle of Azure resources, which serves as a single billing unit for the resources that are present in that service. An Azure subscription can be mapped to only one account. However, an account can have multiple subscriptions.

1.2 Resource providers

Resource Providers typically provide the resources that can be used within a subscription. They also describe the applicable actions for each resource. Most of the resource providers are automatically registered to the subscription. If not, users can register them when required.

1.3 Resource group

A resource group is a central unit for the collection of resources that can be treated as one entity. It helps in automatic provisioning, monitoring, and helps in controlling all the resource members collectively.

2. Key concepts of RBAC

The below forms the three main concepts of RBAC.

2.1 Security Principal (Who needs access)

It refers to the entity that requires access to the Azure resource. The entity could be a:

• User (Person who has a profile in Azure Active Directory)
• Group (Set of users who are clubbed in Azure Active Directory)
• Service Principals (Represents the identities used by Azure service or application to access Azure resources)
• Managed Identity (Allow an Azure resource to identify itself to Azure Active Directory without requiring it to provide any explicit credentials)

2.2 Scope (What to access)

Once we have decided who needs to access the resources, the next step is to figure out what needs to be accessed by them.

Scope provides which resource or the group of resources to which the Security principals have access to. For example, access to App services that are in a particular resource group.

In Azure, the scope can be defined as the following:

1. Management Group,
2. Subscription,
3. Resource Group, and
4. Resource

Let us understand the above with an example.

Suppose we deploy our solutions in Development (Dev), Quality Assurance (QA), Staging, and Production regions. Now, they want to figure out the cost incurred in maintaining each region, so they can create subscriptions at region level i.e 4 subscriptions for 4 regions.

To maintain the access, policy, and compliance across subscriptions, the scope will be defined at the Management group (group of subscriptions) level. Similarly, to maintain the same set of policies within a subscription, the scope will be defined at the Subscription level. The same is the case with resource groups and resources.

2.3 Role Definition (How to access)

Role definition is a collection of permission/action that a security principal will be able to perform on the defined scope. In other words, Role definition determines the type of operations (read, write, and delete) that can be done by the security principal.

Azure has close to 140+ in-built roles. However, the four fundamental built-in roles are as follows:

1. Owner (Security principal with full access to the Scope with the right to delegate access to others),
2. Contributor (Has all the privileges similar to the role ‘Owner’. But, they cannot delegate access to others),
3. Reader (Can view the existing azure resources),
4. User Access Administrator (Allows to manage user access to manage resources).

Azure allows us to create custom roles, which could come in handy when the built-in roles are not suitable or specific to the organization's needs.

3. Role assignments

RBAC is all about roles. And to implement RBAC, role assignments have to be created. Role assignments are nothing but a process where you define a role to a security principal for a particular scope. Access can be granted or revoked by creating or removing a role assignment.

Azure also enables you to have multiple role assignments. An important point to note here is that in multiple role assignments, the highest privilege available across the role assignments is taken into consideration and the effect of the lower privilege role is nullified.

For Example:

• Role assignment 1 - Contributor role is assigned to a Subscription for a user.
• Role assignment 2 - Reader role is assigned to a resource present in the subscription for the same user.

In this case, the higher privilege of the contributor is applied across the subscription for the user, which nullifies the effect of the reader role. Similarly, to have an exclusion on a set of actions to be performed by the security principal on the defined scope, Azure offers deny assignments. Deny assignments prevent the security principal from performing certain actions even if there is a role assignment to grant access for it. In short, Deny assignments take preceding over Role assignments.

Let us consider an example, a developer has access across all the regions (Management groups) to update or modify all resources (Role assignment). However, in the Production region (one of the subscriptions), a rule (deny assignment) is set which will not allow the developer to update any resources in that subscription.

4. Practical implementation of RBAC

Say we start to build our infrastructure in the cloud and have recruited candidates for the following roles: Cloud Architect, Database Administrator, Developers, Testers, and Product Owners. Let's see how RBAC helps us to work effectively.

Cloud Architect - Person or group of persons who are in charge of cloud adoption plans, cloud application design as well as cloud management and monitoring. It is the responsibility of cloud architects to provide the standards to be followed and best practices to be adopted in the cloud system. So, we use RBAC to ensure that the Cloud Architect has access across all the subscriptions with a privilege to do Create, Read, Update, and Delete (CRUD) resources.

Database Administrator - A specific set of groups who work on the databases that are deployed across all the subscriptions. So, we use RBAC to offer contributor access to database administrators only to the databases that are deployed across the subscriptions.

Developers – In the case of developers, we use RBAC to ensure that the scope is restricted only to their regions of work (could be one subscription or a resource group) with a privilege to do the CRUD operations.

Testers and product owners - We use RBAC to offer Reader privilege to Testers and Product Owners for their required scope.

Thus, Azure helps organizations in defining the roles for the individuals or a group who contribute to the system.

5. Final Thoughts

Access management is an important part of cloud governance and it should be given utmost priority. It helps in defining a set of rules to guide the organization in utilizing and controlling the cloud resources to adhere to the industrial standards of data security. Implementing the right level of RBAC helps in achieving secure Azure environments and independent security principals.