Azure RBAC is so 2023! Let’s get ABAC to the rescue!

This post is part of a series

• How to deploy Azure LogAnalytics Workspace and link Application Insights to it
• How to use Azure Container Registry to standardize deployments using Bicep across your organization
• How to secure access to an Azure Container Registry with RBAC
• How to secure access to an Azure Container Registry with a Managed Identity
• 📍 you are here - Azure RBAC is so 2023! Let’s get ABAC to the rescue!
• How to utilize the Azure Container Registry in your Azure DevOps pipeline - to be published soon

I like to deploy my Azure resources using Bicep - If you never heard about it, I blogged a while ago on how to get started with Bicep - please catch up first!

In the last post, I showed you how assigning an RBAC role to a Managed Identity saves you some password rotation related tasks, and I promised to write the next post about ABAC. So here we go:

Quick recap: RBAC

Azure Role-Based Access Control (RBAC) lets admins assign roles to users, groups, and services to control access to Azure resources. With roles like Owner, Contributor and Reader, RBAC makes sure everyone has just the right permissions to get their jobs done, which cuts down on admin headaches.

But as businesses (and their cloud maturity) grow, so do their access control needs. If you’ve been managing permissions with RBAC you know it’s fabulous for broad, static access. But what happens when your access requirements start getting more complex? Enter ABAC (Attribute-Based Access Control): It’s the next level of fine-grained, dynamic access control.

ABAC adds context.

Instead of just assigning permissions based on a user’s role, you can now use attributes like department, project, or even location to grant access to specific resources. Think of it as RBAC with superpowers.

A Real-World Scenario: Using RBAC and ABAC Together

Let’s say you’re running a multi-tenant SaaS app for different departments like Finance, Sales, and HR, and you need to limit access within each department. RBAC helps you set up basic roles (like Storage Contributor or Reader), but it doesn’t go far enough when users or apps only need access to specific resources, like data tagged with Finance or Project Deathstar or containers called templates or data.

That’s where ABAC comes in. You can assign broad roles with RBAC, and then fine-tune access with ABAC policies. Here’s how that works:

• RBAC Role Assignment: John from Finance gets the Storage Contributor role, allowing him to manage all storage accounts in the Finance resource group
• ABAC Policy: We add a rule that says our user can only access containers with the name templates. So even though his role allows him broader access, ABAC restricts him to only what’s relevant to his project.

That is exactly what principle of least privilege means!

ABAC allows you to adapt permissions on the fly based on user and resource attributes, making it perfect for dynamic environments where things change frequently – like employees working across regions or switching between projects.

Assigning ABAC Roles with Azure CLI

# Variables
$subscriptionId = "<your subscription id>"
$resourceGroupName = "<your resource group>"
$identityName = "<your managed identity or user>"
$roleName = "Storage Blob Data Contributor"
$storageAccountName = "<your storage account>"
# Get the principal ID
$identityPrincipalId = $(az identity show --resource-group $resourceGroupName --name $identityName --query 'principalId' --output tsv)
# Define the scope
$scope = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Storage/storageAccounts/$storageAccountName"
# Define the condition
$condition = "(@Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals 'templates')"
$conditionVersion = "2.0"
# Assign the role with the condition
az role assignment create --assignee $identityPrincipalId --role $roleName --scope $scope --condition $condition --condition-version $conditionVersion

Let’s see how you can actually do this using Azure CLI. In this example, we’ll assign a Managed Identity the Storage Blob Data Contributor role and then apply an ABAC policy to restrict access to containers called templates.

We can check in the Azure Portal that this worked:

This ABAC policy ensures that our Managed Identity (or the user in case you chose one) only gets access to the correct container name ✅

Conclusion: Better Together

Instead of asking yourself now if RBAC or ABAC is better: RBAC and ABAC aren’t competitors – they’re complementary. RBAC handles the heavy lifting of defining broad access, while ABAC gives you the flexibility to refine access based on real-world conditions. Think of ABAC as a precision tool you can use alongside RBAC when things get a little more complex.