[API Proposal] Make workload-identity federation reachable from a custom compute environment

[timritzer]

Background and Motivation

Aspire.Hosting.Azure.Kubernetes already implements workload-identity federation end to end — but
only on a path a custom compute environment cannot reach.

AzureKubernetesEnvironmentExtensions.cs:835-862 emits the credential — and this is the only
occurrence of FederatedIdentityCredential anywhere in src/:

foreach (var (resourceName, identityResource) in aksResource.WorkloadIdentities)
{
    var existingIdentity = UserAssignedIdentity.FromExisting($"identity_{sanitizedName}");
    existingIdentity.Name = identityNameParam;
    infrastructure.Add(existingIdentity);

    var fedCred = new FederatedIdentityCredential($"fedcred_{sanitizedName}")
    {
        Parent = existingIdentity,
        Name = $"{resourceName}-fedcred",
        IssuerUri = /* ...aks... oidcIssuerProfile.issuerURL */,
        Subject = $"system:serviceaccount:{k8sNamespace}:{saName}",
        Audiences = { "api://AzureADTokenExchange" }
    };
    infrastructure.Add(fedCred);
}

and the matching runtime wiring (annotated ServiceAccountV1, podSpec.ServiceAccountName, the
azure.workload.identity/use label) happens in the AKS environment's prepare-aks-{name} pipeline
step — registered at AzureKubernetesEnvironmentResource.cs:47 and documented at :35 as applying
"node-pool/workload-identity annotations to compute".

Two things lock this away from anyone else:

1. It runs only inside ConfigureAksInfrastructure (AzureKubernetesEnvironmentExtensions.cs:510),
   a private static method wired exclusively as
   AzureKubernetesEnvironmentResource's infrastructure callback.
2. aksResource.WorkloadIdentities is internal
   (AzureKubernetesEnvironmentResource.cs:153 — internal Dictionary<string, IAppIdentityResource>).

A compute environment that is not the built-in AKS one therefore never runs prepare-aks, and its
generated chart has no ServiceAccount, no workload-identity pod label, and no federated
credential — even though every type involved (FederatedIdentityCredential,
KubernetesServiceCustomizationAnnotation, AppIdentityAnnotation) is public.

Is this the right ask? (division of responsibility)

Yes, with one deliberate boundary. The credential federates an identity the AppHost declares
to a service account the AppHost's own chart creates — both sides are the app's, so this is
app-model work, not platform work.

The boundary: federating a platform-owned identity (say, a shared cluster identity) is a
platform onboarding operation and is explicitly not what this asks for. We do not do that, and an
upstream API should not encourage it either.

We are also not asking Aspire to invent anything — only to make an existing, working emission
reachable.

Proposed API

 namespace Aspire.Hosting;

 public static class AzureKubernetesEnvironmentExtensions
 {
+    /// <summary>
+    /// Emits a federated identity credential linking <paramref name="identity"/> to the
+    /// Kubernetes service account <c>system:serviceaccount:{namespace}:{serviceAccount}</c>.
+    /// </summary>
+    /// <remarks>
+    /// The OIDC issuer is supplied as a value rather than read from a provisioned cluster, so this
+    /// works for a pre-existing cluster and for compute environments that provision no cluster.
+    /// </remarks>
+    public static IResourceBuilder<AzureUserAssignedIdentityResource> WithKubernetesServiceAccountFederation(
+        this IResourceBuilder<AzureUserAssignedIdentityResource> identity,
+        BicepValue<string> oidcIssuerUrl,
+        string kubernetesNamespace,
+        string serviceAccountName);
 }

Taking oidcIssuerUrl as a value is the load-bearing detail: a custom compute environment
provisions no cluster template to read oidcIssuerProfile.issuerURL from.

Usage Examples

var identity = builder.AddAzureUserAssignedIdentity("workload-identity");

identity.WithKubernetesServiceAccountFederation(
    oidcIssuerUrl: clusterIssuerUrl,      // from a parameter or platform metadata
    kubernetesNamespace: "my-namespace",
    serviceAccountName: "my-workload");

The chart-side half (ServiceAccount + pod label) is already achievable today through the public
KubernetesServiceCustomizationAnnotation, so this one addition completes the scenario.

Alternative Designs

• Make WorkloadIdentities public and extract the emission into a public static helper. Equally
  good, and arguably tidier — it would let the AKS environment and third parties share one code
  path rather than two.
• Replicate it downstream. What we do today; it is ~40 lines of stock Azure.Provisioning, but
  it means the federation subject and the service-account name are owned in two different places
  and can drift.

Risks

Low — additive, and it emits the same stock FederatedIdentityCredential the AKS environment
already emits. The one judgement call is accepting the issuer as a value, which is strictly more
permissive than reading it from a provisioned cluster.

[joperezr]

🤖 Aspire triage pass — 2026-09-01 01:01 UTC

Area: area-deployment, area-integrations
Kind: feature-request
Repro: none — API proposal; references existing source by line range in the body
Affected version(s): not specified (latest: 13.5 shipped; 13.6 in progress)
Severity: S4 — additive public API to reach existing workload-identity federation; no broken scenario

Urgency: ⚪ backlog — no milestone
Reason: additive API proposal; routes to backlog while 13.6 stabilizes

Suggested owner(s): Mitch Denny (@mitchdenny) (score ~14), backup Eric Erhardt (@eerhardt) (score ~7)
Evidence:

• mitchdenny merged Add portable volume path environment variables #19404, Fix Kubernetes hostname publishing and routing #19430, Fix Kubernetes values for embedded environment parameters #19429, Set a default fsGroup for Kubernetes persistent volumes #19374 in area-deployment (last 30d)
• mitchdenny closed [Failing test]: Aspire.Deployment.EndToEnd.Tests.AzureResourceScopeDeploymentTests.DeployExistingServiceBusWithResourceGroupAndSubscriptionScope #19173, Deployment E2E: AKS/Kubernetes tests fail due to Azure compute quota/capacity in centralus #18933, TLS FQDN discovery waits 15 minutes for skipped route-less Gateway #19217 as completed in area-deployment
• CODEOWNERS assigns Eric Erhardt (@eerhardt) Mitch Denny (@mitchdenny) to the src/Aspire.Hosting.Azure hosting family (Azure Kubernetes)
• backup: eerhardt merged Remove unnecessary friend assembly declarations #19620, Update Cosmos DB emulator defaults #19510 in area-integrations (last 30d)

Confidence: medium
Needs human?: no