Assigning RBAC via Role Assignment Module

[JFolberth]

Bicep version
run bicep --version via the Bicep CLI, az bicep version via the AZ CLI or via VS code by navigating to the extensions tab and searching for Bicep
Bicep CLI version 0.4.1124
Describe the bug
A clear and concise description of what the bug is vs what you expected to happen
Trying to have a module to handle RBAC assignment. Thought this was a good use case where multiple assignments can be handled via a single module. This would include having to pass the scope of the assignment. Per ARM documentation this could be done as a string. However; bicep expects either a scope of resource or tenant.

To Reproduce
module for authorization:
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-10-01-preview' = {
scope: 'Microsoft.Storage/storageAccounts/${azureResource}'
name: guid(roleDefinitionResourceID, principalId, roleDefinitionResourceID)
properties: {
roleDefinitionId: roleDefinitionResourceID
principalId: principalId
principalType: principalType
}
}

Additional context
Couldn't find this exact issue and didn't feel like accuracy/invalidation and also tbh that thread is getting kind of hard to search through what has been discovered and what' hasn't.

[slapointe]

I changed this to a discussion because that could go in various direction depending on your need and what you're trying to achieve.

Is there any particular reason you'd want a module to perform one or multiple role assignments in a generic way?

A module in Bicep translate in a nested deployment in ARM. Having a module that you call multiple times to perform 1 role assignment sounds like a bad idea to me. But again, maybe I am missing something in your requirements.

You usually do nested deployment to abstract more complex logic than a single, simple task like a role assignment.

But for your initial question, Bicep will require a resource, resource group, subscription, management group or tenant as the scope for a role assignment. You could declare the scope property on the resource itself like this 👇 but you loose the flexibility you seem to be looking for.

param roleDefinitionResourceID string
param principalId string
param principalType string
param azureResource string

resource existingStorageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' existing = {
  name: azureResource
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-10-01-preview' = {
  scope: existingStorageAccount
  name: guid(roleDefinitionResourceID, principalId, roleDefinitionResourceID)
  properties: {
    roleDefinitionId: roleDefinitionResourceID
    principalId: principalId
    principalType: principalType
  }
}

I'll wait to understand your need a bit more, and we'll go from there.

[JFolberth]

Not a problem.

So my thinking here is on two levels.

First with the increase in RBAC roles there is a need to assign multiple roles on a given resources. Specifically resources such as Key Vault and Cosmos come to mind where there would be different roles assigned per resources given the situation. It wouldn't be unheard of to have multiple assignments for read roles and write roles. Thus, converting this to a module would ensure consistency and help reduce redundant code.

The second thought on this when starting to scale out is how to couple this with private registries. If there was generic role assignment module defined as a registry then this would allow for additional control in terms of setting what roles could actually be assigned via allowed parameters to the module. Further to this would help with updating one resource when new authorization APIs become available.

Thoughts? Definitely open to a conversation on it.

[bansioza44]

Hi @slapointe code which you provided I following, I do have one question so azureResource is same name as your existing storage account?

[brwilkinson]

@bansioza44

in order for this to work, yes that is correct, for azureResource value, use the existing storage account name.

resource existingStorageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' existing = {
  name: azureResource
}

[davidkarlsen]

existing

When I attempt this I get: "A resource's scope must match the scope of the Bicep file for it to be deployable. You must use modules to deploy resources to a different scope.bicep(BCP139)"

[slapointe]

I personally (it is very personal) prefer to have modules that wrap and perform a complete a story. In the case of Key Vault, you could have a module that handle the key vault itself, diagnostic settings (logging) and let's say a loop around role assignments all in the same file. It is pretty close to what you expressed I think.

Here is an example and let me know what you think and if that could work for you?

keyvault.bicep

@description('Key Vault name')
param vaultName string

@description('Array of objects that describe RBAC permissions, format { roleDefinitionResourceId (string), principalId (string), principalType (enum), enabled (bool) }. Ref: https://docs.microsoft.com/en-us/azure/templates/microsoft.authorization/roleassignments?tabs=bicep')
param rbacPermissions array = [
  /* example
      {
        roleDefinitionResourceId: '/providers/Microsoft.Authorization/roleDefinitions/00482a5a-887f-4fb3-b363-3b7fe8e74483' // Key Vault Administrator
        principalId: '00000000-0000-0000-0000-000000000000' // az ad signed-in-user show --query objectId --output tsv
        principalType: 'User'
        enabled: false
      }
  */
]

resource keyVault 'Microsoft.KeyVault/vaults@2021-06-01-preview' = {
  name: vaultName
  location: resourceGroup().location
  properties: {
    enabledForDeployment: true
    enabledForDiskEncryption: false
    enabledForTemplateDeployment: true
    enablePurgeProtection: true
    enableRbacAuthorization: true
    enableSoftDelete: true
    sku: {
      family: 'A'
      name: 'standard'
    }
    softDeleteRetentionInDays: 14
    tenantId: subscription().tenantId
  }
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-08-01-preview' = [for item in rbacPermissions: if (item.enabled) {
  name: guid(keyVault.id, item.principalId, item.roleDefinitionResourceId)
  scope: keyVault
  properties: {
    roleDefinitionId: item.roleDefinitionResourceId
    principalId: item.principalId
    principalType: item.principalType
  }
}]

main.bicep

targetScope = 'resourceGroup'

module keyVault 'keyvault.bicep' = {
  name: 'keyVaultDeployment'
  params: {
    vaultName: 'kv${uniqueString(resourceGroup().id)}'
    rbacPermissions: [
      {
        roleDefinitionResourceId: '/providers/Microsoft.Authorization/roleDefinitions/00482a5a-887f-4fb3-b363-3b7fe8e74483' // Key Vault Administrator
        principalId: '5eaecd00-b76e-47ab-8645-16d9a75f57FF'
        principalType: 'User'
        enabled: true
      }
      {
        roleDefinitionResourceId: '/providers/Microsoft.Authorization/roleDefinitions/b86a8fe4-44ce-4948-aee5-eccb2c155cd7' // Key Vault Secrets Officer
        principalId: '5eaecd00-b76e-47ab-8645-16d9a75f57FF'
        principalType: 'User'
        enabled: true
      }
    ]
  }
}

[brwilkinson]

This is the script that I use to export all of the role definitions from the subscription:
https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/1-prereqs/4.1-getRoleDefinitionTable.ps1

That creates this lookup file:
https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/tenants/AOA/Global-Config.json

This is where i read that in with json(loadtextcontent())
https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/sub-RBAC.bicep#L49

So that I can just lookup the id from the friendlyname:
https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/sub-RBAC-ALL.bicep#L75
rolesLookup[roleInfo.name]

So even though I define the role assignment via the name, it still uses the ID... so if you export the role definitions with a 'preview' in the name, that works fine, however if you later export the lookup again, then you also update any references that removed the 'preview' in the name, by just updating the parameter files for that individual role to the new name, which is just a search and replace.

[brwilkinson]

It's probably worth noting as well, they announced 'extension' support a while back, which will allow Bicep to extend beyond Azure Resource Manager (ARM). The first one is for AKS and that is in the early preview stages at the moment. They also said that after the first on is implemented, they would likely consider an Azure AD extension as well. So once that takes place, things like role lookups should be more integrated directly into Bicep... The idea was that creating service principals and other similar AAD task would also be enabled at that point.

[JFolberth]

Thanks, I did see that mention in some of the forums. Think it will be key to help automate a lot of the AAD components have to rely on either manual or PowerShell to perform. Definitely excited to see it when it's available. Appreciate all the help.

[JFolberth]

@brwilkinson any thoughts on how to best ensure subscription RBAC access matches the bicep file (minus roles inherited). Envision removal of users and groups could occur as part of subscription management.

Doing incremental deployments and removing and reapplying access at the subscription level feels dangerous.

[brwilkinson]

This ability to clean up role assignments safely is not something that is available right now (or it's not a problem that I know of as being solved).

I am hoping that this may be remedied via Deployment Stacks.

• I will have to test this out in the current Stacks preview, to see how well it aligns with this concept.

[azMantas]

I give a try to share one more way to assign RBAC roles. My main goal was to have a param file where I can easily add new roles and principals (users or AAD groups)

"vmRoles": {
    "VmContributor": {
        "roleDefinitionId": "/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-173b1dc7cf3c",
        "principalId": [
            "11111111-1111-1111-1111-11111111111",
            "22222222-2222-2222-2222-22222222222",
            "33333333-3333-3333-3333-33333333333"
        ]
    },
    "VmAdminLogin": {
        "roleDefinitionId": "/providers/Microsoft.Authorization/roleDefinitions/1c0163c0-47e6-4577-8991-ea5c82e286e4",
        "principalId": [
            "44444444-44444-4444-44444-4444444444"
        ]
    },
    "VmUserLogin": {
        "roleDefinitionId": "/providers/Microsoft.Authorization/roleDefinitions/fb879df8-f326-4884-b1cf-06f3ad86be52",
        "principalId": [
            "55555555-5555-5555-5555-55555555555"
        ]
    }

That's a module for a RBAC assignment. This module will be a part of main vm bicep file. The main purpose of this module is to assign rbac roles to multiple princpials.

param principalID array
param roledefinitionId string
param resourceNameToAssignRbac string

resource resource 'Microsoft.Compute/virtualMachines@2021-07-01' existing = {
  name: resourceNameToAssignRbac
}

resource rbac 'Microsoft.Authorization/roleAssignments@2020-08-01-preview' = [for principal in principalID: {
  name: guid(principal, roledefinitionId, resource.id)
  scope: resource
  properties:{
    roleDefinitionId: roledefinitionId
    principalId: principal
  }
}]

the last step is to implement RBAC assignment module to the VM deployment module. As you can see I use call vmRbac module and call items function on top of that. That allows me dynamically assign multiple roles with multiple rbac defined in param file.

module VmRBAC 'vmRBAC.bicep' = [for role in items(vmRoles): {
  name: '${role.key}-${utc}'
  scope: vmResourceGroup
  params: {
    principalID: role.value.principalId
    roledefinitionId: role.value.roleDefinitionId
    resourceNameToAssignRbac: vmResource.outputs.vmName
  }
}]

[JFolberth]

Thanks for this I did do something similar and will answer below. Biggest difference is I tend to want to list the param file as Principal ID and roles under it but think that is a personal preference.

[JFolberth]

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:

    "parameters": {
        "roleAssignmentInfo":{
          "value":{
            "assignments":[
              {
                "principalID": "1336b403-6998-4b87-8bfe-b9d059095b60", //OST WGO Developers
                "principalType": "Group",
                "roleIDs": [
                    "b24988ac-6180-42a0-ab88-20f7382dd24c", // Contributors
                    "00482a5a-887f-4fb3-b363-3b7fe8e74483" // Key Vault Admin
                ]
              },
              {
                "principalID": "a378896b-35bd-4127-b6ae-6acee3fcec60", //Dev Owners App Service Connection
                "principalType": "ServicePrincipal",
                "roleIDs": [
                   "b86a8fe4-44ce-4948-aee5-eccb2c155cd7" // Key Vault Secrets Officer
                ]
              }
              ]
              }
          }
        }

main bicep:

module RBACRoles 'modules/var_roleAssignmentInfo_module.bicep'= [for (roleAssignmentInfo,i) in array(roleAssignmentInfo) : {
  name: 'RBACAssignmentModule${i}'
  scope: subscription()
  params:{
    assignment: roleAssignmentInfo.assignments
  }
}]

var_roleAssignmentInfo_module.bicep

`param assignment array
targetScope = 'subscription'

module RBACAssignments 'auth_roleassignment_sub.module.bicep' = [for roleAssignmentInfo in array(assignment) : {
  name: 'RBACAssignmentModule${roleAssignmentInfo.principalID}'
  scope: subscription()
  params:{
    principalID: roleAssignmentInfo.principalID
    principalType: roleAssignmentInfo.principalType
    roleIDs: roleAssignmentInfo.RoleIDs
  }
}]

auth_roleassignment_sub.module.bicep:

`param principalID string
param principalType string
param roleIDs array
targetScope = 'subscription'

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = [for (roleID,i) in roleIDs: {
  name: guid(subscription().id, principalID, roleID)
  properties: {
    roleDefinitionId: 'providers/Microsoft.Authorization/roleDefinitions/${roleID}'
    principalId: principalID
    principalType: principalType
  }
}]

[brwilkinson]

Adding a link to a separate discussion on Resource Scoped Role assignments

#5805

Also @JFolberth is resolved for you for now, given the current limitations?

There is also a separate thread on researching for the role ID algorithm used in the portal FYI that @slapointe has opened.

#5694

[JFolberth]

Yup, I've marked this as answered and appreciate the follow up.