[enhancement]: AzureResourceManagerTemplateDeployment@3 - support bicep deployment with private registries

[johnnyreilly]

Task name

AzureResourceManagerTemplateDeployment@3 - supports bicep deployment - but not with private registries. Would be awesome if it did.

Describe your feature request here

Whilst AzureResourceManagerTemplateDeployment@3 supports Bicep deployment, it doesn't support authenticating for private Bicep registries. Consider the following:

          - task: AzureResourceManagerTemplateDeployment@3
            name: DeployInfra
            displayName: Deploy infra
            retryCountOnTaskFailure: 3
            inputs:
              deploymentScope: Resource Group
              azureResourceManagerConnection: ${{ variables.serviceConnection }}
              subscriptionId: $(subscriptionId)
              action: Create Or Update Resource Group
              resourceGroupName: $(resourceGroupName)
              location: $(location)
              templateLocation: Linked artifact
              csmFile: "infra/main.bicep"

We see the following when we attempt to execute it:

/home/vsts/work/1/s/infra/database/cosmos.bicep(57,17) : Error BCP192: Unable to restore the module with reference "br:icebox.azurecr.io/bicep/ice/providers/document-db/database-accounts:v1.3": Service request failed.
Status: 401 (Unauthorized)

Content:
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required, visit https://aka.ms/acr/authorization for more information."}]}

Headers:
Server: openresty
Date: Fri, 02 Jun 2023 13:11:24 GMT
Connection: keep-alive
X-Ms-Correlation-Request-Id: b1ac068c-f69d-4495-90c3-302ff1c93ff6
x-ms-ratelimit-remaining-calls-per-second: 333.066667
Strict-Transport-Security: REDACTED
Content-Type: text/plain; charset=utf-8
Content-Length: 134

/home/vsts/work/1/s/infra/database/cosmos.bicep(72,25) : Error BCP192: Unable to restore the module with reference "br:icebox.azurecr.io/bicep/ice/providers/document-db/sql-databases:v1.2": Service request failed.
Status: 401 (Unauthorized)

Workaround

If you want to use this at present, you're required to manually restore the Bicep modules first. We've found it's possible to achieve this by using the AzureCLI@2 task first and triggering a restore like so:

          - task: AzureCLI@2
            displayName: Bicep restore
            inputs:
              azureSubscription: service-connection-with-access-to-registry
              scriptType: bash
              scriptLocation: inlineScript
              inlineScript: |
                bicep restore infra/main.bicep

Where service-connection-with-access-to-registry is an Azure Resource Manager service connection using service principal authentication which has access to the private Bicep registry.

Design thoughts

I'm actually not sure what support for the private registries should look like; if you look at the service connections we're using here; we have 2:

1. with permissions to deploy to Azure used by AzureResourceManagerTemplateDeployment@3
2. with permissions to read from our Bicep registry, used by our restore workaround

It's probably not unusual to have distinct service connections covering different concerns. This makes me wonder if maybe a dedicated registryServiceConnection property might be a good idea.

See also

Mentioned here also:

#15337 (comment)

[abunnyuk]

The AzureResourceManagerTemplateDeployment@3 works incredibly well and suits all of our needs, except for supporting restoring Bicep modules from a Container Registry which is fast becoming the preferred method for organisations.

Adding this support would massively help in streamlining our tasks where, at present, we have to use an AzureCLI@2 task that uses az cli commands to both validate/publish the module and then process the outputs.

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days