Can we further automatize the steps to give a UAI access to a given storage account?

[thomasp-ms]

Is your feature request related to a problem? Please describe. Currently, many of our tutorials and provisioning resources have some manual steps for giving a UAI access to a given storage account.

Describe the solution you'd like It would be nice if we had scripts to automatize this process. It is not always going to be possible because in some cases we don't know the name of the storage account. However, it would still be nice to have some scripts that takes inputs given by the user.

[jfomhover]

Similar to #157

[jfomhover]

I've researched this a little bit, there's a couple options, none sounds satisfactory entirely.

Option 1 : bicep

we could use our current bicep script "msi_storage_rw.bicep", but the users would have to run to figure out the UAI principal ID before running the command.

Option 2 : az cli

We could provide 3 commands like:

az role assignment create --assignee "UAIPRINCIPALID" \
--role "Storage Blob Data Contributor" \
--scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/Example-Storage-rg/providers/Microsoft.Storage/storageAccounts/storage12345"

Option 3 : integrate in the pair bicep script

The silo creation bicep script could do it by itself, but it might work only for a specific subset of configs where the orchestrator storage is in the same resource group, and not private (no endpoint creation).

[thomasp-ms]

I'm not big on Option 3 if that's not going to be applicable for all variants of setups. Options 1 and 2 seem to share the same drawback of requiring the user to figure out the UAI, but a/ we can provide explicit guidance for that and b/ this is already the case with the current state, so I don't view this as a huge drawback.

I slightly prefer O1 vs O2, because a/ it would be nice to stay consistent with bicep templates and b/ O2 would require the user to do 3 actions instead of just 1 (assuming we can't create several role assignments in a single command, otherwise this argument does not hold).

That being said, would O1 still work in cases where O3 wouldn't? (Sorry, I'm probably missing something here but I can't see why the difficulties in O3 wouldn't apply to O1).