Support CosmosDB and Redis role assignments on app specific managed identity

[eerhardt]

Description

We currently don't support an easy API for modifying the role assignments on database resources. There are no role types that can be used from the Azure.Provisioning libraries today. So for now we will just move our existing role assignments to the ACA roles bicep module.

To support database resources, we add a new virtual method on AzureProvisioningResource - AddRoleAssignments passing in a context object containing the information on the role assignments to add.

Also needed to split all role assignments out of the {app}-roles bicep module because of an issue with CosmosDB failing if the role assignment is added in the same bicep file as the managed identity it is pointing to. This simplifies the code because the role assignment generation is the same whether the resource is existing or not.

Contributes to #6161
Fix #8142

Checklist

• Is this feature complete?
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Ongoing
• Does the change require an update in our Aspire docs?
  • Yes
    - Link to aspire-docs issue [New article]: Aspire 9.2 Azure WithRoleAssignments docs (dotnet/docs-aspire#2788)

[captainsafia]

This looks good given the gnarliness you had to work around with the way role assignments are managed for these resource types.

[eerhardt]

@davidfowl @captainsafia - I believe this is now ready for review.

[captainsafia]

LGTM! Reads much easier than the annotations-based implementation. 😅

[captainsafia]

What does an empty DefaultRoleAssignmentsAnnotation actually help us achieve here? This is just here to pass through to AppliedRoleAssignmentsAnnotation in the non-ACA scenario, right?

[eerhardt]

This is one part that I'm not super excited about, and would like some feedback on.

This is just here to pass through to AppliedRoleAssignmentsAnnotation in the non-ACA scenario, right?

No, this works for both ACA and non-ACA.

• You're right that in non-ACA scenarios this turns into an AppliedRoleAssignmentsAnnotation, which will inject the contributor role into the cosmos resource's bicep.
• In ACA scenarios, the AzureResourcePreparer will copy the DefaultRoleAssignmentsAnnotation to a regular (empty) RoleAssignmentAnnotation, which will cause the role to be written to the role bicep file.

One thought I had was to make up a "fake" contributor/admin RoleDefinition with a random Guid, and check for that in both places. But just having the empty one serves the purposes I need it to.

Thoughts?

[captainsafia]

In ACA scenarios, the AzureResourcePreparer will copy the DefaultRoleAssignmentsAnnotation to a regular (empty) RoleAssignmentAnnotation, which will cause the role to be written to the role bicep file.

Ah, I see where this happens.

Thoughts?

IMO, an empty one feels better than a fake role assignment. We clarified in an offline discussion why we need DefaultRoleAssignments vs RoleAssignment here.

[eerhardt]

Merging now because this change and #8171 will conflict. So merging will help avoid conflicts now.

I address the above feedback in Follow up on database role assignments (dotnet/aspire#8212)