alex-frankel
commented
3 years ago This would be a great addition, but I'd prefer to see this added to the deployments runtime so that both ARM and Bicep can benefit and we do as little "magic" in the bicep transpiler as possible. If it's alright, I'd like us to have an internal conversation to see if this is something we can prioritize, otherwise it may make sense for you to pick it up. Thanks for offering!
bicep must have some source of truth which would need to be vended with it
I'm hoping that this doc is generated off of that source of truth. At the very least, if we can tie updates to the bicep implementation to updates of this doc, that would be "current enough" IMO.
Also, it is not clear to me if the well known role definition ids are constant between different Azure clouds.
I think these are consistent between all clouds, but we should double-check.
NeilMacMullen
JustinGrote
anthony-c-martin
slavizh
allanlw
skurhse
KaiWalter
ChristopherGLewis
Bandgren
jahead
AlexanderSehr
OskarKlintrot
Is your feature request related to a problem? Please describe.
Currently, to deploy a azure role assignment, the UUID of the role definition must be hard coded and/or provided as a parameter. This is a pain.
See https://github.com/Azure/bicep/blob/main/docs/examples/101/create-managedidentity-rbac/main.bicep for an example.
Describe the solution you'd like
Bicep is in a position to provide access to well-known constant values.
Syntax proposal 1: Introduce a new global variable that is loaded by default. Then you could access the roleDefinitionId like:
This has the advantage of (presumably) being easier to implement and has the advantage of only being one value in the namespace if there are other well-known constants that might be added in the future. Technically I suppose this would be a breaking change though.
Syntax proposal 2: The other option would be a new function for this specific case:
This is also a breaking change but is slightly simpler easier to use. It could also have an optional argument for targeting other scopes.
Downsides
Providing this information means that bicep must have some source of truth which would need to be vended with it (in which case it could become stale) or added as a new dependency. Also, it is not clear to me if the well known role definition ids are constant between different Azure clouds.
Regardless of the ergonomics this would essentially be adding resource-specific support into the bicep language, which as far as I can tell so far is relatively resource agnostic (or at least as much as ARM templates themselves are). Adding stuff like this starts to get into the "standard library" territory, which bicep might be trying to avoid.
This seems bite sized enough that if it's a desirable feature I'm actually considering implementing it myself and sending a PR, but I wanted to start a discussion first.