How does it work. In AzureRM SC I can select my own user managed identity, but in this type I cannot select it. Is it creating some managed identities in background? Or maybe just for during the pipeline using it? Can somebody explain?

How does it work. In AzureRM SC I can select my own user managed identity, but in this type I cannot select it. Is it creating some managed identities in background? Or maybe just for during the pipeline using it? Can somebody explain?

• azure
• azure-devops

• Hi @Zveratko, Good day. Have you got a chance to check the workaround below to use an ARM service connection with an MSI in the Docker@1 task.? Hope the information may help resolve your concerns in this post. Thx for the sharing. – Alvin Zhao - MSFT Commented Mar 20 at 2:46

1 Answer 1

Based on your description, it appears that you have tried to create a Docker Registry service connection with the Registry type of Azure Container Registry and you would like to use the Authentication type of the Managed Service Identity.

However, this operation in Azure DevOps does not create any underlying MSI for this connection, nor does it allow selecting an existing MSI. When using a Docker@2 task with this service connection on an Azure VM configured as a self-hosted pipeline agent, the authentication defaults to the system-assigned MSI of that VM. This means:

• Different agent machines may authenticate against different MSIs.

• If the VM has multiple user-assigned MSIs, authentication conflicts may arise.

Workarounds for this limitation:

Option 1: Use a Service Principal Instead of MSI

• Choose Service Principal for authentication, which automatically creates a service principal (app registration) with a client secret.
• Alternatively, use Workload Identity Federation, which also creates a service principal (app registration) but with a federated credential (no expiration).

Option 2: Use an ARM Service Connection with MSI

Although Docker@2 does not support ARM service connections, Docker@1 and AzureCLI@2 tasks can reference it to authenticate against a user-assigned MSI explicitly. This eliminates the need for an MSI-bound self-hosted agent VM.

Example using Docker@1 with an ARM service connection:

pool:
  vmImage: ubuntu-latest

steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: 'ARMSvcCnnMSIACR' # References the ARM service connection with an underlying user-assigned MSI
    scriptType: 'pscore'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az acr login --name $(myACR)
      docker pull $(myACR).azurecr.io/test/repo/ubuntu:base
      docker images
- task: Docker@1
  inputs:
    containerregistrytype: 'Azure Container Registry'
    azureSubscriptionEndpoint: 'ARMSvcCnnMSIACR' # References the ARM service connection with an underlying user-assigned MSI
    azureContainerRegistry: '$(myACR).azurecr.io'
    command: 'Build an image'
    dockerFile: '$(System.DefaultWorkingDirectory)/Ubuntu/HelloWorld/Dockerfile'
    imageName: 'ubuntu/helloworld:$(Build.BuildId)'
- task: Docker@1
  inputs:
    containerregistrytype: 'Azure Container Registry'
    azureSubscriptionEndpoint: 'ARMSvcCnnMSIACR' # References the ARM service connection with an underlying user-assigned MSI
    azureContainerRegistry: '$(myACR).azurecr.io'
    command: 'Push an image'
    imageName: 'ubuntu/helloworld:$(Build.BuildId)'