[AVM Question/Feedback]: Breaking Change - Role-Assignments name should be consistent & configurable

[AlexanderSehr]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Related to #2973

Description

As of today, all role assignment names in AVM-Bicep are generated using a snippet like

bicep-registry-modules/avm/res/key-vault/vault/main.bicep

Lines 346 to 348 in 88ce9d9

	resource keyVault_roleAssignments 'Microsoft.Authorization/roleAssignments@2022-04-01' = [
	for (roleAssignment, index) in (roleAssignments ?? []): {
	name: guid(keyVault.id, roleAssignment.principalId, roleAssignment.roleDefinitionIdOrName)

While great if you only use AVM, it comes with a few challenges such as

• Existing role assignments will run into errors of the type 'RoleAssignment already exists' IF the same combination of scope, principalId & roleDefinitionId was deployed using a different 'resource' name
• You cannot actually influence the name, as the name is always generated. So even if you'd want to specify an existing name because you fetched them before, you cannot use them
• Finally, it's also not 100% consistent when using an AVM module itself, as the last element of the GUID, roleAssignment.roleDefinitionIdOrName, can have 3 different values depending on whether you provide a role name, the role definition GUID, or the full role definition ID - all scenarios which are supported.

While it would be great to find out how e.g. the Azure CLI or the Portal generate the name, it would be a good first step to update the implement (in this repository & the AVM schema) to

resource keyVault_roleAssignments 'Microsoft.Authorization/roleAssignments@2022-04-01' = [
  for (roleAssignment, index) in (roleAssignments ?? []): {
    name: roleAssignment.?name ?? guid(
      keyVault.id,
      roleAssignment.principalId,
      contains(builtInRoleNames, roleAssignment.roleDefinitionIdOrName)
      ? builtInRoleNames[roleAssignment.roleDefinitionIdOrName]
      : contains(
            roleAssignment.roleDefinitionIdOrName, '/providers/Microsoft.Authorization/roleDefinitions/')
            ? roleAssignment.roleDefinitionIdOrName
            : subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleAssignment.roleDefinitionIdOrName))
    properties: {
      roleDefinitionId: contains(builtInRoleNames, roleAssignment.roleDefinitionIdOrName)
        ? builtInRoleNames[roleAssignment.roleDefinitionIdOrName]
        : contains(roleAssignment.roleDefinitionIdOrName, '/providers/Microsoft.Authorization/roleDefinitions/')
            ? roleAssignment.roleDefinitionIdOrName
            : subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleAssignment.roleDefinitionIdOrName)
      principalId: roleAssignment.principalId
      description: roleAssignment.?description
      principalType: roleAssignment.?principalType
      condition: roleAssignment.?condition
      conditionVersion: !empty(roleAssignment.?condition) ? (roleAssignment.?conditionVersion ?? '2.0') : null // Must only be set if condtion is set
      delegatedManagedIdentityResourceId: roleAssignment.?delegatedManagedIdentityResourceId
    }
    scope: keyVault
  }
]

// UDT
type roleAssignmentType = {
  @description('Optional. The name (as GUID) of the role assignment. If not provided, a GUID will be generated.')
  name: string?

  (...)
}

The above solve some of the issues by

• Allowing the user to define an optional name for the role assignment
• And if they don't provide one, the logic always uses the full role definition ID for the name (as opposed to whatever the user provided)

Please note: This can be a major breaking change. As stated before, role assignments are not idempotent if the name changes. The only users that won't experience breaking changes would be the one that already only provided the full role definition ID.

Related to #5694

Update 2024-07-18: Given the lookup it may make sense to simplify the implementation via a dedicated variables:

var formattedRoleAssignments = [
 for (roleAssignment, index) in (roleAssignments ?? []): union(roleAssignment, {
   roleDefinitionId: contains(builtInRoleNames, roleAssignment.roleDefinitionIdOrName)
     ? builtInRoleNames[roleAssignment.roleDefinitionIdOrName]
     : contains(roleAssignment.roleDefinitionIdOrName, '/providers/Microsoft.Authorization/roleDefinitions/')
         ? roleAssignment.roleDefinitionIdOrName
         : subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleAssignment.roleDefinitionIdOrName)
 })
]
resource workspace_roleAssignments 'Microsoft.Authorization/roleAssignments@2022-04-01' = [
 for (roleAssignment, index) in (formattedRoleAssignments ?? []): {
   name: roleAssignment.?name ?? guid(workspace.id, roleAssignment.principalId, roleAssignment.roleDefinitionId)
   properties: {
     roleDefinitionId: roleAssignment.roleDefinitionId
     principalId: roleAssignment.principalId
     description: roleAssignment.?description
     principalType: roleAssignment.?principalType
     condition: roleAssignment.?condition
     conditionVersion: !empty(roleAssignment.?condition) ? (roleAssignment.?conditionVersion ?? '2.0') : null // Must only be set if condtion is set
     delegatedManagedIdentityResourceId: roleAssignment.?delegatedManagedIdentityResourceId
   }
   scope: workspace
 }
]

---

Instructions: How to work around the breaking change

To use existing role assignments even with the new interface (which changes the default name in cases you did not provide the full roleDefinitionId), you can use the following steps:

1. For a resource you previously deployed role assignments through the original template to, fetch the role assignments via $roles = Get-AzRoleAssignment -Scope '<resourceIdOfResource>'
2. For each role assignment, take note of the 'RoleAssignmentName' property
3. Add its value to each role assignment in your template via the new configurable name property

Doing so will overwrite the new default behavior and let's you continue to use the name you used during the orignal deployment, avoiding errors like 'RoleAssignment already exists'.

Example:

# 1. Fetch role assignments
$roles = Get-AzRoleAssignment -Scope '/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/myRg/providers/Microsoft.KeyVault/vaults/myVault'

# 2. Note the value of each 'RoleAssignmentName'
$roles
# RoleAssignmentName : 22222222-2222-2222-2222-222222222222
# RoleAssignmentId   : /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/myRg/providers/Microsoft.KeyVault/vaults/myVault/providers/Microsoft.Authorization/roleAssignments/22222222-2222-2222-2222-222222222222
# Scope              : /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/myRg/providers/Microsoft.KeyVault/vaults/myVault
# DisplayName        : Glad Os
# SignInName         : [email protected]
# RoleDefinitionName : Cost Management Contributor
# RoleDefinitionId   : 434105ed-43f6-45c7-a02f-909b2ba83430
# ObjectId           : 44444444-4444-4444-4444-444444444444
# ObjectType         : User
# CanDelegate        : False
# Description        : 
# ConditionVersion   : 
# Condition          : 

# RoleAssignmentName : 33333333-3333-3333-3333-333333333333
# RoleAssignmentId   : /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/myRg/providers/Microsoft.KeyVault/vaults/myVault/providers/Microsoft.Authorization/roleAssignments/33333333-3333-3333-3333-333333333333
# Scope              : /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/myRg/providers/Microsoft.KeyVault/vaults/myVault
# DisplayName        : Ctm Insights
# SignInName         : 
# RoleDefinitionName : Reader
# RoleDefinitionId   : acdd72a7-3385-48ef-bd42-f606fba81ae7
# ObjectId           : 55555555-5555-5555-5555-555555555555
# ObjectType         : ServicePrincipal
# CanDelegate        : False
# Description        : 
# ConditionVersion   : 
# Condition          : 

// 3. Update your deployments
roleAssignments: [
 {
   name: '22222222-2222-2222-2222-222222222222'
   roleDefinitionIdOrName: 'Cost Management Contributor'
   principalId: '44444444-4444-4444-4444-444444444444'
   principalType: 'User'
 }
 {
   name: '33333333-3333-3333-3333-333333333333'
   roleDefinitionIdOrName: 'acdd72a7-3385-48ef-bd42-f606fba81ae7'
   principalId: '55555555-5555-5555-5555-555555555555'
   principalType: 'ServicePrincipal'
 }
]

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

Note

This label was added as per ITA06.

[AlexanderSehr]

Planning to implement this soon. Announcement will follow once ready.

[AlexanderSehr]

Linked to #2973 to close

[Agazoth]

@AlexanderSehr I just hurt myself on thisone 😄

Updated key vault from 0.5.1 to 0.9.0 and now i cannot redeploy existing deployments without The role assignment already exists. errors.

I'll give the workaround a try. Any ETA on a fix?

[AlexanderSehr]

Hey @Agazoth,
please exuse the late reply. I was out of office for the past 2 weeks.
There won't be a 'fix' in the classical sense, as the implementation was intentionally changed with the knowledge that it would be a breaking change (to which end the workaround can be used). The issue is more on the provider, than on our side in that a role assignment must always have a custom name when using IaC. However, this was already raised with the PG and maybe there is hope that they will eventually change the way they handle role assignments to be less restricted (e.g., rather update a role assignment for the same scope-principal-roleDefinition assignment, even if the name is different).
For the time being, you can only work through this by either

• removing the current role assignment and deploying it again via the new implementation (which might be nicer in the long run, but requires manual changes)
• setting the role assignment's name to the same value it currently has in Azure by fetching the current role assignments, identifying the name and setting it yourself (which is a bit of a hassle, especially if dealing with a large number of role assignments).

Nasty stuff, but we did have to change the implementation from our side as the previous implementation had the flaw of also conflicting if using different variations of the roleDefinitionIdOrName parameter (e.g., role name, or definition id, or definition GUID). Now it always uses the roleDefinitionId no matter what you do and is hence finally deterministic.

If you need any help with sorting this out on your end, let us know.

[Agazoth]

Thanks @AlexanderSehr we went with option 1, which works fine for us now.

[AlexanderSehr]

Will close this issue in favor of #2973 as the new interface was essentially rolled out and the remaining modules are tracked in the linked issue