Best practice for cross-tenant ACR image pull during customer ARM template deployment (without sharing admin credentials)

The Azure equivalent for a private cross-tenant AKS image pull is not to use the customer tenant’s AKS managed identity directly against an ACR in another tenant. For this scenario, the supported pattern is cross-tenant service principal authentication.

Recommended approach:

1. Create a multitenant Microsoft Entra application in the ISV tenant.
   • In Supported account types, select Accounts in any organizational directory.
   • Create a client secret for that app.
2. Provision that app in the customer tenant.
   • An admin in the customer tenant opens the consent URL for the multitenant app and accepts Consent on behalf of your organization.
3. Grant the app pull permission on the ISV ACR.
   • In the ACR tenant, assign the service principal the correct role scoped to the target registry:
     • Container Registry Repository Reader for ABAC-enabled registries
     • AcrPull for non-ABAC registries
4. Configure the customer AKS deployment to use that service principal.
   • For cross-tenant AKS-to-ACR pulls, the AKS cluster must use service principal authentication.
   • After updating the AKS service principal credential with the multitenant app’s application (client) ID and client secret, the AKS cluster in the customer tenant can pull images from the ACR in the ISV tenant.

Key implication for the current design:

• Do not use ACR admin username/password.
• Do not rely on AKS managed identity for this cross-tenant pull path, because when the cluster and registry are in different tenants, AKS managed identity can’t be used to attach the registry and authenticate.
• The least-privilege option in the documented cross-tenant AKS pattern is a dedicated multitenant app/service principal with only pull rights on the target registry or repository scope.

For the deployment flow described:

• The ARM template or deployment process should use the client ID + client secret of the dedicated multitenant app instead of hardcoded ACR admin credentials.
• Scope permissions as narrowly as possible:
  • Container Registry Repository Reader if the registry is ABAC-enabled
  • otherwise AcrPull
• This gives a revocable, customer-specific credential path and keeps the registry private.

If the deployment environment needs CLI-based registry authentication, the documented service principal flow is:

az login --service-principal --username $SP_APP_ID --tenant $SP_TENANT_ID --password /path/to/cert/pem/file
az acr login --name myregistry

For direct user or workstation access, Microsoft recommends individual Entra identity with az login and az acr login, but for unattended deployment and AKS pull scenarios, a service principal is the recommended model.

References:

• Pull images from a container registry to an AKS cluster in a different Microsoft Entra tenant
• Azure Container Registry authentication with service principals
• Scenarios to authenticate with Azure Container Registry from Kubernetes