RBAC not getting created uniquely

[pattisanta]

I have used this bicep many time without an issue. I added a module for key vault diagnostics. I can deploy successfully the first time. for whatever reason am getting the following error when I redeploy to a new keyvault.
Status Message: Tenant ID, application ID, principal ID, and scope are not allowed to be updated. (Code:RoleAssignmentUpdateNotPermitted)
I think it means the it unable to assign the rbac because it not unique.
Maybe I am missing something obvious. Hoping someone can see what i'm not seeing
@description('Specifies the name of the key vault')
param vault_name string =
param settingName string =
param storageaccountrg string =
param workpsaceresoucegroup string =
param workspace string =
param storagaccountname string =
@description('The collection of resoruce tags passed from paramters file')
param tags object = {

}
@description('Specifies the User principal ID assigned to the role.')
param principalId string = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

@description('Specifies the User principal ID assigned to the role.')
param principalId1 string = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

@description('Specifies the role definition ID used in the role assignment.')
param roleDefinitinGuid string = 'a4417e6f-fecd-4de8-b567-7b0420556985'

@description('Specifies the role definition ID used in the role assignment Key Vault Reader.')
param keyvaultreaderroleDefinitinGuid string = '21090545-7ca7-4776-b22c-e363652d74d2'

var roleAssignGuid = guid(principalId, roleDef.id)
var roleAssignGuid1 = guid(principalId1, roleDef1.id)

resource keyvault 'Microsoft.KeyVault/vaults@2021-04-01-preview' = {
name: vault_name
tags: tags
location: resourceGroup().location
properties: {
sku: {
family: 'A'
name: 'standard'
}
tenantId: subscription().tenantId
enableSoftDelete: true
softDeleteRetentionInDays: 90
enableRbacAuthorization: true
enabledForTemplateDeployment: true
accessPolicies: []
}
}

resource roleDef 'Microsoft.Authorization/roleDefinitions@2018-01-01-preview' existing = {
name: roleDefinitinGuid
}

resource Assignment 'Microsoft.Authorization/roleAssignments@2018-01-01-preview' = {
name: roleAssignGuid
scope: keyvault
properties: {
principalId: principalId
roleDefinitionId: roleDef.id
}
}
resource roleDef1 'Microsoft.Authorization/roleDefinitions@2018-01-01-preview' existing = {
name: keyvaultreaderroleDefinitinGuid
}
resource Assignment1 'Microsoft.Authorization/roleAssignments@2018-01-01-preview' = {
name: roleAssignGuid1
scope: keyvault
properties: {
principalId: principalId1
roleDefinitionId: roleDef1.id
}
}
module keyvaultdiagnostic 'keyvauldiag.bicep' = {
name: 'keyvaultdeploy'
params: {
settingName: settingName
storagaccountname: storagaccountname
storageaccountrg: storageaccountrg
vault_name: vault_name
workpsaceresoucegroup: workpsaceresoucegroup
workspace: workspace
}
dependsOn: [
keyvault
]
}

Regards,
Patti

[brwilkinson]

Yes this error can occur when the GUID for the role assignment is not unique AND it needs to be deterministic.

Currently you are using the following

var roleAssignGuid = guid(principalId, roleDef.id)

so lets take a look at what happens when this runs with some specific bogus guids

var roleAssignGuid = guid('abc29b64-e950-4f86-9a42-f8352d548a79', '018e806b-4f80-42d6-8b0e-67e0ccde42b9')

//or

var roleAssignGuid = guid('myuserID', 'Key Vault Secrets User')

Now imagine that I have 10 resource groups in your subscription.

If each of those used the template, to deploy and were assigning an admin access 'myuserID' at the keyvault scope as a 'Key Vault Secrets User', they would all come up with exactly the same GUID for the value of roleAssignGuid.

• Every role assignment must be unique, so given that you are not able to provide a unique GUID from the arguments that you are passing in then you will now have collisions of the GUID.

So what is the answer ?

• Pass in more parameters that are deterministic when it is executed so that for the scope of the deployment, the guid is unique.

This the what I use on ALL of my role assignments to generate the GUID.

• User role assignments
• Service Principal role assignments
• User Assigned Managed Identity Role assignments

    GUID: guid(subscription().subscriptionId, rgName, roleInfo.Name, rbac.Name, (contains(rbac, 'SubscriptionID') ? rbac.SubScriptionID : subscription().subscriptionId), (contains(rbac, 'RG') ? rbac.RG : Enviro), (contains(rbac, 'Prefix') ? rbac.Prefix : Prefix), (contains(rbac, 'Tenant') ? rbac.Tenant : Global.AppName))

https://github.com/brwilkinson/AzureDeploymentFramework/blob/0aa5f1500b29fc7327956d3af621514625bf371b/ADF/bicep/sub-RBAC-ALL.bicep#L42

So that is quite complex, however I do have more descriptions and explanations, plus reporting in the variable block below as to what all of those things actually mean, which maybe some of the things for you to consider in your case.

var roleAssignment = [for rbac in roleInfo.RBAC : {
    SourceSubscriptionID: subscription().subscriptionId
    SourceRG: rgName
    RoleName: rbac.Name
    RoleID: rolesGroupsLookup[rbac.Name].Id
    DestSubscriptionID: (contains(rbac, 'SubscriptionID') ? rbac.SubScriptionID : subscription().subscriptionId)
    DestSubscription: (contains(rbac, 'SubscriptionID') ? rbac.SubScriptionID : subscription().id)
    DestManagementGroup: (contains(rbac, 'ManagementGroupName') ? rbac.ManagementGroupName : null)
    DestRG: (contains(rbac, 'RG') ? rbac.RG : Enviro)
    DestPrefix: (contains(rbac, 'Prefix') ? rbac.Prefix : Prefix)
    DestApp: (contains(rbac, 'Tenant') ? rbac.Tenant : Global.AppName)
    principalType: principalType
    GUID: guid(subscription().subscriptionId, rgName, roleInfo.Name, rbac.Name, (contains(rbac, 'SubscriptionID') ? rbac.SubScriptionID : subscription().subscriptionId), (contains(rbac, 'RG') ? rbac.RG : Enviro), (contains(rbac, 'Prefix') ? rbac.Prefix : Prefix), (contains(rbac, 'Tenant') ? rbac.Tenant : Global.AppName))
    FriendlyName: 'source: ${rgName} --> ${roleInfo.Name} --> ${rbac.Name} --> destination: ${(contains(rbac, 'Prefix') ? rbac.Prefix : Prefix)}-${(contains(rbac, 'RG') ? rbac.RG : Enviro)}-${(contains(rbac, 'Tenant') ? rbac.Tenant : Global.AppName)}'
}]

Based on the above, this is the output from my role assignment when it runs, which I can use for troubleshooting if/when needed.

Some of the main things to consider adding are:

• source subscription
• destination subscription
• source RG or scope
• destination scope
• role guid
• user guid
• source region
• destination region

e.g.

var roleAssignGuid = guid(subscription().id, resourcegroup().id, keyvault.id, principalId, roleDef.id)

Given that you already have the role assignment deployed at a particular scope with a specific permission, you likley have to clean up all of those role assignments PRIOR to redeploying them out again with a different role assignmentID/GUID algorithm.

• If you are able to get a solid algorithm to determine the GUID right from the start, that scales across environments or even Regions, that is very beneficial in the long term.

One final comment on this is that I also include the 'Prefix' since that is a reference to the region the role assignment will be deployed... to avoid conflicts for cross region role assignments. Depending on the scale of your deployments, you may not need ALL of these options, however hopefully this gives you some ideas.

[brwilkinson]

Hi @pattisanta did you get a chance to review why you were not creating the unique guids for your role assignments ?

[pattisanta]

Hi Ben, Yes. Thank you. Sorry I was out of the office for a few days. I will go ahead close this ticket on github. Patti From: Ben Wilkinson ***@***.***> Sent: Thursday, September 30, 2021 5:29 PM To: Azure/bicep ***@***.***> Cc: Santacroce, Patti ***@***.***>; Mention ***@***.***> Subject: Re: [Azure/bicep] RBAC not getting created uniquely (Discussion #4568) Hi @pattisanta<https://github.com/pattisanta> did you get a chance to review why you were not creating the unique guids for your role assignments ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#4568 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AECGXAFSXPCUYASNZN7RFX3UETJBRANCNFSM5EUMUX3A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. [External Email: This message has originated from an external source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.] ​

[jikuja]

Related:

What really is the best practice for role assignment names?

Deployment examples are using determining inputs for guid() method but e.g. PowerShell is just using New-Guid() to generate random guid as input. Are we overcomplicating the name or is Powershell oversimplifying the name?

[brwilkinson]

Yes this error can occur when the GUID for the role assignment is not unique AND it needs to be deterministic.

The important piece from that paragraph is 'it needs to be deterministic'.

Each time it runs, it needs to retrieve and assign the same guid and new-guid generates a different guid each time it is run.

[brwilkinson]

@jikuja if you did want to treat role assignments like Network IP Address ranges, then you can maintain a list of the IP Addresses that you want to use for all of your Networks. You ensure you never have any overlapping IP addresses and when you deploy a VNET, you always ensure you pass in the unique IP Address space.

So now, if you wanted to maintain a table or spreadsheet or csv or json object with all of your role assignments, you could easily generate the random GUID for each one and when you deploy each time you simply lookup the role assignment guid and use that along with the other settings used for a role assignment.

Each time you need a new one, you then add the role assignment to your document and then pass it in. This is a lot of overhead work to maintain in this case.

So it's easier to manage if you have everything in your table that you use to create the role assignment, then generate a unique guid that can be generated (with the same value dynamically) every time it's deployed and that saves you the step and over head of creating and managing all of the guids ahead of time.