[Spike]: API for role assignments

[davidfowl]

This is a spike to explore APIs for modeling a more secure default security configuration when deploying to azure container apps. It includes a few things:

1. A new set of APIs that azure resources to expose a way to define per reference role assignments. This allows for a least privilege access to resources:

using Azure.Provisioning.Storage;

var builder = DistributedApplication.CreateBuilder(args);

var blobs = builder.AddAzureStorage("storage")
                   .RemoveDefaultRoleAssignments()
                   .RunAsEmulator(c => c.WithLifetime(ContainerLifetime.Persistent))
                   .AddBlobs("blobs");

builder.AddProject<Projects.AzureContainerApps_ApiService>("api")
       .WithExternalHttpEndpoints()
       .WithReference(blobs)
       .WithRoleAssignments(blobs, StorageBuiltInRole.StorageBlobDataContributor);

builder.Build().Run();

In the above WithRoleAssignments allows the user to specify which roles this project/container requires what roles for a specific storage account.

The other API is RemoveDefaultRoleAssignments, which is a way to remove the default role assignments for a storage account.

2. Each compute resource that becomes a container app, gets a roles bicep resource that allocates the managed identity and sets up specific role assignments for that identity based on both the either the per reference role assignments or the resource defaults.

3. Role assignment scopes are resource references. This means we need the ability to get a reference to the underlying azure resource by name, so we can use an existing bicep resource reference in "roles" bicep module. This led to a strange API that was added to AzureProvisioningResource to do this in a way that avoids the compute resource needing to know how to get a reference to the underlying azure resource.

Microsoft Reviewers: Open in CodeFlow

[davidfowl]

We generate a module per container/project and that module has both the user assigned identity and role assignments for that compute resource.

[davidfowl]

These end up as outputs for the container app to use for both runtime and to associate this user assigned identity with the container app.

[davidfowl]

We need to reference the set of resources we are creating role assignments for.

[davidfowl]

I think we need a single type for role definitions and then per resource types that have the well known ones. That would reduce the API explosion.

cc @tg-msft

[davidfowl]

This the strangest part of this change. We need the ability to import the underlying resource use for the role assignment given a name. Look at this to understand more.

This method is called from here

[mitchdenny]

Have you tried deploying this? Based on the Bicep being generated it looks like you are deploying the -roles.module.bicep file first and then taking the user assigned identity out of that. I think that is fine for the case where container apps are only accessing other resources - but we just need to double check this model work for container app to container app deployments.

I think it'll be OK because for container app to container app communication the container app identity (resource side) is not what matters, there would need to be a different Azure Entra app registration which represents the resource (which we are going to need to support defining in the app model).

You know if we get this working it's going to take a lot of the friction out of doing S2S auth.

[davidfowl]

Have you tried deploying this? Based on the Bicep being generated it looks like you are deploying the -roles.module.bicep file first and then taking the user assigned identity out of that. I think that is fine for the case where container apps are only accessing other resources - but we just need to double check this model work for container app to container app deployments.

Not yet, there was a bug in azd, fixed in this pr. It'll work because the identity and role assignments are part of the provision phase. I'll update the description with the deployment details.

[davidfowl]

Deployment works!