[AVM Question/Feedback]: managed identity/RBAC dependency loop after AVM migration

[sinedied]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Description

My app create resources (ie SWA, Functions API, Cosmos DB, OpenAI), and Managed Identity/RBAC creates cross dependencies, for example:

• Functions needs Cosmos DB endpoint as env var
• Cosmos DB needs Functions principal ID to set up SQL roles

Before AVM I was fine, as I set up these in 3 resources:

• Functions, with a dependency on Cosmos DB for endpoint output for app settings (env vars)
• Cosmos DB
• SQL Role, with a dependency on both Functions (principalId) and Cosmos DB (account name)

But migrating to AVM I'm stuck, because the SQL role can only be set up as part of Cosmos DB module and not separately (its a cosmos submodule that cannot be accessed directly, as stated in AVM FAQ).
Now I have a dependency loop that I cannot solve, using only AVM modules.

Is there an obvious way to solve this that I missed?

[AlexanderSehr]

Hey @sinedied,
from the top of my head I'd probably advice to run the role assignment separately as you did originally in the last step using a raw RBAC deployment. It's not pretty, but I don't see how the modules could solve this issue without implementing specific code for this use case (i.e., Cosmos + Function App).
I take it the Cosmos Endpoint is not deterministic? I.e. it would not be possible to construct it and as such resolve one dependency?

[sinedied]

@AlexanderSehr thanks for your reply. I went with what you suggested, implementing the role assignment separately.

What's bothering me though is that I end up duplicating some of the logic/code existing in the AVM(as child module), which means more maintenance. This issue is not specific to my project thought, as such dependency loops frequently appears in architecture with services related to each other, for example when handling Managed Identity/RBAC (like in my case), env variables or networking.

Currently, AVM modules implement these only through their main interface, but if child modules were published this would allow separating the assignment without leaving out of the AVM realm/versioning. For example, my case could be solved by accessing the CosmosDB child module for the SQL role assignment.

In the AVM FAQ, it's said that child module aren't currently published, but I think this could be helpful for such use cases and composability.

[AlexanderSehr]

@AlexanderSehr thanks for your reply. I went with what you suggested, implementing the role assignment separately.

What's bothering me though is that I end up duplicating some of the logic/code existing in the AVM(as child module), which means more maintenance. This issue is not specific to my project thought, as such dependency loops frequently appears in architecture with services related to each other, for example when handling Managed Identity/RBAC (like in my case), env variables or networking.

Currently, AVM modules implement these only through their main interface, but if child modules were published this would allow separating the assignment without leaving out of the AVM realm/versioning. For example, my case could be solved by accessing the CosmosDB child module for the SQL role assignment.

In the AVM FAQ, it's said that child module aren't currently published, but I think this could be helpful for such use cases and composability.

Hey @sinedied,
and this is an absolute fair ask which I'd wish we'd have been able to account for from the very beginning (like in the CARML days - if thay may ring a bell).

As it so happens you're also not the first one asking for the child-modules to be published, but are in good company:

• Module to Provision Event Hub explicitly within existing Event Hub Namespace. Current AVM Event Hub Namespace Module seems not have option to provision event Hub Namespace and Event hub separately  #2868
• [AVM Question/Feedback]: Allow specific submodule deployments? #1933
• [AVM Question/Feedback]: Consumption of child modules? #1390
• [AVM Module Issue]: Allow standalone deployment of access policies #2899
• [Question/Feedback]: Module-support creation child resources (Bicep) Azure-Verified-Modules#578
• [Question]: Make child modules available for direct usage  Azure-Verified-Modules#747

There are certain manual steps (like registering every module before its first version is published) in the process of publishing a module to the public registry that have been preventing us from adding this feature (which we already did implement in the CARML CI [AVM CI's bigger predecessor], be it 'only' for private registries). We're currently working on a PoC to work around / lift some of these limitations and can hopefully offer this capability later this year 🤞

We're already on route to prepare for this future capability. For example, we're about to release a spec that asks owners to always add the @export() flag to their UDTs - even for not-yet-published child modules, because once those are published you'd be able to import their types directly etc. Let's hope the PoC works out well :)

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[sinedied]

Thanks for the details update, I'll close this issue now to avoid further warnings there's already an existing issue.

[AlexanderSehr]

Much appreciated @sinedied, we'll keep you posted :)