Support assigning UserAssigned Managed Identities to compute resources

[eerhardt]

Update (05/09/2025): Remaining work here is to support assigning UMIs to compute resources.

Today when using targeted role assignments (#6161), each container app gets its own managed identity.

Sometimes this can pose problems, like in #8389, where a "data migration" app is used to create a database, but then an "API" app wants to CRUD against it. It is simpler to assign both apps the same managed identity, thus only needing a single database user, which both apps use.

To support custom scenarios like this, we should add the ability for the user to manually create a managed identity, and then assign container apps (projects and containers) to a managed identity manually. Doing this would cause the automatic managed identity to no longer be generated for that container app.

Example code:

var builder = DistributedApplication.CreateBuilder(args);
builder.AddAzureContainerAppEnvironment("env");

var dbServer = builder.AddAzureSqlServer("sqlserver");
var todosDb = dbServer.AddDatabase("todosdb");

// The ApiDbService project is responsible for managing the database schema and seeding data.
var apiDbService = builder.AddProject<Projects.AspireStarterDb_ApiDbService>("apidbservice")
    .WithReference(todosDb);

// The ApiService project provides backend HTTP APIs for the web frontend.
var apiService = builder.AddProject<Projects.AspireStarterDb_ApiService>("apiservice")
    .WithReference(todosDb);

// NEW
var dbuser = builder.AddAzureUserAssignedIdentity("dbuser");
apiDbService.WithAppIdentity(dbuser);
apiService.WithAppIdentity(dbuser);

When paired with the WithRoleAssignments API, any role assignments for apiDbService and apiService would be generated for the dbuser managed identity.

Open Questions

1. In RunMode, how should AddAzureUserAssignedIdentity work? We probably don't want to provision these Azure resources at dotnet run time, since nothing will use them. So we would add the resource in memory, but not add it to the model.

cc @davidfowl @tg-msft @mitchdenny

[archerzz]

We have a similar case. There is an existing user assigned identity which controls the access to some external resources. We want to assign that identity to the container app. It's OK to keep the default identity (it's a good practice to split the access control), but we want the capability to assign the external identity in Aspire.

[SoggyBottomBoy]

I'm commenting here as I believe this is related.

The managed identity that is generated for my container app is given admin access to the database (doesn't seem right... well I don't feel my container app should have admin access). What I was hoping is that my container app would be provided db_datareader, db_datawriter access (sql server) and the subscription managed identity would be given the admin access.

I am using liquibase to apply db migrations. Here is my understanding of the 2 solutions I have (I would like to know which is recommended).

Solution 1:

1. Trigger an initial provisioning using my account
2. Fix up the admin access (and db roles) so that the managed identity I am signing in with in CI has admin access, and the container app has read/write access
3. Add azd up to my CI pipeline
4. Run liquibase as a CI step

Solution 2:

1. Add another project which would contain my liquibase files, and would be responsible for installing liquibase and running migrations
2. The aforementioned project is given the db resource reference last so that it is given the admin role 9.2 Role Changes

(If I do solution 2 do I need to add the managed identity to the db and assign roles, how do I get the managed identity that will be created so that I can define some sql script to run to achieve this?)

The manual steps I currently have to make aren't difficult in anyway, I'm more just curious if I can achieve this behaviour with aspire.

EDIT: I don't think Solution 2 is what I want. I need CI to fail is migrations cannot be applied, so I really want to stop my apps, apply migrations, on fail restart apps, on success azd up and restart.

[davidfowl]

See #8381

[Lindsay-Mathieson]

Would very much like this - had 6 App Service in Azure that all used the same managed identity to access the db. Migrated them to Container Apps using Aspire/azd and have had to go back to specifying a sql user/pass for the connection string.

[davidfowl]

@Lindsay-Mathieson that's not the best pattern for reducing the blast radius of security incidents 😄.

had to go back to specifying a sql user/pass for the connection string.

#9041

[Lindsay-Mathieson]

that's not the best pattern for reducing the blast radius of security incidents 😄.

I'm not exactly happy with it either 😁

I don't really understand what #9041 is solving? Something to do with each container having its own assigned managed identity?

I'd really rather use a external Managed Identity for db access - apparently each ATA container will have its own user in the future, which is a PITA to manage for db access as you add databases, containers and environments. The usernames are random and have no meaning, and if you azd down for any reason, you get a whole new bunch of random username to assign to databases.

@eerhardt solution seems much easier to manage and in line with existing practice.

[davidfowl]

I don't really understand what #9041 is solving? Something to do with each container having its own assigned managed identity?

With aspire each since 9.2 container app gets its own managed identity and role assignments are associated with that identity by default. What that issue is solving is SQL role assignment when using managed identity (you need to use SQL queries since the managed identities are not admin).

@eerhardt solution seems much easier to manage and in line with existing practice.

It doesn't change any of the above, all it does it make it so you can decide which managed identity should be associated with the compute resource.

[Lindsay-Mathieson]

With aspire each since 9.2 container app gets its own managed identity and role assignments are associated with that identity by default. What that issue is solving is SQL role assignment when using managed identity (you need to use SQL queries since the managed identities are not admin).

Ah, I think I understand now - each container has its own managed identity, and that identity is auto added to the relevant sql server as a user on deployment? That would make things easier.

With aspire each since 9.2 container app gets its own managed identity

I've seen that mentioned quite a few times, I am provisioning and deploying with 9.2.1, but each container has the same User Identity.