This post is part of a series about Deployments, Role Assignments and more!

• 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

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.

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 John can only access resources with project=Deathstar tags. 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!

Often times, security ad convenience are perceived as a sea-saw. The more secure convenient something is for a user (or an admin, or a developer), the less convenient it is. The more convenient something feels, the more e can expect it to be insecure. With ABAC we balance the two approaches - making access secure AND convenient at the very same time.

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 = "rg-building-blocks"
$userEmail = "<email of the user>"
$roleName = "Storage Blob Data Contributor"
$storageAccountName = "<name of the storage account>"

# Get the user object ID using the user email
$userObjectId = $(az ad user show --id $userEmail --query "id" --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/blobs/tags:Project<`$key_case_sensitive`$>] StringEquals 'Deathstar'"
$conditionVersion = "2.0"

# Assign the role with the condition
az role assignment create --assignee $userObjectId --role $roleName --scope $scope --condition $condition --condition-version "2.0"

We can check in the Azure Portal that this worked:

This ABAC policy ensures that our user only gets access if the tag is Project == Deathstar.

💡 If you want t try this out, make sure you do in fact have such a tag! (Ask me how I know 😇)

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.