Standard for RBAC Role Assignment names

[SvenAelterman]

Role assignment names must be a GUID. Usually, the GUID is constructed from the combination of the principal ID, the resource ID, and the role definition ID.

However, is there an actual standard for that? Does the order in which the values are passed to the guid() function matter?

[brwilkinson]

Here are some related issues to review:

Recent response:

• Microsoft Sentinel - Playbook Permissions aka. Microsoft.Security uses random role assignment IDs #10564

Others:

• Ability to generate the same GUID value the portal does for roleAssignments #5694
• Provide a mechanism to maintain role assignments with idempotent names #8774
• Automatic naming for role assignments #5105
• Look up existing resources by properties other than name #4917

[brwilkinson]

I like to account the source and destination in my calculation for the guid.

I wrote this as part of an ARM template many years ago and given I wanted it to remain backwards compatible, never updated it, except converted it to Bicep:

• https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/sub-RBAC-RA.bicep#L45

It works for a naming standard that I use in my stamp deployments and I have never needed to update it and I've never had a guid clash for any reason. I built logging into the template so that I can easily troubleshoot or use the logging to ensure things work as expected.

---

If we can agree on a formula for the guid creation that doesn't include any timestamp (or random seed) across the following:

• REST api
• Powershell AZ module
• AZ Cli

Then we could also use the same in Bicep. I would guess that those methods likely include some timestamp (or random seed) so they are not idempotent based on that. So that means we don't solve the bigger problem of them being deterministic.

We probably should have a Module in the Bicep Gallery that can be re-used by the community, I think that could become a de facto standard so people don't need to reinvent the process for naming.

---

Does the order in which the values are passed to the guid() function matter?

It only matters that you never change the order in your own templates, so in that way your own template is deterministic.

[brwilkinson]

something to think about:

if I have 2 Spoke resource groups and they need to create a role assignment on a resource in a Hub resource group

If I use the:

• resourceid of the destination resource
• the role name guid (or name)
• source principal Id

Do I want it to fail or succeed? Am I using the same User Assigned Managed Identity across both Spokes or different Identities? If it was the same one, would I want both of them overwriting the same Role assignment on the Hub resource and have that succeed? Or is the preference to have it fail?!

[SvenAelterman]

It should succeed: it's the same assignment.

If you changed the GUID, the assignment would fail because RBAC won't let you assign the same role to the same resource to the same principal twice.

[brwilkinson]

Right, so that is why I prefer to include the source because I don't want it to succeed, I would want it to fail.

Because in my design, I use a different user assigned identity from each resource group. If it were to be the same, I'd want it to fail.

I wouldn't want the same assignment running twice from 2 different places and not knowing about it. If it was either complete Mode OR a Deploymentstack, who would own the role assignment, if it was run successfully? If I delete the Stack, it should delete the role assignment, which would break the other resource from the other resource group.

So that is why I prefer to add the source scope as part of my guid naming standard. I feel it's a more robust method. To completely differentiate the owner scope who created the role assignment. Without that strange things might occur.

• So depending on what behavior you would like, depends on your standard for creating the guid.

[brwilkinson]

Latest discussion in:

• Microsoft Sentinel - Playbook Permissions aka. Microsoft.Security uses random role assignment IDs #10564