Skip to main content

Private Bicep registry authentication with AzureResourceManagerTemplateDeployment@3

· 3 min read
John Reilly
OSS Engineer - TypeScript, Azure, React, Node.js, .NET

If you deploy Bicep templates to Azure in Azure DevOps, you'll likely use the dedicated Azure DevOps task; the catchily named AzureResourceManagerTemplateDeployment@3. This task has had support for deploying Bicep since early 2022. But whilst vanilla Bicep is supported, there's a use case which isn't supported; private Bicep registries.

title image reading "Private Bicep registry authentication with AzureResourceManagerTemplateDeployment@3" with the Bicep, Azure and Azure DevOps logos

"Unable to restore the module... Status: 401 (Unauthorized)"

Private Bicep registries are a great way to share Bicep modules across your organisation. We use them in the organisation that I'm part of; it's a good a way to help us move faster and to share common security baselines.

Alas it turns out that the AzureResourceManagerTemplateDeployment@3 task doesn't presently play well with private Bicep registries. This is because it's necessary to authenticate to a private registry before you can consume modules. And that's not supported by the AzureResourceManagerTemplateDeployment@3 task. What does that mean? Well take a look at the following Azure Pipeline:

- task: AzureResourceManagerTemplateDeployment@3
name: DeployInfra
displayName: Deploy infra
retryCountOnTaskFailure: 3
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'

You'll note that it passes a Bicep file to the csmFile property. This is the file that will be deployed. But what if that file references modules from a private registry? Well, you'll see an error like this:

screenshot of the failing pipeline including the text 'Error BCP192: Unable to restore the module with reference "": Service request failed.'

As you can see from the Status: 401 (Unauthorized), we have an authentication problem; the task doesn't know how to authenticate to the private registry.


You might think, "oh well that's it then, I can't use private Bicep registries with the AzureResourceManagerTemplateDeployment@3 task". But you'd be wrong. There's a workaround. Essentially, when the AzureResourceManagerTemplateDeployment@3 task runs, it attempts to restore the modules it needs as a first step to compiling the Bicep in to ARM. But it only does this if it needs to. If we perform the restore manually first, then the task won't need to do it again. That's the trick.

Before the AzureResourceManagerTemplateDeployment@3 task runs, we can run a task to restore the modules. We can use the AzureCLI@2 task to do this. Here's an example:

- task: AzureCLI@2
displayName: Bicep restore
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.

screenshot of service connection

So if the above task runs prior to the AzureResourceManagerTemplateDeployment@3 task, then the modules will be restored and the AzureResourceManagerTemplateDeployment@3 task will be able to compile the Bicep in to ARM and deploy it to Azure. This solves the problem; albeit at the cost of an extra task in the pipeline.

In the box, in the future?

It would be tremendous if authentication to private Bicep registries was supported by the AzureResourceManagerTemplateDeployment@3 task. I've raised a feature request for this here. If you'd like to see this too, please do add your voice to the issue.