EES-5480 - handling creation of container app managed identity and its role assignments in Bicep #5210
Conversation
duncan-at-hiveit
force-pushed
the
EES-5480-adding-container-app-user-and-role-assignments-into-automation
branch
5 times, most recently
from
fbe74e5 to
ae4288b
Compare
| resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = { | ||
| name: guid(containerRegistry.id, rolesToRoleIds[role], managedIdentitty.name) | ||
| scope: containerRegistry | ||
| properties: { | ||
| roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', rolesToRoleIds[role]) | ||
| principalId: managedIdentitty.properties.principalId | ||
| principalType: 'ServicePrincipal' | ||
| } | ||
| } |
There was a problem hiding this comment.
Could add a comment to mention that this is dependent on the deploying service principal having the Microsoft.Authorization/roleAssignments/write permission, such as being an Owner, User Access Administrator, or RBAC Administrator at the scope the role is being assigned, and that AcrPull has been allowed through role assignment conditions? I think there's only a small-ish set of roles been conditionally allowed which can be granted, AcrPull being one of them.
There was a problem hiding this comment.
I've added some comments to this effect thanks. I've also updated containerAppRoleAssignment.bicep to behave like keyVaultRoleAssignment.bicep for consistency (taking an array of principalIds).
| module acrPullRoleAssignmentModule 'components/containerRegistryRoleAssignment.bicep' = { | ||
| name: '${apiContainerAppManagedIdentityName}AcrPullRoleAssignmentDeploy' | ||
| params: { | ||
| role: 'AcrPull' | ||
| containerRegistryName: acrName | ||
| managedIdentityName: apiContainerAppManagedIdentity.name | ||
| } |
There was a problem hiding this comment.
This is the Api container's registry access so maybe it should include 'apiContainer' in the name in case another service/identity needs a similar role assignment? Something like apiContainerAcrPullRoleAssignment or apiContainerRegistryAccess rather than acrPullRoleAssignmentModule?
Could also think about grouping everything related to the Api container into a new app/apiContainer.bicep in future.
There was a problem hiding this comment.
Updated to apiContainerAppAcrPullRoleAssignmentModule.
Also, I already have a ticket for better modularising the Bicep as a whole - https://dfedigital.atlassian.net/browse/EES-5479. I think this should be done prior to deploying to Test.
| name: containerRegistryName | ||
| } | ||
|
|
||
| resource managedIdentitty 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' existing = { |
There was a problem hiding this comment.
Spelling mistake in the name here and where it's referenced below
There was a problem hiding this comment.
Removed anyhow, but nicely spotted thanks.
…s AcrPull role assignment from within Bicep, now that we have permission to grant these ourselves.
…tations around role assignments. Better naming and consistency in role assignment modules.
duncan-at-hiveit
force-pushed
the
EES-5480-adding-container-app-user-and-role-assignments-into-automation
branch
from
202abe6 to
909c0bf
Compare
duncan-at-hiveit
deleted the
EES-5480-adding-container-app-user-and-role-assignments-into-automation
branch
This PR:
This is made possible now by the work of Mark Nelson to allow our DevOps SPNs to be able to assign a subset of common roles.