Ability to generate the same GUID value the portal does for roleAssignments

[slapointe]

It is very frustrating today because we cannot compute the same GUID value for the roleAssignment's name that the one created by ARM (Portal & PIM) for the same role assignment values. This makes porting back governance & permissions "as code" way more difficult. We need to delete the ones not created by ARM Templates/Bicep if we want to declare them "as code".

ARM gives me this error message if I try to declare the same roleAssignment in Bicep:

{"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"Conflict","message":"{\r\n  \"error\": {\r\n    \"code\": \"RoleAssignmentExists\",\r\n    \"message\": \"The role assignment already exists.\"\r\n  }\r\n}"}]}}

I get that the name is not the same and the problem is there. I don't have any way to guess how to come up with the same GUID that is generated on the ARM side. Is there any way to dig this info from the platform?

1. I'd like to, know the inputs and in which order, to pass to the guid() function to come up with the same value as ARM does. I guess this will be hard to reproduce, if even possible.

2. If the above is not possible, could we expose a new function that would allow this?

We are close to idempotency here, it is only a matter of generating the same GUID value for the name property.

Not exactly the same ask as #5105 but closely related.

[alex-frankel]

I have reached out to the identity team to see if they publish any info on their GUID generation algorithm. If it is something that could be easily replicated in a bicep function, that could be an interesting way of dealing with this problem.

[slapointe]

I have reached out to the identity team to see if they publish any info on their GUID generation algorithm. If it is something that could be easily replicated in a bicep function, that could be an interesting way of dealing with this problem.

Any return from the team on this @alex-frankel ?

[mitchdenny]

This problem is frustrating me as well. There is always a point in time where some things were done manually, and you are trying to transition to a more automated and compliant approach. The suggestion to remove the role assignment and recreated it via the ARM template is no good because your production systems may depend on this role assignment to function.

[clma91]

Joining this conversation because we face the same issue during automatic deployment through bicep files, where some role assignments were deployed manually beforehand. Or even if a bicep file was run local and afterwards in a pipeline.

How is this guid()-function generating its values? Could it also be dependent on the machine you run it?

I also do not quite understand why there is such a globally unique name required for a role assignment and this is then checked during deployment. Shouldn't it be like if the roleDefinitionId and the to be assigned principalId (with correct principalType) are matching, the role assignment is the same and therefore idempotent?
Why is the name checked for idempotency if the defined attributes are the same?

@alex-frankel have you any news from the team?

[slapointe]

How is this guid()-function generating its values? Could it also be dependent on the machine you run it?

It is not dependent on the machine you run it from. All template functions are processed server side, on Azure.

I also do not quite understand why there is such a globally unique name required for a role assignment and this is then checked during deployment. Shouldn't it be like if the roleDefinitionId and the to be assigned principalId (with correct principalType) are matching, the role assignment is the same and therefore idempotent? Why is the name checked for idempotency if the defined attributes are the same?

roleAssignments are treated like any other resources and need an ID for their CRUD operations at the REST API to work properly. The platform enforces there cannot be 2 identical tuple of principalId, roledefinitionId & scope. Thus the conflict error message we encounter between the manual assignment in the portal and any name provided in templates/Bicep.

We need to have the recipe on how to generate the same name as they do. A better approach IMO would be to have a new function that does just this. That way people cannot misplace the properties used and their order.

[clma91]

It is not dependent on the machine you run it from. All template functions are processed server side, on Azure.

Thanks for explaining.

We need to have the recipe on how to generate the same name as they do. A better approach IMO would be to have a new function that does just this. That way people cannot misplace the properties used and their order.

I totally agree with you. It makes life just hard if these names are generated in a different way through the portal. It would be very useful indeed to have either a way of come to the same guid or as you suggest a function which would do this, so no one could do it wrong.

On the other hand, IMO there should be no need for us to provide a name for something like a role assignment in Bicep. A role assignment is defined throughout its properties which exist or have to be created by the Azure Resource Manager. No matter what the name is, because we do not have the control if someone created it through the portal or ARM/bicep.

[ghost]

Hi slapointe, this issue has been marked as stale because it was labeled as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thanks for contributing to bicep! 😄 🦾

[ckittel]

Can this please be re-opened for tracking purposes?

[Geronius]

Not sure how this could be marked as closed. What's the solution?

[ckittel]

It looks like it got auto-closed by a bot. Hopefully just a mistake.

[matsest]

I've looked into this issue previously and found that for new role assignments created with Azure PowerShell and Azure CLI the assignments are done with non-deterministic uuid/guid() functions in .NET/Python respectively. Similar with terraform and role assignments there.

I would assume the portal does something similar, so it would be hard to "solve" this from the Bicep side in a declarative way unless the name (id) property can be omitted and the deployment engine could deduce the role assignment from a combiantion of principal / role / scope.

[dermot-cochran-ul]

This issue is a major blocker for using Bicep templates with role assignments. We need a workaround for this, so that Bicep deployments will not always fail due to role assignment conflicts.

[alex-frankel]

@dermot-cochran-ul can you help us understand why this is a "major blocker"? Why not delete the portal-generated role assignment and re-create it bicep using a deterministic method?

[dermot-cochran-ul]

I didn't add any portal-generated role assignments. It is all done by Bicep but I am still getting role conflicts.

Do I need to remove all portal-generated role assignments from the resource group, even if the scope is different?

Are there any issues with using role assignments scoped to a BLOB container instead of a Storage Account?

[alex-frankel]

It sounds like you may be running into a separate issue. This thread is specifically about how the portal generates role assignments. Do you mind opening a separate issue with the bicep code you are using and the error you are running into?

[dermot-cochran-ul]

Thanks, yes I will do that. Here it is: #11367

[Aggrobatics]

Same problem here. Since our pipeline was not deploying roleassignments for a while, we had to retroactively patch some environments by deploying a lot of roleassignments using az cli.
None of these environments can be managed using bicep now, because all the pipelines fail due to the "RoleAssignment already exists" error. Simply because the names differ, but the contents (assignee+role) are identical.
We are in quite the pickle due to this issue.
It would be really helpful if Microsoft could provide a guid() implementation for all common programming languages (we require python) so we can update all the affected names in-place using scripting.

[mattfrear]

Just came across this issue too.
When I'm writing bicep templates I want to test them locally using az deployment group create. Once I'm happy I then push my bicep files and deploy them via an Azure Pipeline. The pipeline deployment fails with RoleAssignmentExists, so I have to manually delete the role in the Azure Portal to get the Pipeline to pass.
If I do that, then my local deployments will now fail, because RoleAssignmentExists.

While writing this it occurred to me that a workaround would be to use a different dev Azure subscription for running my local az deployment group create.