We’re encountering an issue with Azure App Services where the managed identity used to pull container images from Azure Container Registry (ACR) is being cleared or reset to empty after deployment.

Here’s the relevant Bicep configuration we’re using:

linuxFxVersion: 'DOCKER|test.azurecr.io/dummy/app:1.0.0'
acrUseManagedIdentityCreds: true
acrUserManagedIdentityID: identityId

We’re using the following resource version: 'Microsoft.Web/sites@2023-12-01'.

Has anyone experienced this issue or have suggestions for debugging/fixing it? Could it be related to the resource version or the configuration?

We've tried changing the identityId to use the principal id instead of the resource id, but this gives a different error instead.

EDIT:

To solve this, we had to include the DOCKER_REGISTRY_SERVER_URL parameter, and remove the acrUserManagedIdentityID parameter.

Like this:

linuxFxVersion: 'DOCKER|test.azurecr.io/dummy/app:1.0.0'
acrUseManagedIdentityCreds: true
appSettings: [
  {
    name: 'DOCKER_REGISTRY_SERVER_URL'
    value: ''
  }

Noticing the behavior for the linuxFxVersion, we've now added this configuration to pull the image directly:

linuxFxVersion: 'DOCKER|index.docker.io/dummy/app:1.0.0'
appSettings: [
  {
   name: 'DOCKER_REGISTRY_SERVER_PASSWORD'
   value: '@Microsoft.KeyVault(SecretUri=${keyVaultSecretUri}/dummy-docker-key/)'
  }
  {
   name: 'DOCKER_REGISTRY_SERVER_USERNAME'
   value: 'dummy'
  }
  {
   name: 'DOCKER_REGISTRY_SERVER_URL'
   value: ''
  }

There is a /v1 in the DOCKER_REGISTRY_SERVER_URL, but not in the linuxFxVersion. It's a bit confusing, but it works in the end. It would be great if there were some documentation on the behavior of this parameter, including how it behaves when you input a URL.

We’re encountering an issue with Azure App Services where the managed identity used to pull container images from Azure Container Registry (ACR) is being cleared or reset to empty after deployment.

Here’s the relevant Bicep configuration we’re using:

linuxFxVersion: 'DOCKER|test.azurecr.io/dummy/app:1.0.0'
acrUseManagedIdentityCreds: true
acrUserManagedIdentityID: identityId

We’re using the following resource version: 'Microsoft.Web/sites@2023-12-01'.

Has anyone experienced this issue or have suggestions for debugging/fixing it? Could it be related to the resource version or the configuration?

We've tried changing the identityId to use the principal id instead of the resource id, but this gives a different error instead.

EDIT:

To solve this, we had to include the DOCKER_REGISTRY_SERVER_URL parameter, and remove the acrUserManagedIdentityID parameter.

Like this:

linuxFxVersion: 'DOCKER|test.azurecr.io/dummy/app:1.0.0'
acrUseManagedIdentityCreds: true
appSettings: [
  {
    name: 'DOCKER_REGISTRY_SERVER_URL'
    value: 'https://test.azurecr.io'
  }

Noticing the behavior for the linuxFxVersion, we've now added this configuration to pull the image directly:

linuxFxVersion: 'DOCKER|index.docker.io/dummy/app:1.0.0'
appSettings: [
  {
   name: 'DOCKER_REGISTRY_SERVER_PASSWORD'
   value: '@Microsoft.KeyVault(SecretUri=${keyVaultSecretUri}/dummy-docker-key/)'
  }
  {
   name: 'DOCKER_REGISTRY_SERVER_USERNAME'
   value: 'dummy'
  }
  {
   name: 'DOCKER_REGISTRY_SERVER_URL'
   value: 'https://index.docker.io/v1'
  }

There is a /v1 in the DOCKER_REGISTRY_SERVER_URL, but not in the linuxFxVersion. It's a bit confusing, but it works in the end. It would be great if there were some documentation on the behavior of this parameter, including how it behaves when you input a URL.

• azure
• azure-bicep

• check with the appSettings for container image pull refering to DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME, and DOCKER_REGISTRY_SERVER_PASSWORD are correctly set @JasperPol – Vinay B Commented Nov 20, 2024 at 5:18
• Thanks! The DOCKER_REGISTRY_SERVER_URL turned out to be the solution. The acrUserManagedIdentityID parameter seems to be unnecessary here, even though it sounds exactly like what I should use. – Jasper Pol Commented Nov 20, 2024 at 9:49
• We've tried changing the identityId to use the principal id instead of the resource id, it should be the managed identity resource id not the resource id. user-managed identity reset? If there are bicep file re-deploy the user-assigned managed identity? – wenbo Commented Nov 21, 2024 at 6:49

1 Answer 1

User-assigned managed identity is reset after Bicep deployment

As discussed in the comments while configuring the container image pull make sure DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME, and DOCKER_REGISTRY_SERVER_PASSWORD are correctly set in appSettings

This will ensure the Azure App Service to properly pull container images from ACR using Managed Identity

demo configuration:

resource webApp 'Microsoft.Web/sites@2023-12-01' = {
  properties: {
    linuxFxVersion: 'DOCKER|test.azurecr.io/dummy/app:1.0.0'
    acrUseManagedIdentityCreds: true
    appSettings: [
      {
        name: 'DOCKER_REGISTRY_SERVER_URL'
        value: 'https://test.azurecr.io'
      }
    ]
  }
  identity: {
    type: 'SystemAssigned, UserAssigned'
    userAssignedIdentities: {
      '${managedIdentityId}': {}
    }
  }
}

this acrUserManagedIdentityID parameter is not required when using DOCKER_REGISTRY_SERVER_URL

Refer:

https://learn.microsoft/en-us/azure/app-service/configure-custom-container?pivots=container-linux&tabs=debian#configure-registry-credentials

https://learn.microsoft/en-us/azure/templates/microsoft.web/sites?pivots=deployment-language-bicep#linuxfxversion