The effect of granting Azure Reader role on Azure Container Registry instances

We observed that granting Azure Reader role at subscription or resource group level allows users to pull container images from Azure Container Registry instances, thus potentially reveling confidential or sensitive data to unauthorised parties.

In a recent security configuration review of one our client’s Azure workloads, we uncovered a significant issue regarding the Azure Container Registry (ACR) permissions. Our auditors, despite being granted only “Reader” access at the subscription level, were able to download/pull container images from the Azure Container Registry. This behaviour is in fact expected, as outlined in Microsoft’s Azure Container Registry documentation. However, we believe that the default permission (AcrPull) granted by this role is undesirable and reflects a lack of separation between the data plane and the control plane.

This discovery raises important questions about the default permissions associated with Azure roles and their potential security implications, especially when sensitive information is embedded within container images.

In this blog post, we will describe the Azure container registry component, how its permission model is designed and how default permissions may provide a security concern for customers (e.g. when secrets are embedded in containers in particular). After discussing the potential impacts of these design decisions, opportunities, including measures to mitigate potential risks, will be addressed.

What is Azure Container Registry?

Azure Container Registry (ACR) is a managed service on the Microsoft Azure platform that allows users to build, store, and manage container images and related artefacts. Based on the open-source Docker Registry 2.0, ACR supports both public and private configurations, enabling customers to maintain Docker images and upload third party or custom images in a secure environment. ACR also facilitates interoperability with services such as Azure Kubernetes Services (AKS) and Azure Container Apps or other third-party containers services. (more informations are available at https://learn.microsoft.com/en-us/azure/container-registry/container-registry-intro)

The permission model : what the documentation says

Azure Container Registry employs a permission model based on Azure Role-Based Access Control (RBAC). It supports several built-in roles, including “Owner,” “Contributor,” and “Reader.” Notably, the “Pull image” permission is automatically granted to these three roles, allowing any user assigned to them at the subscription level to pull images from the ACR. This means that even limited access provided by these built-in roles inadvertently grants the ability to connect to extract container images from the registry.

source : https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli

Now, let us try this in a lab environment to verify what it’s possible.

Proof of Concept

Requirements

To demonstrate this issue, we conducted a proof-of-concept in a controlled lab environment. The requirements included:

  • Azure CLI and Docker CLI installed
  • An admin user with the ArcPush role and Global admin role to create an ACR and push an image
  • A test user assigned the Reader role on the subscription containing the ACR

Deployment and configuration

  • To reproduce the issue, we have created a dedicated subscription in our lab Tenant and deployed an Azure container registry :
Basic configuration of a ACR
  • Then, we deploy a sample image to the registry :
az login
az acr login --name crpoc01azurecr.io
docker pull nginx
docker tag nginx crpoc01azurecr.io /samples/hello-world
docker push crpoc01azurecr.io /samples/hello-world
  • After deployment success, we can see the pushed image in the repositories tab of our registry  :
Container registry is deployed
  • Finally, we assign the “Reader” role to a test user at the subscription level. On the subscription, click on “Access control (IAM) section. Then click on “Add” button and click on “Add role assignment.”
Access control at subscription level
  • Click on the “Reader” role and click on “Next” button.
Add role assignment role selection
  • Click on “Select members” and select your target user.
Add role assignment members tab
  • Click on “Review + assign” button

Taking advantage of the overly permissive authorization

After deploying a sample image into the registry, we assigned the Reader role to our test user. Upon logging in and executing commands to list and pull images, we will confirm that the user can successfully download container images, demonstrating the unintended access granted by the Reader role.

  • We will launch a command prompt and establish a connection to the repository with our test user:
az login
az acr login --name crpoc01.azurecr.io
  • Once logged in, we’re going to list the images inside the registry :
az acr repository list --name crpoc01.azurecr.io
acr repository list output

  • Now we will verify if our test user, with a reader role on the subscription, is really allowed to pull the image:
docker pull crpoc01.azurecr.io/samples/nginx:latest
Docker pull output
  • Download of container images succeeded! We can verify that the pulled image is really in our local docker images:
docker images
docker images output

Conclusion

This demonstration highlights a critical oversight in Azure’s default permissions. Users with the “Reader” role at subscription level, along with “Owner” and “Contributor” roles, can connect to an Azure Container Registry (ACR) instance, pull its container images and navigate their contents offline. Any data stored unencrypted in the image, including those typically confidential or sensitive (e.g., network and topology information, URIs to confidential cloud resources, business information, Personal Identifiable Information (PII), keys and secrets to third-party systems, etc.) is therefore exposed and may pose a risk to the organization. 

Although the Azure Container Registry service implements a Role-Based Access Control (RBAC) model, it still appears to lack the separation of duties advertised by cloud service providers between the control plane and the data plane. In the case of container registries, assigning a default Azure role at the subscription level (i.e., Reader, Owner, and Contributor) results in granting access to both planes simultaneously and without requiring any approval from the resource manager.  

Because of this, organizations that have granted auditors Reader access at a subscription-level in the past may have also inadvertently given auditors full access to the contents of any image hosted in the Azure Container Registry instances located in the same subscription. 

In contrast, Azure Key Vault implements an RBAC model that appears to fulfill the initial promise (which, by extension, reinforces our initial oversight hypothesis): subscription-level roles can be assigned to users and provide them with access to the control plane. In other words: a Reader can browse a Key Vault instance’s metadata and observe its configuration but not change it. Above all, a Reader can never read the actual content of the vault. To grant access inside the vault, the owner must also grant users roles specifically made available by Microsoft for Key Vault resources (e.g., Key Vault Contributor, Key Vault Reader, Key Secrets User). This granularity of access rights allows vault operators to securely manage access to cryptographic material (e.g., secrets, keys, and certificates) akin to managing access to data stored in any database and service alike. 

Our recommendations

To mitigate these risks, we recommend the following best practices:

  1. Limit role assignments: Ensure that only essential users are assigned the Azure “Reader”, “Contributor”, or “Owner” roles at the subscription level. Consider using ACR Repository roles or custom roles for more granular access control.
  2. Avoid storing sensitive data in images: Do not embed sensitive information, such as credentials or secrets, within container images. Utilize Azure Key Vault for secure storage of sensitive data.
  3. Isolate the registry: Deploy the container registry in a dedicated Azure subscription to minimize exposure.
  4. Restrict network access: Disable public access to the ACR or restrict it to specific IP addresses. (https://learn.microsoft.com/en-us/azure/container-registry/container-registry-access-selected-networks). Also, implement private links for enhanced security (https://learn.microsoft.com/en-us/azure/container-registry/container-registry-private-link).
  5. Implement Conditional Access Policies: Configure policies to restrict which users can access the registry (https://learn.microsoft.com/en-us/azure/container-registry/container-registry-configure-conditional-access).
  6. Monitor activity: Set up diagnostic settings and monitor activity logs to detect any unexpected behaviour related to authentication and image pulls.

What we could expect in the future

We believe that Microsoft should consider revising the default permission model for Azure Container Registry. A dual-layer permission approach, similar to Azure Key Vault permission model, could enhance security by segregating control plane and data plane permissions.

How we can help you

Our Advisory and Audit division operates a team that specialises in conducting security assessments of AWS, Azure and Microsoft 365 tenants. We utilise publicly available benchmarks, such as CIS Benchmarks, alongside our proprietary benchmarks to provide clients with a comprehensive view of their security posture. We offer actionable plans to strengthen their platforms and mitigate potential risks.

For more information about our services, please visit the Orange Cyberdefense Switzerland website, in the cloud security section https://www.orangecyberdefense.com/ch/all-services/assess-advise/cloud-security.