Maintaining security in a cloud infrastructure is hard, especially when too many people are accessing it – your architects, engineers, administrators, support engineers, etc. However, not all of them would require the same level of access.
Here is where Azure takes a step ahead by providing access management services like RBAC & ABAC, permitting access based on job roles and other relevant factors.
What is Azure RBAC and its benefits?
Role-based access control (RBAC) is an authorization system to achieve secured access management to Azure resources. Organizations often adopt Azure RBAC to provide their employees with different levels of access based on their roles. It protects sensitive data and ensures they can only access information and resources required to do their jobs.
For instance, an engineer/developer will need a higher permission level than an administrator since they are responsible for designing and developing Azure applications.
So, to be precise, Azure RBAC allows you to
- Define & manage multiple accesses to Azure resources
- Know the specific areas that different roles assigned have access to
- Quickly discover what other roles can do with your resources (Create, update, read or delete)
How does Azure RBAC work?
With RBAC, you can restrict resource access by creating role assignments, which involve assigning role definitions to security principals at a particular scope.
Security principals: It represents a user, group, service principal, or managed identity that can be assigned to a role.
Role definition: It’s a collection of actions that the assigned identity can perform.
Currently, we have got around 60+ in-built roles in Azure that can be assigned to users and four fundamental ones which can be used right away,
|Fundamental roles||Access level|
|Contributor||Has full access to Azure resources; cannot assign roles in RBAC|
|Owner||Manages all resources, including the ability to assign roles in Azure RBAC|
|Reader||It allows you to view all resources but not modify them|
|User Access Administrator||Manages only the user access to Azure resources|
It doesn’t stop there; Azure also enables the creation of up to 5000 custom roles per tenant based on your requirements.
Scope: It contains one or more resources to which the granted access applies. Azure lets you specify scopes at four levels: Management group, Subscription, resource group, and resource.
Scopes generally have a parent-child relationship, so when access is granted to a parent scope, permissions are directly inherited by the child scopes.
Here’s a flow of how the role assignment in Azure RBAC works
Pro tip: You can assign roles to groups instead of users, as this reduces the number of role assignments (4000 allowed per Subscription) and simplifies role management.
Assigning roles to specific users might be an overhead when several resources are spread across various scopes, such as subscriptions, resource groups, etc. In this case, granting/restricting access to an entire application can come in handy. Explore how it’s done!
What differentiates Azure ABAC from RBAC?
Just like Azure RBAC, Azure Attribute-based access control (ABAC) allows access based on role definitions and assignments. But if you want to fine-grain access management, then Azure ABAC can be ideal!
ABAC supports adding certain conditions or attributes on top of role assignments. Say you have set the tag as “Key=Project, Value = Cascade” while creating a Blob container.
As shown below, those tags can be further used as conditions for ABAC authentication.
Advantages of using Azure ABAC
- It offers more granularity. In our case, you can grant users read access to Blobs in your Subscription only if the Blobs are tagged “Project=Cascade.”
- You can restrict access control based on business information, like a resource’s deployment stage or a user’s project.
- Using Azure ABAC authentication helps to reduce the number of role assignments significantly.
Note: Azure ABAC is generally available (GA) for controlling access only to Blob Storage, Azure Data Lake Storage Gen2 & Queues using specific attributes in the standard storage account performance tier.
Azure ABAC vs. RBAC: Which is better?
Though both access management services are effective in their ways, ABAC is more granular than RBAC.
ABAC facilitates access based on attributes, and security is significantly enhanced. But, the main disadvantage is the complexity involved in defining and maintaining multiple conditions.
Anyways, if you have a more extensive user base, then ABAC slightly has the upper hand, though its implementation is complex and time-consuming.
The top advantage of RBAC systems is that they grant access based on the job roles imposed on individual users. Creating many such roles may seem fine for a small to mid-sized business, but it becomes a big turmoil as the company grows.
Here are a few other limitations faced by users in Azure RBAC,
- As mentioned, RBAC can’t be configured at the application level
- It restricts access only to the Service Bus namespace, not to individual components like Queues, Topics, and Subscriptions.
- It allows only a certain number of custom roles per Azure AD.
To eliminate such limitations, you can try out Serverless360 (Cloud Management Platform) to have a more fine-grained and simplified access control while effectively managing the Azure resources.
Additionally, Serverless360 audits every activity users perform on Azure services to spot any security breaches immediately.
Secured access is mandatory for any organization leveraging Azure infrastructure. So, in this blog, we’ve covered the difference between 2 primary access management services in Azure (RBAC vs. ABAC), along with their pros and cons.
But before jumping to a conclusion, understand your needs and choose the security model that better suits your Azure environment.