Azure Managed Application Fails with KeyVaultParameterReferenceNotInTheSameTenant When Publisher Management Access Is Disabled

Disabling publisher management access makes the publisher-tenant Key Vault reference unsupported; remove that reference and use either customer-supplied secure parameters or a cross-tenant ACR service principal, with a customer-local ACR plus managed identity as the strongest credential-free design.

Why the deployment changes behavior

Microsoft documents Key Vault credential retrieval for Managed Applications only when management access is enabled.^1^ The Key Vault integration also relies on the Appliance Resource Provider service principal being granted access to the vault.^2^

When management access is disabled:

• The publisher has no access to the deployed managed application or managed resource group in the customer tenant.
• The deployment executes in the customer subscription and tenant.
• The publisher Key Vault reference crosses that tenant boundary, producing KeyVaultParameterReferenceNotInTheSameTenant.

“No publisher management access” is a supported permission model, but it intentionally removes publisher access; it is not merely a UI setting controlling post-deployment maintenance.^3^

Therefore, granting more Key Vault permissions, enabling template deployment, or changing the vault firewall does not resolve this particular error. Those settings are relevant only after the deployment model supports the Key Vault reference.

Recommended credential approaches

Option 1: Customer-local ACR and managed identity

For the cleanest separation, make the image available in an ACR belonging to the customer tenant, then:

1. Deploy a user-assigned managed identity with the managed application.
2. Assign it AcrPull on the customer’s ACR.
3. Attach the identity to the Container App.
4. Configure the registry entry with the identity resource ID instead of username and passwordSecretRef.

Container Apps supports both user-assigned and system-assigned identities for ACR pulls and recommends user-assigned identity when possible.^4^

Conceptually, the Container App registry configuration is:

{
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "<identity-resource-id>": {}
    }
  },
  "properties": {
    "configuration": {
      "registries": [{
        "server": "<customer-registry>.azurecr.io",
        "identity": "<identity-resource-id>"
      }]
    }
  }
}

Do not specify a registry username or password when using managed identity. The identity must have AcrPull on the registry.^5^

Images can be imported from an ACR in another tenant by supplying pull credentials during the import. Cross-tenant import does not work when public access is disabled on the source registry.^6^

Option 2: Cross-tenant service principal

If the Container App must pull directly from the publisher ACR:

1. Create a multitenant application/service principal for the workload.
2. Provision its service principal in the publisher tenant.
3. On the publisher ACR, assign:
   • AcrPull for a non-ABAC registry, or
   • Container Registry Repository Reader for an ABAC-enabled registry.
4. Configure Container Apps registry authentication using:
   • Username: application/client ID
   • Password: client secret
5. Pass those values as secure customer inputs or retrieve them through a secret mechanism located in the customer tenant. Do not embed them in the Marketplace package.

ACR explicitly supports a service principal for cross-tenant image-pull scenarios.^7^ Container Apps accepts registry credentials through a secret referenced by passwordSecretRef.^5^

A repository-scoped ACR token can provide narrower repository access than the registry-wide admin account, but it remains a username/password credential that must be delivered and rotated securely. Do not use or hardcode the ACR administrator credentials; hardcoded usernames, passwords, keys, and SAS URIs are prohibited in Managed Application packages.^1^

Managed identity directly against the publisher ACR

Container Apps documents managed-identity image pulls where the identity is assigned AcrPull on the registry, but the supplied documentation does not establish a supported cross-tenant Container Apps managed-identity flow. A managed identity created with the Container App belongs to the customer tenant, while the publisher ACR belongs to another tenant.

Use the documented cross-tenant service-principal pattern instead, or copy the image into a customer-tenant ACR and use managed identity locally. Do not infer cross-tenant support from the fact that managed identity works when both resources share a tenant.

References

1. Restrictions on hardcoded credentials
2. Access Key Vault secret when deploying Azure Managed Applications
3. Azure Managed Applications overview
4. Azure Container Apps image pull with managed identity (portal)
5. Containers in Azure Container Apps
6. Import container images to a container registry
7. Azure Container Registry authentication with service principals