Loading...

How to secure access to an Azure Container registry with a Managed Identity and RBAC

How to secure access to an Azure Container registry with a Managed Identity and RBAC

This post is part of a series

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 service principle can be used to make sure that someone can only pull images from an Azure Container Registry. This post will cover how to secure your Azure Container Registry with a Managed Identity.

What is a Managed Identity?

If you don’t know about Managed Identities yet: a Managed Identity gives your app an identity in the cloud without the need to register an app in Microsoft Entra (the artist formerly known as Azure Active Directory). This means, that you don’t need to create secrets or certificates and you also don’t need to store secrets or rotate them - Microsoft manages that for you. Because if we are all being honest: Yes, we know that we should rotate secrets. But not enough organizations do this. Managed Identities come in 2 flavors: system assigned and user assigned.

  • System assigned means that they belong to a certain Azure resource and share its lifecycle
  • User-assigned means, that they are resource on their own and can be assigned to one or more other resources.

I covered more about this in this blog post

Now let’s get started:

A little bit of prep work

To assign a Managed Identity to an Azure Container Registry we need have an Azure Container Registry in the first place. If you followed the blog post series - this should already be done. If not - please catch up now.

After that, we create the user-assigned Managed Identity itself:

$Managed_Identity = "<name of your managed identity>"
az identity create --resource-group $RESOURCE_GROUP --name $Managed_Identity

You can check in the Azure portal that it does in fact exist:

managed identity

Assign Managed Identity to ACR

Now let’s assign our Managed Identity to the Azure Container Registry


az acr identity assign --name $ACR_NAME --identities $Managed_Identity --resource-group $RESOURCE_GROUP

Create the role assignment

As a last step, we need to create the RBAC in our identity. To do this, we need the principalId property (aka the Object ID of our Managed Identity)

$PRINCIPAL_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $Managed_Identity --query "principalId" --output tsv)

Now we will use this to create the role assignment:

az role assignment create --assignee $PRINCIPAL_ID --role "AcrPull" --scope "/subscriptions/$subscriptionId/resourceGroups/$RESOURCE_GROUP"

That’s it! Let’s quickly check in the Azure portal that it worked and we are done:

rbac assignment in Managed Identity

The elephant in the room

You might now ask - if I am such a fan of IaC, why wouldn’t we then deploy the Managed Identity with a bicep file (preferably published to an Azure Container Registry for easy use by all developers in the organization)? I’m so glad you asked! 😇

I love to have more than just one tool under my belt. For quick demos or to try out things during first phase of development, I usually use Azure CLI to get started. It’s the easiest way to create and modify the resources I need.

If my solution then scales, I like to have proper Bicep files in place, so that deployments are so repeat and we can easily track what exactly we deployed via source control. So if you want to create a Bicep file for a Managed Identity, here is the module that I would use:

Let’s first get the role id for AcrPull


$ACRPULL_ROLE_ID=$(az role definition list --name acrpull --query "[0].id" --output tsv)
$roleId = (az role definition list --name "AcrPull" --query "[0].id" --output tsv)
$ACRPULL_ROLE_ID = $roleId.Split('/')[-1]

Main Bicep file (main.bicep)

param resourceGroupName string
param subscriptionId string
param managedIdentityName string
param acrName string
param location string = resourceGroup().location
param acrpullRoleId string
module managedIdentityModule 'managedIdentity.bicep' = {
name: 'managedIdentityDeployment'
params: {
name: managedIdentityName
location: location
}
}
module roleAssignmentModule 'roleAssignment.bicep' = {
name: 'roleAssignmentDeployment'
params: {
managedIdentityPrincipalId: managedIdentityModule.outputs.principalId
acrName: acrName
subscriptionId: subscriptionId
acrpullRoleId: acrpullRoleId
}
}

Managed Identity Module (managedIdentity.bicep)

param name string
param location string = resourceGroup().location
resource managedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' = {
name: name
location: location
}

Role Assignment module


param managedIdentityPrincipalId string
param acrName string
param subscriptionId string
param acrpullRoleId string
var acrId = resourceId(subscriptionId, 'Microsoft.ContainerRegistry/registries', acrName)
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
name: guid(acrId, managedIdentityPrincipalId, 'AcrPull')
properties: {
roleDefinitionId: '/subscriptions/${subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/${acrpullRoleId}'
principalId: managedIdentityPrincipalId
scope: acrId
}
}

You can now either deploy this from here (locally) with Azure CLI or you publish these modules to an Azure Container Registry so that others can consume them from there easily. I described earlier in this series how the latter works; here is the Azure CLI command:

$ACRPULL_ROLE_ID = (az role definition list --name "AcrPull" --query "[0].id" --output tsv).Split('/')[-1]
az deployment group create --resource-group $RESOURCE_GROUP --template-file main.bicep --parameters resourceGroupName=$RESOURCE_GROUP subscriptionId=$subscriptionId managedIdentityName=$Managed_Identity acrName=$ACR location=$location acrpullRoleId=$ACRPULL_ROLE_ID

Boom - done ✅

You now have two ways to automatically create a Managed Identity, and assign the RBAC to it.

Conclusion

We can now use the Managed identity instead of our service principal and don’t need to worry anymore that we really don’t care about secret rotation. Azure Key Vault is already good to store credentials, but following best practices we would want to regularly rotate them. This is now automagically being take care of by Microsoft :-)

PS

When I mentioned “Writing ablog post about Bicep and RBAC”, Janek Fellien very casually told me that RBAC is so 2023 and that ABAC is the hottest shit. Let me know if I should find a good scenario for that and write about it!

Published on:

Learn more
Luise Freese: Consultant & MVP
Luise Freese: Consultant & MVP

Recent content on Luise Freese: Consultant & MVP

Share post:

Related posts

Code AI apps on Azure - Python, Prompty & Visual Studio

Build your own custom applications with Azure AI right from your code. With Azure AI, leverage over 1,700 models, seamlessly integrating them ...

2 days ago

Network Connectivity for RISE with SAP S/4HANA Cloud Private Edition on Azure

In this article, we will explore different ways to connect to RISE with SAP S/4HANA Cloud Private Edition deployment on Azure, guiding yo...

2 days ago

Azure Landing Zones - Policy Refresh Q1 FY25

ALZ - Policy Refresh Q1 FY25 is here! As you may be aware, the ALZ team release cadence is now on quarterly basis to help customers and partne...

2 days ago

Debug Queries More Efficiently with the Improved Error Messaging in Azure Cosmos DB Data Explorer

Azure Cosmos DB Data Explorer is a web-based tool available in the Azure Portal that allows you to manage data, as well as track and fix issue...

3 days ago

Meet the Winners | Microsoft Developers Azure AI & Azure Cosmos DB Learning Hackathon

Azure Cosmos DB powers some of the world’s most popular intelligent apps like ChatGPT. In a recent hackathon, Over 9,500 developers engaged wi...

3 days ago

Introducing RBAC Authentication and more for the Azure Cosmos DB Integrated Cache

We’re excited to announce new features for the Azure Cosmos DB! The integrated cache is built into the dedicated gateway, and now there’s new ...

3 days ago

Microsoft DiskANN in Azure Cosmos DB Whitepaper

We are excited to publish a new whitepaper titled, Microsoft DiskANN in Azure Cosmos DB, where we examine the impressive capabilities of Micro...

4 days ago

Announcing Private Preview: VS Code Extension of vCore-based Azure Cosmos DB for MongoDB

Overview We’re excited to introduce a new VS Code extension for vCore-based Azure Cosmos DB for MongoDB ! This tool allows users to conn...

4 days ago

Azure Communication Services September 2024 Feature Updates

The Azure Communication Services team is excited to share several new product and feature updates released in August 2024. (You can view previ...

4 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy