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

[pho-enix]

Bicep version
Not related to bicep version.

Describe the bug
Microsoft Sentinel - Playbook Permissions creates random role assignment IDs. This makes picking up/ importing those role assignments in bicep impossible (as bicep expects deterministic resource names.)

To Reproduce
Steps to reproduce the behavior:

1. Select an existing Sentinel workspace in Azure Portal
2. Navigate "Setting"
3. Select the "Settings" tab
4. Open "Playbook permissions"
5. Open "Configure permission"
6. Select a scope and create the permission with "Apply"
7. Lookup the role assignment ID that has been created in RBAC for the selected scope
8. Note down the role assignment ID
9. Delete the RBAC assignment
10. Repeat the steps from 1. - 7.
11. Note down the role assignment ID
12. Compare the role assignment IDs form 8. and 11.
    => Role Assignment IDs are different/ non deterministic.

[pho-enix]

MicrosoftDocs/azure-docs#105888

[brwilkinson]

Unfortunately this is a known issue.

• role assignment names are required to be unique in the tenant.

I don't believe we have a fix or resolution, however:

• From a Bicep perspective what you have in the docs does closely map to the best practice and should be idempotent for bicep redeployments.

E.g.

// BUG: When setup via Azure Portal you will get a random GUID 
var roleAssignmentName = guid(principalId, roleDefinitionID, subscription().id)

Also consider to replace subscription().id, with whatever scopeId or resourceid where you are actually making the role assignment, to ensure this scales. If above is on subscription scope then that is already correct.

problem definition:

• if you create role assignment via rest api, AZ powershell, AZ cli or portal, we don't know the algorithm that is used to generate the guid that is used for the name.

• I will add some other related issues that we have open on this.

[brwilkinson]

related:

• 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

[pho-enix]

@brwilkinson
I see two different kinds of problem here:

• The is no canonical naming convention for the role assignment name in bicep
  As you say, you have to include Principal, Role Definition and Scope in the assignment name to ensure it does not clash with any other role assignments. However I am not aware of a canonical naming conventions for that. And you will definitively have different GUIDs for:

 guid(principalId, roleDefinitionID, subscription().id)
 guid(subscription().id, roleDefinitionID, principalId)
 guid(principalId, roleDefinitionID, subscription().subscriptionId)
 guid(principalId, roleDefinitionName, subscription().id)

IMHO a helper function in bicep might be helpful for that:

roleAssignmentName(scope, roleDefinitionID, principal)

• There is no way to find out the GUID of an existing role assignment
  If role assignments created by a different party (and potentially random or with an unknown algorithm) are involved you might want to have another function that allows you to query the GUID by providing scope, roleDefinitionID and principal.

[stephaniezyen]

This will be resolved by support for user-defined functions
#447 and #9239

[mbsnl]

@brwilkinson
In the end it's not entirely a Bicep problem. It's more like the general governance around naming (generating the guid for) the roleAssignment.

In the scope of Bicep/ARM, Azure-customers can solve this themselves using consistent Template code, or like a user-defined function. However, it's more that other Microsoft tooling/services uses different methods of generating the name/guid:

• Azure Portal, AzCLI, AzPowerShell, Priviledged Identity Management, Microsoft Entra, Sentinel Playbooks
• And this list will only grow

So I think it would help if this looked at by the team managing the "Microsoft.Authorization/roleAssignments" resource provider, maybe they should create a build-in/standardized validation from the combination Principal,Role,Scope, that always generates exactly the same name/guid in a future API version. I know backporting will be difficult. But once this new API is in place, you can granularly start updating tools/portals and more. At least we will have a path forward in 1 or 2 years time.
I can only think of all the difficulties arising, when things like Deployment Stacks really kick of.

And maybe the ARM/Bicep-deployed-way is not that bad, so when the resourceprovider team standardizes on something like this:

var roleAssignmentName = guid(principalId, roleDefinitionId, scopeId)

Then Bicep/ARM Deployments does not even have to be changed.

[brwilkinson]

Adding link to another discussion thread on the topic

• Standard for RBAC Role Assignment names #10539

Adding this since there are a few extra notes there:

• I would guestimate that other sources for creating role assignments use a random seed, such as time to ensure guids are not duplicates.
• depending on your use case, you may want to generate the guid based on a different parameters.

[yuanyi2121]

IMO, the roleAssignment id is the most broken feature in ARM template:

1. if you have 20 roleAssignment in the template and one of them failed. It is impossible to tell which one failed by a given GUID.
2. like mentioned above, different way of roleAssignment may have different ids. If you did a roleAssignment in portal, then did the same again via an ARM template, the latter will fail simply because of the ids are different.
   This drives me nuts from time to time.