Azure / Azure/bicep

Feature request: Abstract away user-assigned identity assignment across resources

Open
#5,801 6 comments 0 reactions 0 assignees View on GitHub
enhancement provider improvement
Dominant language
Bicep
Stars
3.6k
Forks
830
Avg merge
1d 21m
Merged PRs (30d)
79

Description

**Is your feature request related to a problem? Please describe.**
Different resources across Azure allow the assignment of a user-assigned identity. but the way of doing so is just odd compared to other assignments across Bicep.

'Microsoft.Kusto/clusters@2021-08-27' assigns it in the following way:

```
param UAIName string
resource UAI 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' existing = {
name: UAIName
}

resource Kusto 'Microsoft.Kusto/clusters@2021-08-27' = {
//...
identity: {
type: 'UserAssigned'
userAssignedIdentities: {
'${UAI.id}': {} //Note that the ID of the UAI is assigned as the key for an empty value in a map
}
}
}
```

Given that nearly everything else accepts a string field in which you put the ID or accepts an object that defines only an identifier, it's odd that here the UAI assignment is always done with this funky dictionary assignment, and it's not clear that there's ever anything you'd put into the value.

We see the same approach used across the board in Azure, with 'Microsoft.Resources/deploymentScripts@2020-10-01', Microsoft.Synapse/workspaces@2021-06-01-preview', 'Microsoft.DocumentDB/databaseAccounts@2021-06-15' and others taking the same approach.

In fact, the only outlier I've seen so far has been Service Fabric in assigning the identity to its nodes:

```
resource SFNodes 'Microsoft.ServiceFabric/managedClusters/nodeTypes@2021-07-01-preview' = [for node in nodeTypes: {
//...
vmManagedIdentity: {
userAssignedIdentities: [
UAI.id
]
}
}]
```

And it's the only one that handles the UAI assignment like I'd expect to see.

**Describe the solution you'd like**
I'd like to see a uniform approach taken in ARM, but since this is the responsibility of a bunch of different teams, I'm not holding my breath.

The next best thing from the Bicep group through would be abstracting that away and leaving it to the compiler to select the right format for the resource it's assigned to. Instead of having me pass the UAI ID to the field, let me just pass in the existing UAI resource itself and at build-time, identify whether it needs to be characterized as a funky dictionary or as an array of the IDs, but don't make me, the developer have to worry about it.

Thanks for your consideration!

Contributor guide

Open the contributing guide

Research direction

No files, tests, or entry points are named. Start by locating how Bicep represents resource identity properties and how Azure resource types define their identity schemas, then trace the compiler path for assigning an existing user-assigned identity. Done means a consistent source-level assignment works for the cited dictionary and array forms, with coverage for the affected resource types.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure
Domain
cloud, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.