How to give the system-assigned identity access to key vault in the same deployment with the usage of symbolic names logic in Bicep? API Management with KV

[BenjaminEngeset]

Hi project maintainers and contributors,

Heavy user of the great Bicep tooling here.

What is the correct way to actually give system-assigned identity access to the key vault in the same main.bicep/deployment AND let it grab out what it might need from the key vault?

I taught that Bicep logic would be able to understand the dependencies between the resources when it comes to that system-assigned identity must be created beforehand, in order to be able to give the identity to the key vault AND let it grab what it might need. But maybe this is more due to Azure Resource Manager limitation than Bicep?

On the internet there is of course tons of ways to solve this with hackering and making not good code hygiene, but I really think to use the nature and logic of Bicep would be number 1.

Documentation is stating.

https://docs.microsoft.com/en-us/learn/modules/build-first-bicep-template/3-define-resources

Example:

By declaring the app resource with a property that references the symbolic name of the plan, Azure understands the implicit dependency between the App Service app and the plan. When it deploys the resources, Azure will make sure it fully deploys the plan before it starts to deploy the app.

https://docs.microsoft.com/en-us/learn/modules/create-composable-bicep-files-using-modules/3-add-parameters-outputs-modules

Example:

In this example, symbolic names are used for the reference between the modules. This helps Bicep to automatically understand the relationships between the modules.

Is this not applicable for system-managed identity that gets configured for an resource in the deployment as well that wants access to a new key vault and take out what it might need in the same deployment?

[brwilkinson]

if you create the resource and system assigned identity in a Bicep Module.

You should be able to assign a roleAssignment in another module, you can use an existing resource within this module to pull out the system identity clientid that you need for the objectid in the roleassignment.

[BenjaminEngeset]

@brwilkinson

Thanks.

So basically nested module.

I taught this would not be possible in the same deployment as existing references an existing resource that isn't deployed in current Bicep file.

But if Bicep > ARM will understand this, that is great and means that existing has bigger potential than I originally thought 😃

[brwilkinson]

@bengeset96 please let us know how your testing goes and if you are happy, we can mark this as answered.

[brwilkinson]

I'll mark as answered, however please feel free to let us know if you are unable to get this working.

The main consideration here, is that a system assigned identity can only be created when the resource is created, so it limits the options that you have in ordering your deployment of resources. If you used a User Assigned identity, you can create that first. then create the VM or other Resource and assign the user identity, then later assign that access to the keyvault... by then the identity would have replicated, so when you go to use it you are much less likely to run into latency issues for the creation of the identity.

[BenjaminEngeset]

@brwilkinson

Did not see this before now. I have not tested it yet, but the logic makes sense. Will just have to put it into play 👍

Doing APIM deployments and have it working this way with existing would be perfect.

[jaq316]

@bengeset96 ... Did you manage to get this working?

If so... Would you mind posting some code?