Automatic naming for role assignments

[aelij]

Is your feature request related to a problem? Please describe.
Role assignment naming is hard to get right in ARM. I think the best way of doing it is using the guid function to hash all the parameters of the role assignment. This way templates remain fully idempotent, and avoid "role assignment exists" errors.

Describe the solution you'd like

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-10-01-preview' = {
  name: auto
  properties: {
    roleDefinitionId: roleDefinitionId
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

name would be equal to guid(scope, roleDefinitionId, principalId, principalType) (or perhaps generalized as, guid(scope, prop1, prop2, ...). This also forces principalId (and other parameters) to be statically-known - which is great since using dynamic values makes the name non-idempotent.

Note this can also be used for Cosmos's Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments (and possibly others).

[alex-frankel]

Definitely get the desire for this, but I don't think this is something likely to change. It would be up to the Authorization RP team to make a change like this, so it's not up to us.

If the name is auto, how would we know the name for future updates of the same role assignment? Personally, I'd prefer roleAssignments relax the GUID requirement and allow any name (that is unique to the tenant). I think the biggest challenge is having to guess and pray that the GUID you are generating is not taken.

[aelij]

how would we know the name for future updates

I meant that auto would compile into a guid expression from the resource's data. Then, if you change one of the parameters, it would create a new role assignment.

[alex-frankel]

It would be difficult to justify doing something specifically for roleAssignments, but it might be interesting to explore a more generic "auto-naming" capability for all resource types.

[aelij]

As I said above, it could be generalized by using the guid function on all properties, guid(scope, string(p1), string(p2), ...)

[alex-frankel]

The question is what properties to choose automatically? Does there need to be some sort of mapping that says something like:

• for roleAssignment use roleDefinitionId, principalId, etc.
• for virtualMachine use propertyA, propertyB, etc.

At that point it becomes a question of who maintains that list and what would the fallback behavior be? We also need to ask how useful is a guid for a resource name when it's not explicitly required?

I'd much prefer the Authorization RP figures out how to relax the guid requirement.

[aelij]

Why not use all properties for any resource?

I doubt it can be solved by the auth RP - the ARM contract requires operations to be idempotent, which means a PUT must include the resource identifier. And the identifier needs to be globally unique, which is why a GUID is a good choice. Plus the fact the RP doesn't allow duplicate entries (that is ones that differ by ID but have the same role assignment properties) - which is why this is difficult.

[slavizh]

@aelij you cannot use all properties as some of these can be changed. For example if you change the description that does not result in new name and thus new role created.

[aelij]

Hmm, yes. Then perhaps an API spec extension that defines those properties (e.g. x-ms-id-property: true). As for fallback, if this extension is not defined, then Bicep should display an error that auto is not support for the type.

This could also be used by Azure SDKs which now produce a random GUID for role assignments. That makes it difficult to migrate an existing assignment to Bicep.

[aelij]

API spec extension that defines those properties (e.g. x-ms-id-property: true).

What about this idea?

[ghost]

Hi aelij, 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! 😄 🦾

[aelij]

Not stale