Using Shared Variable File Pattern to simplify Azure Roles In Bicep

Photo of author

Dan Rios

📅

🔄

3 minute read

Azure Roles in Bicep – whenever I’m working with role assignments in Infrastructure as Code, I usually find myself checking AzRolesAdvertizer to get the correct role GUID for my assignments. This can become a tedious task, often repeated across many new templates especially when dealing with less common roles.

Thankfully, there’s a solution: leveraging the shared variable file pattern in Azure Bicep.

Azure roles json shared file pattern
Soon, this feature will be built-in to Bicep as a function: https://github.com/Azure/bicep/issues/16867 but currently, at the time of writing it’s still in development. I will update this post when it’s live!

Azure Roles Shared Pattern in Bicep

If you’re unsure about what the pattern is and how it can be beneficial in Bicep, check out an earlier blog I wrote on it.

I recently came across this repository from Microsoft: https://github.com/microsoft/azure-roles. It curates a list of all current Azure roles, adding new ones daily to a JSON file in the GitHub project. This means you can use the shared variable file pattern in Bicep to centrally reference any role you want and even better, you’ll get IntelliSense auto-completion to help you search as well.

Steps to try it out:

  1. Copy the azure-roles.json file to your repository.
  2. Create a variable to load the Azure roles JSON file.

Now, you can type your variable and search for Azure RBAC roles directly in VS Code for a much smoother experience.

Azure Roles in Bicep

Automation with Azure DevOps

Prerequisites

  • Service connection created with federated credentials.
  • Build service requires Contribute, Pull Request, and Branch permissions. However, for production scenarios, it’s recommended to shift to a dedicated service principal for improved pipeline security.

You can take this further by automating a nightly build in Azure DevOps for your Bicep projects. I’ve modified the original create-azureroles.ps1 script from the GitHub project to work with Azure DevOps federated credentials. This runs on a nightly pipeline cron job and automatically creates a pull request with any new roles to be added!

Azure Roles Pipeline run

Here’s the modified PowerShell script. You’ll just need to update the Git config details on lines 53/54. Otherwise, simply save it wherever you prefer in your repository structure.

TL;DR: This script does everything the existing one in the Microsoft Azure Roles repo does, but with a few enhancements: it now creates a branch, commits the updated file, and raises a pull request containing details of any new roles being added. This way, you can fully automate role file updates in your Bicep projects!

Next up is the Azure DevOps pipeline YAML I’ve put together. Since I’m using federated credentials, I can take advantage of Azure DevOps predefined variables (such as tenantId, applicationId, and the federated token) to connect to Azure for the role checks.

The pipeline is scheduled to run nightly and will execute the PowerShell script mentioned above (be sure to amend the file paths to suit your setup). The only details you’ll need to update are the service connection name on line 19 and the Git config settings.

In Action – Pull Request

When testing this method, I removed a role from the latest azure_roles.json file and then ran the pipeline. It correctly picked up two new roles the one I had deleted, plus a genuinely new one and provided a clear description showing exactly what was being added.

That’s it! Now you have two pretty awesome enhancements to your Bicep projects:

  • A curated list of all Azure Roles with their corresponding GUIDs to use in Bicep Shared Variable File Pattern
  • Automated approach to updating the file daily through Azure DevOps pipelines with nightly schedule

I think I’d like to try and contribute back to the repository so the script can be available there for Azure DevOps folks to use. If you are using GitHub then the current workflow can be found in the repository to be adopted already, but it doesn’t use federated credentials (maybe someone can modify that one next!).

Leave a comment