Add operator role assignment support for Azure resources

[Copilot]

Overview

This PR implements a new feature that allows Azure Container Apps environments to designate operator principals (users or groups) that should receive administrative access to Azure resources. This addresses scenarios where users deploying Aspire applications to Azure lack administrative access to resources and need to manually configure role assignments.

Problem

When deploying Aspire-based applications to Azure using Azure Container Apps, users often don't have administrative access to the deployed resources. This requires them to:

1. Manually determine which permissions are needed
2. Create role assignments for operators who need to manage resources
3. Coordinate with administrators to grant access

Solution

This PR introduces a declarative programming model that allows resources to define "operator roles" and compute environments to designate operator principals. The system automatically generates the appropriate role assignments during deployment.

Usage Example

var builder = DistributedApplication.CreateBuilder(args);

// Define an admin group parameter
var adminGroupObjectId = builder.AddParameter("adminGroupObjectId");

// Designate the admin group as an operator for this environment
builder.AddAzureContainerAppEnvironment("env")
    .WithOperator(adminGroupObjectId);

// Add Azure Storage - operators automatically get StorageAccountContributor role
builder.AddAzureStorage("storage");

Generated Bicep

The system generates role assignment resources like this:

resource storage_StorageAccountContributor 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(storage.id, operatorPrincipalId, subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '17d1049b-9a84-46fb-8f53-869881c3d3ab'))
  properties: {
    principalId: operatorPrincipalId
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '17d1049b-9a84-46fb-8f53-869881c3d3ab')
    principalType: 'User'
  }
  scope: storage
}

Implementation Details

New Annotations

• OperatorPrincipalAnnotation: Applied to compute environments to store operator principal IDs
• OperatorRoleCallbackAnnotation: Applied to Azure resources to define which roles operators should receive

API Surface

• WithOperator(IResourceBuilder<ParameterResource>): Extension method on IResourceBuilder<AzureContainerAppEnvironmentResource> to add operator principals
• Supports multiple operators via method chaining

Infrastructure

• ProcessOperatorRoleAssignments(): New method in AzureResourcePreparer that processes operator annotations and creates role assignment resources during the BeforeStartAsync lifecycle hook
• Follows existing patterns for role assignment infrastructure
• Leverages IAddRoleAssignmentsContext for consistency

Resource Integration

• Azure Storage: Automatically registers StorageAccountContributor role for operators
• Extensible design allows other Azure resources to easily add operator role support

Testing

Added comprehensive test suite (OperatorRoleAssignmentTests.cs) with 6 tests covering:

• Annotation verification
• Role callback registration
• Resource creation
• Bicep generation (with snapshot verification)
• Multiple operators support
• Negative cases (no operators)

All tests pass successfully.

Future Enhancements

The implementation provides a foundation for:

• Privileged Identity Management (PIM) support
• Additional Azure resources with operator roles
• Fine-grained role customization per resource type
• Custom role definitions

Breaking Changes

None. This is a new feature that doesn't affect existing functionality.

Related Issues

Addresses the operator role assignment feature request for Azure-based deployments.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• aka.ms
  • Triggering command: /usr/local/bin/bicep build /tmp/aspire8yc1IN/env.module.bicep --stdout (dns block)
  • Triggering command: /usr/local/bin/bicep build /tmp/aspireDquH6I/env.module.bicep --stdout (dns block)
  • Triggering command: /usr/local/bin/bicep build /tmp/aspiretha8PR/internal-api.module.bicep --stdout (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

When someone deploys an Aspire-based app to azure using Azure Container Apps and associated resources there is often an issue where those users do not have administrative access to those resources.

It means that they need to figure out what sets of permissions they get and manually create role assignments.

It would be good if on the compute environment which is the root of the publish/deployment pipeline we could indicte there we have an "operator" principal, either a group or a user that we want to have the collection of administrative access to a given resource.

We might want tis to support different scenarios such has configuring Privileged Identity Management (we will do this later).

For now we need to figure out a programming model that allows resources to declare their "operator roles" and for the compute resource to share a set of designated operators. I am thinking the API should look something like this:

var builder = DistributedApplication.CreateBuilder(args);
var adminGroupObjectId = builder.AddParameter("adminGroupObjectId");
builder.AddAzureContainerAppsEnvironment("env")
  .WithOperator(adminGroupObjectId);

builder.AddAzureStorage("storage);

WHat would happen in the code above is there would be an annotation on the storage resource that stores a callback which takes the operator ID from the WithOperator(...) method and generates role assignments which grant operators specific elevated rights.

In the future we could add logic to fine tune whether it uses PIM or not. Put together a proof of concept of this idea that will work for Azure-based deployments.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.