Raised in #84 (comment).

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

It would be great to have a module to simplify role assignments.

Module path

identity/role-assignment

Describe the module

The module contains a role assignment resource. It takes an array of role definition IDs as a parameter to enable batch role assignments.

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

When deploying some Azure services together that use AzureAD for RBAC, it is common to receive errors regarding propagation time.

"Caller is not authorized to perform action on resource. If role assignments, deny assignments or role definitions were changed recently, please observe propagation time."

An example is when Azure Application Gateway is created that uses Key Vault for its SSL Certificates. On some tenants, success rate is at about 20%.

Module path

deployment-scripts/wait

Describe the module

This new module would create a sleep for a configurable number of seconds to be used in other resources DependsOn in order to delay resource creation. EG. wait.bicep

@shenglol

Would it be possible for you to add support around decorator description(''' ''') support for the brm tool?

Example

@description('''
Storage account name restrictions:
- Storage account names must be between 3 and 24 characters in length and may contain numbers and lowercase letters only.
- Your storage account name must be unique within Azure. No two storage accounts can have the same name.
''')
@minLength(3)
@maxLength(24)
param storageAccountName string

It would be awesome if brm generate and brm validate could support such functionality for readme.

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

A similar module exists, with an example of how to run a helm script. But this module provides an easier to use notation for the helm repos.

Module path

modules/deployment-scripts/aks-run-helm

Describe the module

It will provide specific top level input parameters to make it easier to use helm with aks.

| helmRepo | string | No | Public Helm Repo Name |
| helmRepoURL | string | No | Public Helm Repo URL |
| helmApps | array | No | Helm Apps {helmApp: 'azure-marketplace/wordpress', helmAppName: 'my-wordpress'} |

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

To be able to add a DAPR optimised app onto a DAPR Container App Environment ( #118 )

Module path

app/dapr-containerapp

Describe the module

It will focus on the Microsoft.App/containerApps resource, setting DAPR config optimised for the component type patterns used in the #118

It will optionally create a User Assigned Identity (and RBAC) that can pull a container image from a precreated ACR.

The 1.0.1 of the module will be modelled on the 2 most common DAPR application scenarios.

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

We need a module to simplify Resource Group creation.

Module path

resources/resource-group

Describe the module

Taken from the CARML repository, the module contains a Resource Group resource. It sets default values for common properties and allows users to override them via parameters. It further inclused extension resources such as RBAC & locks.

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

We need a module to simplify storage account creation.

Module path

storage/storage-account

Describe the module

The module contains a storage account resource. It sets default values for common properties and allows users to override them via parameters.

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

Split from #60

DeploymentScripts typically require several Azure resources to be deployed together to execute a meaningful deployment (ID, RBAC and the Script Itself). It lends itself to be in a registry because of this nature.

As well as serving as a meaningful module for customers, it will be directly leveraged in the Azure/Aks-Construction repo to reduce complexity in post-deployment automation steps;

• Using the AZ CLI to create self-signed certificates in an Azure Key Vault for use by an Azure Application Gateway Ingress Controller.

DeploymentScripts are a powerful, yet underutilised resource in Arm, we need more living samples of this resource type being used.

Module path

deployment-scripts/create-agw-kv-certificate

Describe the module

A single bicep file that will deploy a managed identity, apply rbac permissions on existing resources and run an Azure CLI script.

The Azure CLI script will

• Instruct KeyVault to create a self signed certificate based on its default certificate policy
• Add either a root or frontend certificate to an existing Application Gateway, referencing the KeyVault certificate

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

We would like to simplify our template here by using a Bicep module. We will then go back and replace the Template with a direct call to the public module.

Module path

modules/azure-gaming/game-dev-vm

Describe the module

This Bicep module makes it easier for users to leverage the Game Dev Virtual Machine on a VM via ARM.
https://docs.microsoft.com/en-us/gaming/azure/game-dev-virtual-machine/

The tags array returned by the MCR API is not sorted. We'll need to sort it locally.

@shenglol I don't know if we already do this in our CI, but it would be good to validate idemopotency for a particular module. Technically this should be implied for any bicep code that deploys once, but we know that is not always the case.

For Deployment Scripts, idempotency in the script will not come for free. It would be good to ensure that these in particular are checked for idempotency.

@shenglol

Could it be possible to extend maxLength for description in metadata.json?

Current is 1000.

In some cases it would be great to have the module detail oriented for the consumer by describing. Then you also have the README.md table and examples for full understanding.

Hi project maintainers and contributors.

Awzm stuff - specially the part around brm tooling. Small gamechanger for me personally (-:

Checked the src, looks like its using some of the functionality as when you are deploying a Bicep file to Azure Resource Manager, just not the build cmdlet when using brm generate and brm validate. All I have to say very good work 💯

Would it be possible to share the .yml that is used for PRs for having all src code used in one place?

Currently the repository is including GH Actions and supporting scripts. But for ADO only the underlaying scripts are there, but the .yml that is using the automagic is not there.

Documentation is currently stating:

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

We need a module to simplify Storage Account creation.

Module path

storage/storageaccounts

Describe the module

Taken from the CARML repository, the module contains a Storage Account resource. It sets default values for common properties and allows users to override them via parameters. It further inclused extension resources such as RBAC, diagnostic settings & locks. It further enables the user to deploy child resources such as containers, queues alongside a rich set of its properties (and their extensions).

Module path

modules/network/virtual-network/

Bicep version

0.12

Describe the bug

While using the virtualNetworks bicep module to in the Azure Quickstarts repo, 'best practice violations' are produced by armttk v0.12.

To reproduce

Azure/azure-quickstart-templates#12704

Code snippet

please see PR

Relevant log output

NestedTemplate [parameters('vnetName')] [ Lines 456 - 854 ]
    [?] apiVersions Should Be Recent (514 ms) 
##[warning]        The apiVersion 2021-05-01 was not found for the resource type: Microsoft.Network/virtualNetworks/virtualNetworkPeerings
##[warning]        The apiVersion 2021-05-01 was not found for the resource type: Microsoft.Network/virtualNetworks/virtualNetworkPeerings
##[warning]        The apiVersion 2021-05-01 was not found for the resource type: Microsoft.Network/virtualNetworks/virtualNetworkPeerings
##[warning]        The apiVersion 2021-05-01 was not found for the resource type: Microsoft.Network/virtualNetworks/virtualNetworkPeerings

   NestedTemplate [format('{0}-virtualNetworkPeering-local-{1}', uniqueString(deployment().name, parameters('location')), copyIndex())] [ Lines 747 - 1145 ]
    [?] apiVersions Should Be Recent (514 ms) 
##[warning]        The apiVersion 2021-05-01 was not found for the resource type: Microsoft.Network/virtualNetworks/virtualNetworkPeerings

   NestedTemplate [format('{0}-virtualNetworkPeering-remote-{1}', uniqueString(deployment().name, parameters('location')), copyIndex())] [ Lines 901 - 1299 ]
    [?] apiVersions Should Be Recent (514 ms) 
##[warning]        The apiVersion 2021-05-01 was not found for the resource type: Microsoft.Network/virtualNetworks/virtualNetworkPeerings

  Parameter Types Should Be Consistent
    [-] Parameter Types Should Be Consistent (357 ms) 
##[error]        Type Mismatch: Parameter 'roleDefinitionIdOrName' in nested template '[format('{0}-VNet-Rbac-{1}', uniqueString(deployment().name, parameters('location')), copyIndex())]' is defined as string, but the parent template defines it as array). Line: 1065, Column: 30
##[error]        Type Mismatch: Parameter 'localVnetName' in nested template '[format('{0}-virtualNetworkPeering-remote-{1}', uniqueString(deployment().name, parameters('location')), copyIndex())]' is defined as string, but the parent template defines it as array). Line: 919, Column: 30
##[error]        Type Mismatch: Parameter 'remoteVirtualNetworkId' in nested template '[format('{0}-virtualNetworkPeering-local-{1}', uniqueString(deployment().name, parameters('location')), copyIndex())]' is defined as string, but the parent template defines it as array). Line: 771, Column: 30
##[error]        Type Mismatch: Parameter 'addressPrefixes' in nested template '[parameters('vnetName')]' is defined as array, but the parent template defines it as string). Line: 480, Column: 22

    [-] Template Should Not Contain Blanks (472 ms) 
##[error]        Empty property:  null Line: 621, Column: 39
##[error]        Empty property:  null Line: 691, Column: 39

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

Adding a new Bicep registry module sample to test the CI.

Module path

samples/array-loop

Describe the module

It's a simple module demonstrating array iterations in Bicep.

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

We need a module to simplify availability set creation.

Module path

compute/availability-set

Describe the module

Taken from the CARML repository, the module contains an Availability Set resource. It sets default values for common properties and allows users to override them via parameters. It further inclused extension resources such as RBAC & locks.

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

We need a module to simplify Virtual Network creation.

Module path

network/virtual-network

Describe the module

Taken from the CARML repository, the module contains a Virtual Network resource. It sets default values for common properties and allows users to override them via parameters. It further inclused extension resources such as RBAC, diagnostic settings & locks. It further enables the user to deploy child resources such as subnets alongside a rich set of its properties.

The ResourceGroup removal logic used in this repo is already very detailed. However, there are a few more modules worth adding to the current removal script.

For example

• KeyVault
• Cognitive Services
• API Management
• Log Analytics Workspaces

If we don't implement a corresponding logic, a 2nd test of e.g. a test file deploying a key vault will fail because it does not automatically recover deleted resources.

To speed things up, I'd suggest to re-use parts of the removal logic used in CARML and align it to the structure used in the Bicep-Registry-Modules repository.

cc: @shenglol, @eriqua

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

We need a module to simplify Managed Identity creation.

Module path

managed-identity/user-assigned-identities

Describe the module

Taken from the CARML repository, the module contains a Managed Identity resource. It sets default values for common properties and allows users to override them via parameters. It further inclused extension resources such as RBAC & locks.

When a module contains a deploymentScript should we expose properties of the deploymentScript resource (cli version, cleanup, retention) or optimize the module contract for the purpose of the workload? IOW, standardize the way modules leverage deploymentScripts and abstract that from the UX.

Exposing the deploymentScript properties creates unnecessary surface area (for failure) and adds to the complexity of the module... also makes it more of a breaking change should the script be replace some day by extensibility or a proper RP. Exposes the implementation, etc.

The flip side is that hardcoding something like CLI version will eventually break the module when an image is retired. Note this will break users regardless but hardcoding means the fix must come in the module itself - rather than user code. We could be proactive on these and ensure that we update before an image is retired.

Same is true for outputs - should we output things that are specific to the deploymentScript resource or only those things that are relevant to the purpose of the module?

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

We would like to simplify our template here by using a Bicep module. We will then go back and replace the Template with a direct call to the public module.

Module path

modules/azure-gaming/game-dev-vmss

Describe the module

This Bicep module makes it easier for users to leverage the Game Dev Virtual Machine on a VMSS cluster via ARM.
https://docs.microsoft.com/en-us/gaming/azure/game-dev-virtual-machine/

On my (draft) PR, the GitHub workflow has failed with an unhelpful message.

Error: Unhandled error: TypeError: core.log is not a function

https://github.com/Azure/bicep-registry-modules/runs/5851365810?check_suite_focus=true#step:3:12

I'm authoring some complex tests for a new module. I've therefore split the tests out into their own files, and referenced them from main.test.bicep

However this does seem to cause the brm validate an issue

dapr-containerapps-environment\test\main.test.bicep" is invalid. Could not find tests in the file. Please make sure to add at least one module referencing the main Bicep file.

Module path

/modules/network/vnet

Bicep version

0.6.18

Describe the bug

bicep resource name is appServiceEnvironment_diagnosticSettings while it should be virtualNetwork_diagnosticSettings

additionally, new diagnosticSettings API (2021-05-01-preview) introduced categoryGroup: 'allLogs' and categoryGroup: 'allMetrics' which simplifies setting up all logs collection into particular destination

To reproduce

https://github.com/Azure/bicep-registry-modules/blob/main/modules/network/virtual-network/main.bicep#L172

Code snippet

No response

Relevant log output

No response

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

Stamping out Container Apps and Container Apps Environments requires lots of repetition.
In the case of DAPR, there are common patterns for the DAPR components that are created in the Container Apps Environment.

These common patterns can be enabled in the module by way of parameters for

• Service bus
• Cosmos
• Blob

Container App Environments also have dependencies on other resources which can be optionally created in the template.

Module path

app/dapr-containerapps-environment

Describe the module

A module that creates the Container App environment with smart defaults for private networking, a log analytics workspace, container registry resources and the relevant DAPR components and configuration. It could also include the creation of the other azure resources but perhaps just passing the resources in by reference would be more suitable.

I've lost count of the number of times that i've done a brm generate in the test folder of a module i'm working on.

Yes i know it's my fault, and i probably should never cd into the test folder.... but you know if brm knows that i'm in a folder called test - it could help me out by asking for confirmation. 😸

Module path

/modules/network/virtual-network/

Bicep version

1.0

Describe the bug

Error BCP192: Unable to restore the module with reference "br:mcr.microsoft.com/bicep/network/virtual-network:1.0": The module does not exist in the registry.

To reproduce

This is reproduced in this PR here, which tries to use this module.
Azure/azure-quickstart-templates#12704

Code snippet

module vnet 'br/public:network/virtual-network:1.0' = {
  name: vnetName
  location: location
  params: {
    name: vnetName
    addressPrefixes: vnetAddressPrefix
    subnets: [
      {
        name                             : subnetName        
        addressPrefix                    : subnetAddressPrefix
        privateEndpointNetworkPolicies   : 'Disabled'
        privateLinkServiceNetworkPolicies: 'Enabled'
        networkSecurityGroupId           : networkSecurityGroup.id
      }
    ]
  }
}

Relevant log output

+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Validate-DeploymentFile.ps1
D:\a\1\test\ci-scripts\Validate-DeploymentFile.ps1 : D:\a\1\s\application-workloads\azure-gamedev\gamedev-vmss\nestedtemplates\virtualNetworks.bicep(14,13) : Error BCP192: Unable to restore the module with reference "br:mcr.microsoft.com/bicep/network/virtual-network:1.0": The module does not exist in the registry.
At D:\a\_temp\d5ef0165-5965-4bc0-8da6-717f071a6137.ps1:3 char:1
+ . 'D:\a\1\test\ci-scripts\Validate-DeploymentFile.ps1'

Hi project contributors and maintainers 😃

What is the benefit of using JSON ARM for the cr (besides source of truth) when the scheme for the module is br (bicep registry)

Since main.json is being uploaded and not main.bicep ❓

And even more interesting since when calling on the JSON ARM module, you are allowed to use the same module definition as Bicep with same params syntax/upbuilding.

Does that mean the json is being decompiled from ARM JSON to Bicep under the upload when using br scheme?

Would be interesting to know why and if users of Bicep should go for this direction instead rather than .bicep

The outputs in the readme.md are autogenerated. Where one of the outputs is an array, it would be great to be able to expand it out.
Eg. For an array of objects, we could list the name and types used.

Problem

When you use brm, it doesn't currently check to see if there's a newer version of itself available.
This will lead to some users unknowingly testing locally with an older version, and then having PR checks fail on module submission. It could also lead to the issue of old (invalid) scaffolds being generated, which then requires troubleshooting.

Solution

When using brm generate/validate, check to see if the local version is the latest version.

Hi,

@shenglol

Have you seen this issue before with the brm validate?

Locally it works fine, but in pipeline context it will throw this out.

I have tried to add .gitattributes file with

* text=auto
*.bicep text eol=lf

Then clone repo again to trigger lf change.

Same issue occurs.

Running git ls-files --eol

Even when setting both bicep and json files to lf manually in VS Code has no improvements.

Do you have any idea how to handle such behavior?

Seems that #66 has been experiencing something similar.

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

I think it would make sense to have all modules from the Common Azure Resource Module Library (CARML) automatically published to the public bicep library, instead of manually tranfering every single module and to avoid duplicates (like we already have with e.g. virtual-network).
The maintenance overhead would be incredibly high and implementing a CI in the CARML repo to automatically push them to the registry on change would be the much better solution.

Module path

provider/module

Describe the module

Respective module description

Context is from here:
#62 (comment)

Basically, for modules that have "prereq" resources, should we require modules to optionally allow either a new resource or an existing one?

This is the case for using a managed identity, which we will see for any resources that support MI. I suspect there other cases - existing Log Analytics workspace, storage accounts, etc.

CARML makes heavy use of "object" and "array of object" parameter types. Here's an example in the network/virtual-network module:

• definition: https://github.com/Azure/bicep-registry-modules/blob/main/modules/network/virtual-network/main.bicep#L11
• usage: https://github.com/Azure/bicep-registry-modules/blob/main/modules/network/virtual-network/main.bicep#L106
• instantiation example: https://github.com/Azure/bicep-registry-modules/blob/main/modules/network/virtual-network/README.md#example-2

While this is good for flexibility, it makes consumption of the module impossible unless you look at the source code or have an example reference.

I recommend we block this pattern until we have full support for custom types, which is tracked here:
Azure/bicep#4158

That may be overly strict. We can wait until we get more feedback before making this decision, but I'd like to get out in front of it or "limit the damage" as much as possible.

Module path

/modules/network/virtual-network

Bicep version

1.0

Describe the bug

Microsoft.Authorization/roleAssignments uses a preview version ( 2021-04-01-preview ) and there are more recent versions available.

To reproduce

Azure/azure-quickstart-templates#12782

Code snippet

see PR

Relevant log output

##[error]        Microsoft.Authorization/roleAssignments uses a preview version ( 2021-04-01-preview ) and there are more recent versions available.
        Valid Api Versions:
        2022-04-01
        2022-04-01
        2022-01-01-preview
        2021-04-01-preview
        2020-10-01-preview

Should we standardize the ordering of the top level keywords in modules? Thinking:

• It's often easier to reason over when this is consistent...
• params/outputs define the contract, having that be easy to discern is useful
• should be easy to automate

Have you checked this module does not already exist in the registry?

Yes

Why is the module needed?

Extension of #60 and #69

DeploymentScripts typically require several Azure resources to be deployed together to execute a meaningful deployment (ID, RBAC and the Script Itself). It lends itself to be in a registry because of this nature.

As well as serving as a meaningful module for customers, it will be directly leveraged in the Azure/Aks-Construction repo to reduce complexity in post-deployment automation steps;

• Using the AZ CLI to leverage the AKS Run Command to install CertManager on the cluster
• Using the AZ CLI to leverage the AKS Run Command to install External-DNS on the cluster
• Using the AZ CLI to leverage the AKS Run Command to install a sample application (the Azure Vote App) on the cluster
• Using the AZ CLI to leverage the AKS Run Command to query the Kubernetes events for Warnings

Module path

deployment-scripts/aks-run-command

Describe the module

A single bicep file that will deploy a managed identity, apply rbac permissions on existing resources and run an Azure CLI script.

The Azure CLI script will

• Invoke the AKS Run Command, relaying the command it has been provided with

when modules offer the capability to use existing resource or create new ones various information is required via params... usually:

• some flag indicating new vs. existing
• resource name
• resource rg
• resource subId

Should we standardize the way these patterns are implemented? Including things like:

• is the default new or existing?
• is the name of the flag param consistent (e.g. createNewMSI vs. useExistingMSI) if we pick a default seems we must do this as well
• should rg/sub params default to the current scope (resourceGroup().name, subscription().id)
• should the name have a defaultValue (which likely never works with existing but always works with new)
• should the name param and the rg/sub param be similarly named? E.g. managedIdentityName and then (managedIdentityResourceGroup vs. existingManagedIdentityResourceGroup)

Makes it really elegant to understand how the params work - knowing what a defaultValue is on a module is pretty important... but this creates a maint issue. We could automate any changes to a defaultValue must also acompany a readme change (or just automate that part of the readme (assuming we aren't already)).

could also help address this with tooling support...

test

The newer version of brm requires the metadata.json file to use a summary property as opposed to description.

1. The schema referenced by https://aka.ms/bicep-registry-module-metadata-file-schema still points to the old schema with description. This causes VSCode to indicate a problem with the metadata file, and causes the .

Additionally;
brm doesn't currently check to see if there's a newer version of itself available. This will lead to some users unknowingly testing locally with an older version, and then having PR checks fail on module submission.

Have you checked this module does not already exist in the registry?

• Yes

Why is the module needed?

DeploymentScripts typically require several Azure resources to be deployed together to execute a meaningful deployment (ID, RBAC and the Script Itself). It lends itself to be in a registry because of this nature.

As well as serving as a meaningful module for customers, it will be directly leveraged in the Azure/Aks-Construction repo to reduce complexity in post-deployment automation steps;

• Using the AZ CLI to Import Azure Container Registry images as part of a bicep deployment (post ACR creation)
• Using the AZ CLI to create certificates in an Azure Key Vault for use by an Azure Application Gateway Ingress Controller.

A sample could also be added to the readme to show;

• Seeding an ACR with Bicep modules from the MCR

DeploymentScripts are a powerful, yet underutilised resource in Arm, we need more living samples of this resource type being used.

Module Paths

deployment-scripts/acr-import

Describe the modules

A single bicep file that will deploy a managed identity, apply rbac permissions on existing resources and run an Azure CLI script (either inline or linked)

Have you checked this module does not already exist in the registry?

• Yes

Why is the module needed?

To expedite the creation of API applications that use a serverless pattern.
Tech stack targets FunctionApps for compute and CosmosDb for db storage.
Observability is implemented in various azure services.

Module Paths

app/apim-cosmos-functionapp

Describe the modules

The main module takes a GitHub repo url (and branch names) and does a full infra deployment, binding the slots to staging/production in the repo.

• Azure APIM is deployed with an independent REDIS cache
• Web tests are created on internet accessible web/api endpoints for completeness.
• Application secrets are stored in Key Vault, and secrets are added securely in the CosmosDb module.

It would be most of what is documented in this repo: https://github.com/Gordonby/AzureBicepServerlessAppStack

During PR of #63 an error is raised

Run brm validate
The file "/home/runner/work/bicep-registry-modules/bicep-registry-modules/modules/resources/deployment-scripts-import-acr/main.json" is modified or outdated. Please regenerate the file to fix it.

However the file is up to date, and local validation succeeds

Have you checked this module does not already exist in the registry?

Yes. Some overlap foreseen with VNET & Resource Group modules. However, our modules wrap these as are at a higher level than individual resources.

Why is the module needed?

Help customers deliver the ALZ (Azure Landing Zone) reference architecture using the Bicep modules from the ALZ-Bicep repository, supported by CAE team (WW CSU).

This will form another consumption method to meet more customers where they want to consume the modules from as per https://github.com/Azure/ALZ-Bicep/wiki/ConsumerGuide

Modules paths

Describe the modules

As mentioned above this will form another consumption method to meet more customers where they want to consume the modules from as per https://github.com/Azure/ALZ-Bicep/wiki/ConsumerGuide to deploy the ALZ (Azure Landing Zone) architecture using the existing ALZ-Bicep modules.