Accessing Customer's ACR using Publisher's Managed Identity

Question

As written in Microsoft's documentation, Managed Identity does not work across tenant boundaries and I would like to ask about this in the context of Azure Managed Applications.

I have a configuration where I, as a Publisher have a Container App that is associated with Managed Identity. Managed Identity has a Contributor role in the publisher subscription.

I have a customer tenant with the Managed Application installed. There is a Resource Group with the Azure Container Registry dedicated to that Managed Application.

I have created a Container App in the publisher subscription and it uses the Managed Identity mentioned above. The .NET application uses DefaultAzureCredential and the Azure SDK for .NET. The application successfully connects to ACR in the Customer Managed Application installation and I can upload Docker images there.

The question is: why does this work? Theoretically, the publisher's managed identity should not work across the tenant boundaries, but I am able to connect to ACR living in the Customer Tenant.

Is there something I am missing?

Answer 1

Your observation is valid, and the behavior you're encountering arises due to specific nuances in how Azure Managed Identity and Azure Resource Manager (ARM) work together in the context of Azure Managed Applications and cross-tenant scenarios.

Let me clarify why your setup works despite the apparent tenant boundary:

1. Azure Managed Application Context

When using Azure Managed Applications, there is a special relationship between the publisher and the customer tenant. Specifically:

Managed Resource Group Ownership: In an Azure Managed Application deployment, the publisher retains ownership of the Managed Resource Group (MRG) in the customer's subscription. This means the publisher's subscription has a certain level of control and permission delegation over the resources in the customer's tenant.

2. Role Assignment for Managed Identities

Managed Identities are restricted to their own tenant by default. However:

• In your scenario, you have explicitly assigned a Contributor role to the publisher's Managed Identity for the specific resource (Azure Container Registry) in the Managed Resource Group within the customer subscription.
• This role assignment is effectively creating an exception to the tenant boundary rule because:
  • The role assignment is resource-scoped, not tenant-scoped.
  • The Managed Identity is granted access to interact with the ACR, regardless of its tenant origin.

3. Cross-Tenant Access in Managed Applications

Azure Managed Applications provide the publisher with certain permissions that facilitate cross-tenant operations:

• The Managed Identity is treated as a trusted identity for operations within the Managed Resource Group.
• The DefaultAzureCredential in your .NET application successfully authenticates and accesses ACR because the assigned Contributor role explicitly allows those actions.

Why Does This Appear to Break the Tenant Boundary?

This works because role assignments are scoped at the resource level, not the tenant level:

• Azure evaluates role-based access control (RBAC) at the resource level for every API call, regardless of the origin tenant of the identity.
• When the publisher's Managed Identity makes a request to ACR in the customer subscription, the role assignment at the resource level takes precedence, bypassing the usual tenant restrictions.

The cross-tenant access in your setup works because:

• The Managed Application's architecture allows the publisher to manage resources in the customer's subscription.
• You explicitly assigned a Contributor role to the publisher's Managed Identity on the ACR, which permits cross-tenant access to that specific resource.

While Managed Identity itself does not inherently support cross-tenant operations, the combination of:

1. Managed Application resource scoping, and
2. Explicit RBAC role assignments at the resource level, makes this scenario functional.