Bicep Registry
Recently Microsoft released a new feature concerning Bicep called private registry for Bicep modules or Bicep private registry / Bicep registry for short. In essence this means storing Bicep modules in an Azure Container Registry (ACR). Using Bicep modules is a way to modularize Bicep code.
One of the benefits of a Bicep registry is sharing these Bicep modules inside (or even outside) your company. While you can share code in Azure DevOps or Github directly, an ACR is an Azure resource and because of this, it utilizes Azure RBAC to control who has access. With Bicep registries this basically means anyone who has push permissions to the ACR can push/write Bicep modules into the ACR and anyone with pull permissions can read the module files. When modules are in a Bicep registry ‘reading’ is called ‘restoring’.
Reading modules files is necessary when a Bicep file with a reference to a module is being transpiled into an ARM template. Transpiling can be done explicitly with the bicep build command, but this functionality is also incorporated in New-Az<scope>Deployment (pwsh) and az deployment <scope> create (az CLI) commands. These commands transpile the Bicep code to an ARM template and immediately deploys the ARM template to the target environment in one go.
Deploy cross tenant
So lets say we have a tenant A where a Bicep registry is deployed with Bicep modules. But we want to deploy a main.bicep file, with references to modules in the Bicep Registry, to tenant B. This means we need to have pull permissions to the ACR in tenant A while transpiling, and permissions to deploy to tenant B…while deploying.
There are multiple ways to solve this problem actually, but first, lets see what is happening exactly. When using Bicep registries, there is an option in the Bicep config file to decide the precedence of credentials to be used for authenticating to the Bicep registry. Here you can specify ‘AzureCLI’ or ‘AzurePowerShell’ for example. This means that when transpiling, Bicep is checking the token caches of theses tools to try to connect to the ACR.
When using New-Az<scope>Deployment (pwsh) or az deployment <scope> create (az CLI) commands to deploy a Bicep file, the step to transpile and deploy is the same. This means the used credentials need to have permissions on both the ACR and the target environment to deploy to. And here enters.. Azure Lighthouse.
If you are not familiar with this, the concept is basically: give principals (users/groups/service principals) from tenant X permissions to Azure resources in tenant Y. The Azure Lighthouse service is especially beneficial for MSPs who are managing a multitude of customer environments.
You might already see where I’m heading with this.
The idea is to give the account used for deploying in tenant B, pull permissions with Azure Lighthouse to the ACR in tenant A. And this in fact works like a charm.
DevOps
While the above method works for regular accounts, it works for Azure DevOps service connections too!! as they use SPNs to authenticate. Just hand over ACR pull permissions of the Bicep registry in tenant A to the service principal (SPN), used by the Azure DevOps service connection, in tenant B with Azure Lighthouse.
Code samples
And no better way to deploy a Lighthouse delegation than with Bicep of course.
Here are some Bicep files to deploy a Lighthouse delegation (definition and assignment) to a resource group. The assignment module file is placed into its own Bicep module and should be stored alongside this Bicep file. The idea is to target the deployment to resource group where the ACR resides.
N.B. The code does not work out of the box. Fill in where comments are placed.
1targetScope = 'subscription'
2
3@description('Specify a unique name for your offer')
4param mspOfferName string = 'bicepAcrDelegation'
5
6@description('Name of the Managed Service Provider offering')
7param mspOfferDescription string = 'bicepAcrDelegation'
8
9@description('Specify the tenant id of the Managed Service Provider')
10param managedByTenantId string //fill in guid tenant Id
11
12@description('Specify an array of objects, containing tuples of Azure Active Directory principalId, a Azure roleDefinitionId, and an optional principalIdDisplayName. The roleDefinition specified is granted to the principalId in the provider\'s Active Directory and the principalIdDisplayName is visible to customers.')
13param authorizations array = [
14 {
15 'principalId': //fill in objectId of principal who should get permission
16 'roleDefinitionId': '7f951dda-4ed3-4680-a7ca-43fe172d538d' //current guid is acrpull
17 'principalIdDisplayName': //fill in descriptive name
18 }
19]
20param rgName string = 'bicepregistry'
21
22var RegistrationName = guid(mspOfferName)
23var AssignmentName = guid(mspOfferName)
24
25resource acrDelegationDefinition 'Microsoft.ManagedServices/registrationDefinitions@2020-02-01-preview' = {
26 name: RegistrationName
27 properties: {
28 registrationDefinitionName: mspOfferName
29 description: mspOfferDescription
30 managedByTenantId: managedByTenantId
31 authorizations: authorizations
32 }
33}
34
35module acrDelegationAssignment './acrDelegationAssignment.bicep' = {
36 name: AssignmentName
37 scope: resourceGroup(rgName)
38 params: {
39 AcrDefintitionresourceId: acrDelegationDefinition.id
40 AssignmentName: AssignmentName
41 }
42}
43
44output mspOfferName string = 'Managed by ${mspOfferName}'
45output authorizations array = authorizations
1//acrDelegationAssignment.bicep (use this filename!)
2targetScope = 'resourceGroup'
3
4param AcrDefintitionresourceId string
5param AssignmentName string
6
7resource acrDelegationAssignment 'Microsoft.ManagedServices/registrationAssignments@2019-06-01' = {
8 name: AssignmentName
9 properties: {
10 registrationDefinitionId: AcrDefintitionresourceId
11 }
12}
This Lighthouse delegation only needs to happen once, but needs to be deployed to tenant A. When that’s set it’s possible to deploy resources, like this storage account, to tenant B, where the bicep registry resides in tenant A:
1//main.bicep
2targetScope = 'resourceGroup'
3
4param name string
5
6module mySa 'br:jannicksbicepreg.azurecr.io/bicep/modules/storage:v1' = {
7 name: name
8 params: {
9 kind: 'StorageV2'
10 saname: '${name}${uniqueString(name)}'
11 sku: {
12 name: 'Standard_LRS'
13 }
14 tags: {
15 env: 'dev'
16 }
17 }
18}
Here is an example of the pipeline yaml:
1trigger: none
2
3pool:
4 vmImage: ubuntu-latest
5
6jobs:
7- job:
8 steps:
9 - task: AzureCLI@2
10 inputs:
11 azureSubscription: 'bicepAcrLighthouseTestServiceConnection' #Tenant B
12 scriptType: 'bash'
13 scriptLocation: 'inlineScript'
14 inlineScript: 'az bicep upgrade'
15 - task: AzureCLI@2
16 inputs:
17 azureSubscription: 'bicepAcrLighthouseTestServiceConnection' #Tenant B
18 scriptType: 'bash'
19 scriptLocation: 'inlineScript'
20 inlineScript: |
21 az deployment group create \
22 --name $(Build.BuildNumber) \
23 --resource-group jannickbiceptest \
24 --template-file main.bicep
When the permissions (with Azure Lighthouse) are not in place there is this error message:
ERROR: /home/vsts/work/1/s/main.bicep(6,13) : Error BCP192: Unable to restore the module with reference “br:jannicksbicepreg.azurecr.io/bicep/modules/storage:v1”: Unhandled exception: Azure.RequestFailedException: Service request failed.
This could mean the Lighthouse delegation was either not successful or was revoked.
Keep an eye on Barbara 4bes’ blog to find out another way to solve this problem.