bicep role assignment to resource group

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 *

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.

Create Resource Group With Azure Bicep and Deploy Resources In It

In this short post we will discuss how to deploy a resource group and (optionally) create resources inside of this resource group all during one deployment.

Additionally, we cover different values of targetScope for the deployment: subscription , managementGroup , and tenant .

To create a resource group, target scope of the deployment should be set to subscription , and a resource of type Microsoft.Resources/resourceGroups must be created. If target scope is not subscription , then resource group should be deployed using a module.

The ability to create a resource group from a template is useful because it eliminates the need to perform creation of resource group manually and allows managing larger deployments.

Minimal Example

Deployment target scopes, bicep files, compiled arm template, modules: resource group and storage account, deploying at “managementgroup” or “tenant” targetscopes, related posts, useful links.

So, we want to define a resource group in a bicep file in order to have it deployed automatically. This is a basic case and it is covered in the Minimal Example section.

Additionally, let’s assume that we also want to deploy some resources into this resource group, in our case it will be a storage account. This scenario is discussed in Deploying Resource Group and Storage Account .

The post also goes briefly about Deployment Target Scopes and how they relate to a resource group deployment. Later, this knowledge helps in understanding slightly more advanced cases of deploying at subscription , managementGroup and tenant target scopes.

In summary, this post talks about the deployment of the following resource types in a combination with different target scopes:

• Microsoft.Resources/resourceGroups - the resource group we create
• Microsoft.Storage/storageAccounts - some resource to deploy into the resource group

Deploying a resource group in a Bicep file is straightforward. The simplest template should contain an assignment of subscription target scope and definition of Microsoft.Resources/resourceGroups resource.

Each Bicep file has a targetScope which is set implicitly or explicitly, it is used to perform validation and checks on the resources in the template.

When deploying a resource group, your target scope likely to be subscription or higher, because target scope resourceGroup makes less sense when creating a resource group in a template.

Target scope possible values are:

• resourceGroup (default)
• subscription
• managementGroup

Setting target scope is done by using targetScope keyword and a scope name, for example:

In the following sections we will cover two cases:

• Deploying main bicep file at the subscription target scope
• Deploying main bicep file at the managementGroup and tenant target scopes

Deploying Resource Group and Storage Account

In the Minimal Example we saw how to deploy just a resource group. In this part of the post, we are going to also deploy a storage account in the newly created resource group.

Target Scope “subscription”

As already discussed, we need to deploy two resources: a resource group and a storage account.

• Resource group resource ( Microsoft.Resources/resourceGroups ) has to be deployed at the subscription scope. Since the scope of the bicep file is subscription as well, we can simply deploy resource group in the main file .
• Storage account resource has to be deployed at the resourceGroup scope. Therefore, we need to use modules to deploy it at a scope different from the main file.

Our main.bicep file contains deployment of a resource group and a storage account module:

Only if you are curious how Bicep files above look like when compiled into an ARM template, see JSON below.

• Storage account is deployed in a nested deployment Microsoft.Resources/deployments (line 12 )
• Scope of the nested deployment is set via resourceGroup property (line 15 )
• $schema property has two values: ../subscriptionDeploymentTemplate.json# for the parent template (line 2 ) and ../deploymentTemplate.json# for nested deployment (line 27 )

Target Scopes “managementGroup” and “tenant”

Now, how to deploy a resource group if our deployment targetScope is not subscription ? - Use modules to specify the right scope for a resource group.

Bicep modules have an optional scope property which can be used to specify a scope different from the bicep file where module is consumed. We’ve already used this functionality for the storage account in the previous section.

Since our main file’s targetScope is not subscription , we need to put resource group into a separate module (just another bicep file).

These modules are the same both for managementGroup and tenant target scopes

Below is our resource-group.bicep file, it deploys the resource group and a storage account module. This file is identical to main.bicep from the previous chapter where we deployed at the subscription target scope.

The storage.bicep file is the same as in the previous section - simple storage account declaration.

Now, we just need to consume resource-group.bicep module inside of our main bicep file.

Important point is to specify the correct scope for the module, this should be subscription for resource group.

Deploying at the tenant scope is almost identical to deploying at the management group scope. The only difference is the targetScope of the file, and that’s it.

NOTE: You need permissions at the tenant level to be able to deploy at the tenant scope. Read more about the required access .

• Parameters In Azure Bicep - Ultimate Guide With Examples
• Variables In Azure Bicep - From Basics To Advanced
• Learn Modules In Azure Bicep - Basics To Advanced, How It Works, Nested Modules, Outputs, Scopes
• Reference New Or Existing Resource In Azure Bicep
• Child Resources In Azure Bicep - 3 Ways To Declare, Loops, Conditions
• 5 Ways To Deploy Bicep File With Parameters - Azure DevOps, PowerShell, CLI, Portal, Cloud Shell
• Using Key Vault Secrets As Secure Parameters In Azure Bicep - Template & Module Inputs
• Deploy Azure Bicep In YAML and Classic Release Pipelines (CI/CD) - Azure DevOps
• Reference() Function Explained With Examples - ARM Template
• resource-scopes.md - Azure Bicep
• Bicep modules - Azure Resource Manager
• Microsoft.Resources/resourceGroups

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

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.

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

Assign Multiple RoleAssignments at Different Scopes #5926

{{editor}}'s edit

Artiomlk feb 10, 2022.

Beta Was this translation helpful? Give feedback.

This is possible... I would recommend to read over this thread of some of the complexities.

Also this blog which I believe was based on some of the discussions in that thread via @JFolberth

https://blog.johnfolberth.com/nested-loops-in-azure-bicep-with-an-rbac-example/

Then please share back any questions or follows up that you have here.

Essentially to do a role assignment, you deploy into the Scope of the resource E.g. the resource group, Then you use an existing reference, then you can do the role assignment at that scope of that resource.

So if you have 2 resource groups, you need to have a module to deploy into the scope of those resources groups Etc.

Here is also an alternate …

Replies: 1 comment · 6 replies

Brwilkinson feb 10, 2022 maintainer.

ArtiomLK Feb 10, 2022 Author

Brwilkinson feb 16, 2022 maintainer.

• Numbered list
• Unordered list
• Attach files

Select a reply

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.

This browser is no longer supported.

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

Scope functions for Bicep

• 2 contributors

This article describes the Bicep functions for getting scope values.

managementGroup

managementGroup()

Returns an object with properties from the management group in the current deployment.

managementGroup(identifier)

Returns an object used for setting the scope to a management group.

Namespace: az .

managementGroup() can only be used on a management group deployments . It returns the current management group for the deployment operation. Use when either getting a scope object or getting properties for the current management group.

managementGroup(identifier) can be used for any deployment scope, but only when getting the scope object. To retrieve the properties for a management group, you can't pass in the management group identifier.

Return value

An object used for setting the scope property on a module or extension resource type . Or, an object with the properties for the current management group.

Management group example

The following example sets the scope for a module to a management group.

The next example returns properties for the current management group.

It returns:

The next example creates a new management group and uses this function to set the parent management group.

resourceGroup

resourceGroup()

Returns an object that represents the current resource group.

resourceGroup(resourceGroupName)

resourceGroup(subscriptionId, resourceGroupName)

Return an object used for setting the scope to a resource group.

The resourceGroup function has two distinct uses. One usage is for setting the scope on a module or extension resource type . The other usage is for getting details about the current resource group. The placement of the function determines its usage. When used to set the scope property, it returns a scope object.

resourceGroup() can be used for either setting scope or getting details about the resource group.

resourceGroup(resourceGroupName) and resourceGroup(subscriptionId, resourceGroupName) can only be used for setting scope.

When used for setting scope, the function returns an object that is valid for the scope property on a module or extension resource type.

When used for getting details about the resource group, the function returns the following format:

The managedBy property is returned only for resource groups that contain resources that are managed by another service. For Managed Applications, Databricks, and AKS, the value of the property is the resource ID of the managing resource.

Resource group example

The following example scopes a module to a resource group.

The next example returns the properties of the resource group.

It returns an object in the following format:

A common use of the resourceGroup function is to create resources in the same location as the resource group. The following example uses the resource group location for a default parameter value.

You can also use the resourceGroup function to apply tags from the resource group to a resource. For more information, see Apply tags from resource group .

subscription

subscription()

Returns details about the subscription for the current deployment.

subscription(subscriptionId)

Returns an object used for setting the scope to a subscription.

The subscription function has two distinct uses. One usage is for setting the scope on a module or extension resource type . The other usage is for getting details about the current subscription. The placement of the function determines its usage. When used to set the scope property, it returns a scope object.

subscription(subscriptionId) can only be used for setting scope.

subscription() can be used for setting scope or getting details about the subscription.

When used for getting details about the subscription, the function returns the following format:

Subscription example

The following example scopes a module to the subscription.

The next example returns the details for a subscription.

Returns an object used for setting the scope to the tenant.

Returns the tenant of the user.

tenant() can be used with any deployment scope. It always returns the current tenant. You can use this function to set the scope for a resource, or to get properties for the current tenant.

An object used for setting the scope property on a module or extension resource type . Or, an object with properties about the current tenant.

Tenant example

The following example shows a module deployed to the tenant.

The next example returns the properties for a tenant.

Some resources require setting the tenant ID for a property. Rather than passing the tenant ID as a parameter, you can retrieve it with the tenant function.

To learn more about deployment scopes, see:

• Resource group deployments
• Subscription deployments
• Management group deployments
• Tenant deployments

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