role assignment in bicep

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Quickstart: Assign an Azure role using Bicep

• 3 contributors

Azure role-based access control (Azure RBAC) is the way that you manage access to Azure resources. In this quickstart, you create a resource group and grant a user access to create and manage virtual machines in the resource group. This quickstart uses Bicep to grant the access.

Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. Bicep offers the best authoring experience for your infrastructure-as-code solutions in Azure.

Prerequisites

To assign Azure roles and remove role assignments, you must have:

• If you don't have an Azure subscription, create a free account before you begin.
• Microsoft.Authorization/roleAssignments/write and Microsoft.Authorization/roleAssignments/delete permissions, such as Role Based Access Control Administrator .
• To assign a role, you must specify three elements: security principal, role definition, and scope. For this quickstart, the security principal is you or another user in your directory, the role definition is Virtual Machine Contributor , and the scope is a resource group that you specify.

Review the Bicep file

The Bicep file used in this quickstart is from Azure Quickstart Templates . The Bicep file has two parameters and a resources section. In the resources section, notice that it has the three elements of a role assignment: security principal, role definition, and scope.

The resource defined in the Bicep file is:

• Microsoft.Authorization/roleAssignments

Deploy the Bicep file

Save the Bicep file as main.bicep to your local computer.

Deploy the Bicep file using either Azure CLI or Azure PowerShell.

Replace <principal-id> with the principal ID assigned to the role.

When the deployment finishes, you should see a message indicating the deployment succeeded.

Review deployed resources

Use the Azure portal, Azure CLI, or Azure PowerShell to list the deployed resources in the resource group.

Clean up resources

When no longer needed, use the Azure portal, Azure CLI, or Azure PowerShell to remove the role assignment. For more information, see Remove Azure role assignments .

Use the Azure portal, Azure CLI, or Azure PowerShell to delete the resource group.

Tutorial: Grant a user access to Azure resources using Azure PowerShell

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

Azure and automation

Create role assignments for different scopes with Bicep

When you create Azure resources with Bicep, you are able to set up role assignments as well. This can be very useful in different scenario’s as it enables you to add an extra layer to your infra as code, which you don’t have to perform manually or through other automation. A role assignment is a resource when you use it in Bicep and can be defined as such, but handling the different scope levels can be a challenge. That is why in this post, I will explain how to create role assignments for different scopes with Bicep.

Before you read on, I recommend you scan through this page in the Microsoft Docs , which gives a great explanation of the different properties of a role assignment. In this post, we will focus on how to handle the scope. To do so, I will walk through all scopes with examples of how a template could be deployed.

Management Group Scope

Let’s start with the biggest scope we have available in Azure resource manager: Management Group. This is how you define the role assignment in Bicep:

To deploy it and set the parameters, you can use different methods. For this post I have used PowerShell. As you can see, you need to define the Id for both the roledefinition and the principalID. To make this a bit easier and more readable, I have made use of Get-AzADUser and Get-AzRoleDefinition

Deployment would go like this:

This deployment would refer to the file rbac-mg.bicep , which it will use to give the user [email protected] the reader role over the management group exampleGroup. Of course you change the values to your own use case.

Subscription scope

So how do we do the same for a subscription? Fortunately, we don’t have to make that many changes. We change the following values:

• Change targetScope = 'managementGroup' to targetScope = 'subscription'
• managementGroup()   is changed to subscription()
• managementGroup().id is changed to subscription().subscriptionId

This is all we have to do for the Bicep template. You can find the new template here .

Note: if you don’t define the targetscope, it will by default use the subscription if you use New-AzDeployment. But for readability, you could consider specifying it anyway.

As for the PowerShell deployment, that would now look like this:

The role assignment will be deployed to the current scope of the PowerShell session, which you can find by using Get-AzContext .

Resource Group Scope

The resource scope is very similar to the subscription scope. Again, you change the targetscope and the references from subscription() to  resourcegroup() .  And for resource groups as well you are able to leave out the targetscope, but you could consider adding it for readability.

To see what the Bicep file would look like, click here .

And deployment would go like this:

Resource scope

A resource resource role assignment is a little different than the previous deployments. You need to refer to the resource within the role assignment, which you do with the scope parameter. To show how it works, I have used a storage account as an example.

A role assignment to a resource has a different use case than to one of the other scopes. If you are doing an assignment for users, a Resource scope is possible, but can make your environment very complicated. It is recommended to keep the assignments at a higher level. That is different for managed identities or service principles. They need the least amount of principal and could be set on a resource level. An example is a key vault, where you want the role assignment to be very specific.

This is what the bicep file could look like:

I have removed all flexibility in the storage account to keep the focus. In production, you would want some flexibility in the properties of the storage account.

Deployment is the same method as the resource group scope:

Deployment in Modules

This is all cool, but one of the great things about Bicep is the use of modules! So how would you do that? For Management groups, subscriptions, or resource groups, that is pretty straight forward. All of the above files can be used as a module and deployed from a different file with the following syntax:

Now with Resources, it is a little more difficult. As we have seen before, you have to define the scope within the role assignment. You are not able to use a parameter for this scope, as it needs the resource itself as a scope. This makes it more difficult to provide flexibility. Even if you would consider making use of the existing option, you wouldn’t get flexibility as you need to define the resource type there. So how doe we make sure we don’t have to create a separate rbac-module for every resource type?

The answer can be found in the files in the brand new public registry : you make the role assignment a part of the resource module. So in this case, for every storage account you provide the option to add a role assignment in the module file.

But you still need flexibility. Flexibility to not create a role assignment or to create multiple. Again, we can find a great method at the public registry : we use a for loop that is empty by default. If the role assignment is not needed, just don’t add it as a parameter. If you need more than one, you add them as an array. Let’s see how that would look.

The template

Although the registry uses a submodule, I prefer to add it straight to the resource. This is how the module for a storage account would look:

If we want to create the resource without role assignment, we just omit the roleAssignments parameter. If we do want to create one (or multiple), our main.bicep file would refer to it like this:

By using this method for every resource you have in a module, you will have some duplicate code, but you won’t have a separate rbac-module for every resource type. This will keep your module files clean but still provide flexibility.

So this is how you create role assignments for different scopes with Bicep. You can find all the complete Bicep files that are referred to here .

If you want to learn more about Bicep, follow along with the LearnLive series that are running right now: https://aka.ms/learnlive-iac-and-bicep

Related Posts:

I’m also having a problem with the scope of a role assignment. Your post was helpful, but I do have one question. For the example for management group scope, there’s a parameter called “ManagementGroupId”, but it doesn’t seem to be used. I see the role definition is created a the management group level. Is the role assignment also defined at the management group level by default? I assume that’s the case since the targetScope = “managementGroup”. Thanks.

Great article Barbara. Thanks so much!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Assign Azure Privileged Identity Management Roles using Bicep

Azure Privileged Identity Management (PIM) is a tool that allows you to provide Just In Time (JIT) access to Azure RBAC roles. Using PIM, you can create a role assignment to make a user or group eligible for a role. This assignment doesn’t mean that the user or group has the role, but instead that they can request the role when they need it. When this occurs, the user can trigger an elevation request to be granted the role for a short period (usually hours, but definable). Rules can then be applied to their request, such as requiring approval, requiring a ticket number and so on, and then the rights are granted. PIM is a great tool for removing many permanent access rights to users, but it does require an Azure AD P2 licence for each user.

PIM is an Azure AD feature, so I assumed it wouldn’t be possible to create PIM assignments using Bicep (or ARM), but it is possible. PIM roles are often application or service-specific, so being able to create them as part of your Infrastructure as Code is quite helpful.

Creating PIM Assignments

To create a PIM assignment, we are going to use the Microsoft.Authorization/roleEligibilityScheduleRequests , the full API sec for this can be found here . This object can be used for more than just creating an assignment, it can, in theory, be used to activate an assignment, remove assignments and more. We’ll focus on creating and updating assignments.

To be able to use this, we are going to need a couple of pieces of information:

The object ID of the user or group you want to assign the role to. This can be found by looking at the user or group in AAD. You’re looking for the object ID field

The complete ID of the role you want to assign. This is usually in the format:

Subscription ID is the ID of the subscription holding the role you want to assign. The role ID is the GUID of the role. You can find the GUID’s for all the built-in roles in the MS docs here , or you can also use the handy AzRoleAdvertizer site . If you’re applying the assignment at the management group rather than subscription or resource, you will replace this with the ID of the management group role.

With this information, we can create the Bicep code we need. First, we need to get the start date for the role in the correct format. The format is 2022-04-10T14:40:08.067566 but fortunately, the Bicep utcNow function gets this in the correct format, so we can use that. This function can only be used as a default value for a parameter, so we need to create a parameter in our template that we assign this to and won’t override in the future.

Now we have that we can create the actual resource:

A few things to note:

• The name needs to be a GUID, so I am using the guid function to generate one, passing the resource group and a string as a seed to ensure a consistent GUID generation should I run this again
• The request type is set to AdminUpdate. This will create a role if it doesn’t exist and update it if it does. You can use AdminCreate if you want only to create it.
• The schedule info section is setting that the user or group should be eligible to elevate for a year (the max allowed) before the role needs to be reviewed
• I have set the scope to be the resource group. This defines that the PIM role should be for this resource group only. If I wanted to assign rights to elevate over a whole subscription or management group, then I would adjust the scope

The whole template looks like this:

Once deployed, you should be able to go to the PIM UI in the portal and see that the designated user or group is now eligible to elevate to this role.

Permissioning Azure Pipelines with Bicep and Azure RBAC Role Assignments

How can we deploy resources to Azure, and then run an integration test through them in the context of an Azure Pipeline? This post will show how to do this by permissioning our Azure Pipeline to access these resources using Azure RBAC role assignments. It will also demonstrate a dotnet test that runs in the context of the pipeline and makes use of those role assignments.

We're following this approach as an alternative to exporting connection strings , as these can be viewed in the Azure Portal; which may be an security issue if you have many people who are able to access the portal and view deployment outputs.

We're going to demonstrate this approach using Event Hubs. It's worth calling out that this is a generally useful approach which can be applied to any Azure resources that support Azure RBAC Role Assignments. So wherever in this post you read "Event Hubs", imagine substituting other Azure resources you're working with.

The post will do the following:

• Add Event Hubs to our Azure subscription
• Permission our service connection / service principal
• Deploy to Azure with Bicep
• Write an integration test
• Write a pipeline to bring it all together

Add Event Hubs to your subscription ​

First of all, we may need to add Event Hubs to our Azure subscription.

Without this in place, we may encounter errors of the type:

##[error]MissingSubscriptionRegistration: The subscription is not registered to use namespace 'Microsoft.EventHub'. See https://aka.ms/rps-not-found for how to register subscriptions.

We do this by going to "Resource Providers" in the Azure Portal and registering the resources you need. Lots are registered by default, but not all.

Permission our service connection / service principal ​

In order that we can run pipelines related to Azure, we mostly need to have an Azure Resource Manager service connection set up in Azure DevOps. Once that exists, we also need to give it a role assignment to allow it to create role assignments of its own when pipelines are running.

##[error]The template deployment failed with error: 'Authorization failed for template resource {GUID-THE-FIRST} of type Microsoft.Authorization/roleAssignments . The client {GUID-THE-SECOND} with object id {GUID-THE-SECOND} does not have permission to perform action Microsoft.Authorization/roleAssignments/write at scope /subscriptions/\*\*\*/resourceGroups/johnnyreilly/providers/Microsoft.EventHub/namespaces/evhns-demo/providers/Microsoft.Authorization/roleAssignments/{GUID-THE-FIRST} .'.

Essentially, we want to be able to run pipelines that say "hey Azure, we want to give permissions to our service connection". We are doing this with the self same service connection, so (chicken and egg) we first need to give it permission to give those commands in future. This is a little confusing; but let's role with it. (Pun most definitely intended. 😉)

To grant that permission / add that role assignment, we go to the service connection in Azure Devops:

We can see there's two links here; first we'll click on "Manage Service Principal", which will take us to the service principal in the Azure Portal:

Take note of the display name of the service principal; we'll need that as we click on the "Manage service connection roles" link, which will take us to the resource groups IAM page in the Azure Portal:

Here we can click on "Add role assignment", select "Owner":

Then when selecting members we should be able to look up the service principal to assign it:

We now have a service connection which we should be able to use for granting permissions / role assignments, which is what we need.

Event Hub and Role Assignment with Bicep ​

Next we want a Bicep file that will, when run, provision an Event Hub and a role assignment which will allow our Azure Pipeline (via its service connection) to interact with it.

Do note that our bicep template takes the service principal id as a parameter. We're going to supply this later from our Azure Pipeline.

We're now going to write a dotnet integration test which will make use of the infrastructure deployed by our Bicep template. Let's create a new test project:

We'll create a test file called EventHubTest.cs with these contents:

Let's talk through what happens in the test above:

• We read in Event Hub connection configuration for the test from environment variables. (These will be supplied by an Azure Pipeline that we will create shortly.)
• We post a message to the Event Hub.
• We read a message back from the Event Hub.
• We confirm that the message we read back matches the one we posted.

Now that we have our test, we want to be able to execute it. For that we need an Azure Pipeline!

Azure Pipeline ​

We're going to add an azure-pipelines.yml file which Azure DevOps can use to power a pipeline:

When the pipeline is run, it does the following:

• Gets the service principal id from the service connection.
• Compiles our Bicep into an ARM template
• Deploys the compiled ARM template to Azure
• Installs the dotnet SDK
• Uses the Azure CLI task which allows us to access service principal details in the pipeline to run our dotnet test.

We'll create a pipeline in Azure DevOps pointing to this file, and we'll also create the variables that it depends upon:

• azureResourceGroup - the name of your resource group in Azure where the app will be deployed
• location - where your app is deployed, eg northeurope
• serviceConnection - the name of your AzureRM service connection in Azure DevOps
• subscriptionId - your Azure subscription id from the Azure Portal
• tenantId - the Azure tenant id from the Azure Portal

Running the pipeline ​

Now we're ready to run our pipeline:

Here we can see that the pipeline runs and the test passes. That means we've successfully provisioned the Event Hub and permissioned our pipeline to be able to access it using Azure RBAC role assignments. We then wrote a test which used the pipeline credentials to interact with the Event Hub. To see the repo that demostrates this, look here .

Just to reiterate: we've demonstrated this approach using Event Hubs. This is a generally useful approach which can be applied to any Azure resources that support Azure RBAC Role Assignments.

Thanks to Jamie McCrindle for helping out with permissioning the service connection / service principal. His post on rotating AZURE_CREDENTIALS in GitHub with Terraform provides useful background for those who would like to do similar permissioning using Terraform.

• Add Event Hubs to your subscription
• Event Hub and Role Assignment with Bicep
• Azure Pipeline
• Running the pipeline

Standard way

All examples that you find in the documentation (like this one ), require you to pass the Role Definition Id.  This Id can be found on this page that lists all built-in Azure roles.

Although this works, it’s a cumbersome experience to look up the Role Definition Id and pass it to the role assignments.

Community alternatives

In the community, people came up already with solutions that simplify this:

• Great approach, but cannot be used from within another Bicep template, because of the PowerShell requirement
• A pure Bicep approach, user-friendly, but quite some work to setup

Generate the Bicep module

I wanted to have a Bicep module to perform role assignments on resource group level, similar like Jos described in his blog post.  It had to support all available Azure roles.  Instead of plumbing it myself, I created a simple PowerShell script that generates the Bicep module, based on a template with place holders.  It also includes custom roles that you might have configured in your Azure environments.

The resulting module can be found here or on my GitHub :

This role assignment module gives you auto-complete with all available roles.  Combined with the VS Code extension, this gives a superb developer experience:

Like often, some automation can make your life just easier!  I hope you’ve enjoyed this one!

UPCOMING TRAININGS

CHECK OUT OUR TRAININGS

Azure Integration Services

Azure migration.

• Azure Governance

Azure Security

Azure foundations, recent posts.

• Azure Service Bus vs Event Grid Pull Delivery
• Trying the new Microsoft Applied Skills
• Finally a correct way to configure RBAC for DevOps agents!
• What do the new API Management v2 tiers mean for you?
• Validate payloads in Azure API Management
• Announcement
• API Management
• Architecture
• Azure App Service
• Azure Data Factory
• Azure DevOps
• Azure Event Grid
• Azure Functions
• Azure Kubernetes Service
• Azure Policy
• Azure Resource Graph
• Azure Resource Manager
• Azure Service Bus
• Azure Stream Analytics
• BizTalk Server
• Container Apps
• Geen categorie
• Home Automation
• Microsoft Learn
• Service Bus

MEET THE YOUR AZURE COACH TEAM

Your Azure Coach is specialized in organizing Azure trainings that are infused with real-life experience. All our coaches are active consultants, who are very passionate and who love to share their Azure expertise with you.

Toon Vanhoutte

Azure integration services & serverless.

Wim Matthyssen

Azure infra, security & governance, azure development and ai/ml, azure identity and security, stéphane eyskens, cloud-native azure architecture, geert baeke, azure kubernetes service & containerization, maik van der gaag, azure infrastructure as code & devops, bart verboven, sammy deprez, azure ai, ml & cognitive services, sander van de velde.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Assigning RBAC via Role Assignment Module #5678

JFolberth Jan 19, 2022

Beta Was this translation helpful? Give feedback.

So I ended up taking thoughts from a few folks and leveraged modules to handle nesting each loops. Did this as wanted the parameter file to be simpler for maintenance/scalability. This as of now is only for the subscription.

parameters.json:

Replies: 4 comments · 17 replies

Slapointe jan 19, 2022.

JFolberth Jan 20, 2022 Author

bansioza44 Mar 30, 2023

brwilkinson Mar 30, 2023 Maintainer

davidkarlsen May 24, 2023

Slapointe jan 20, 2022, {{editor}}'s edit, brwilkinson jan 24, 2022 maintainer, jfolberth jan 24, 2022 author, azmantas jan 23, 2022, brwilkinson feb 2, 2022 maintainer, jfolberth feb 3, 2022 author.

This discussion was converted from issue #5669 on January 19, 2022 21:52.

• Numbered list
• Unordered list
• Attach files

Select a reply

Easy way to set Azure RBAC roles in Bicep

When deploying resources in Azure using Bicep, occasionally you will have to assign rights to a user or principal to perform certain actions. For example, authorizing an app service to access a storage account.

Initially you would create something like this:

I came up with the following Bicep module which shows a nice way to hide the nasty details such as the role guids in a module.

This makes the Bicep files a lot more readable, especially when you have to assign roles more often.

Creating a module to do this also has the advantage that you can change the scope, for example when the storage account is part of a different resource group.

Cleaned up initial example:

I hope someone has some use for this as well.

Update 18-07-2023: Updated to include principalType in template.

Azure Bicep & User Assigned Managed Identity

This will be a quick one!

A colleague asked me if it was easier to use user assigned managed identities in Bicep versus ARM. Well, challenge accepted!

After about 45 minutes of hacking, I created the following:

Key things to point out here with the web app config:

• The set of lines userAssignedIdentities: { '${uami.id}': {} } are where you associate the user-assigned identity id with the web app
• You also need the line keyVaultReferenceIdentity: uami.id to tell the app service which identity to use when contacting the key vault

Cool stuff!

John Folberth

Resources and posts for those figuring out DevOps in Azure

• Professional

Assigning Cosmos Data Plane Roles via RBAC w/ Bicep

Introduction

If one wasn’t already aware, CosmosDB has the ability to assign built in RBAC roles scoped to the account, database, and the container. When trying to achieve this via Bicep I quickly discovered there really wasn’t much content on this topic. In fact the majority of the content on this topic revolved around leveraging the creation of customer Cosmos role definitions. Hopefully this article will help provide some clarity. For this post I designed this as a module in a bicep registry. Full code can be found on my bicep_registry repository.

If you weren’t aware CosmosDB currently provides t wo built in RBAC roles . Cosmos DB Built-in Data Reader and Cosmos DB Built-in Data Contributor . Just as described one is read only and one is for data operations.

These roles are beneficial as we don’t have to create a custom definition and then worry about maintaining it. Using a built in role is typically the preferred approach as they are viewed as more secure and can configured in any Azure subscription.

These data plane RBAC roles differ significantly in terms of resource configuration than from normal Azure build-in roles . The main reason being, the traditional RBAC roles, are stored behind the Microsoft.Authorization resource provider. For example here is the resource ID for the built in contributor role: /providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c

Cosmos RBAC roles use a different provider for the role definition id. These role definitions are a sub resource of the actual database account. Thus they are formated as: /subscriptions/<mySubscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.DocumentDB/databaseAccounts/<myCosmosAccount>/sqlRoleDefinitions/<roleDefinitionId>

This means to retrieve or use the built in RBAC roles for Cosmos we will need to know the subscriptionid, resource group name, account name, and the role definition id.

Role Assignment

Since the built in RBAC roles for Cosmos are technically a sub resource of the cosmos account this means we will need to ensure that the assignment is either nested in the cosmos account creation or has the account listed as the resource parent.

I prefer the parent approach as this will provide us the ability to leverage the RBAC assignment as a module and thus can call it infinite amount of times.

The other tricky part was finding the above roleDefinitionId. The 'Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments requires the resource id of the build in role definition id. This wasn’t straight forward in the documentation I have since updated it .

Here is my entire Cosmos SQL Role Assignment Module:

The complete module can be found here .

I did discover/realized during this process that at this time only User Assigned Identities can be provisioned the RBAC role. When I attempted this with a System Managed Identity access was not granted.

Cosmos RBAC data plane access has traditionally be configured either via PowerShell role assignment or applications leverage the full Cosmos connection strings. This article hopefully walked through and provided you with a way to leverage Bicep to keep these RBAC role assignments in your infrastructure as code. If you are interested more Cosmos feel free to check out my post on the DP – 420 Cosmos Specialty exam .

4 thoughts on “ Assigning Cosmos Data Plane Roles via RBAC w/ Bicep ”

Hi John, very useful post. Thanks!

But it seems this role assignment is not idempotent as other Azure RBAC role assignment, have you encountered the same issue?

resource sqlRoleAssignment ‘Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments@2023-04-15’ = { name: guid(cosmosDataPlaneContributorRoleID, principalId, cosmosAccount.id) parent: cosmosAccount properties: { principalId: principalId roleDefinitionId: ‘/${subscription().id}/resourceGroups/${resourceGroup().name}/providers/Microsoft.DocumentDB/databaseAccounts/${cosmosAccount.name}/sqlRoleDefinitions/${cosmosDataPlaneContributorRoleID}’ scope: cosmosAccount.id } }

Hey Howard,

Appreciate the feedback! No I have not run into any idempotency issues as of yet and have run my deployment multiple times with no change to the assignment. When originally developing this I do remember that this was an issue in addition to configuring the scope of the assignment. Though I am foggy on remembering what ended up being the fix. If you have more details happy to look further into it.

Thanks John, this article helped me solve my problem. The roledefinition still gave me a warning, which failed my pipeline so i added an existing resource to refer as the roledefinitionid.

resource sqlRoledefinition ‘Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions@2023-04-15’ existing = { parent: account name: ‘00000000-0000-0000-0000-000000000002’ }

resource sqlRoleAssignment ‘Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments@2023-04-15’ = { name: guid(‘00000000-0000-0000-0000-000000000002’, functionAppIdentity, account.id) parent: account properties:{ principalId: functionAppIdentity roleDefinitionId: sqlRoledefinition.id scope: account.id } }

Glad to hear it helped! Do you mind sharing what the warning was?

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.