Detect system-assigned managed identities in AzureCredentialHelper by DavidZidar · Pull Request #15885 · microsoft/aspire

DavidZidar · 2026-04-04T00:48:57Z

Description

This should restore support for system-assigned managed identities.

When system-assigned managed identities are enabled the IDENTITY_ENDPOINT and IDENTITY_HEADER environment variables are defined. It should be enough to detect the endpoint variable for this purpose.

AZURE_CLIENT_ID is still used by user-managed identities.

Reference:
https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=portal%2Chttp#rest-endpoint-reference

Fixes #15879

Checklist

Is this feature complete?
- Yes. Ready to ship.
- No. Follow-up changes expected.
Are you including unit tests for the changes and scenario tests if relevant?
- Yes
- No
Did you add public API?
- Yes
  - If yes, did you have an API Review for it?
    - Yes
    - No
  - Did you add <remarks /> and <code /> elements on your triple slash comments?
    - Yes
    - No
- No
Does the change make any security assumptions or guarantees?
- Yes
  - If yes, have you done a threat model and had a security review?
    - Yes
    - No
- No
Does the change require an update in our Aspire docs?
- Yes
  - Link to aspire.dev issue:
    - New issue
- No

github-actions · 2026-04-04T00:49:14Z

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15885

Or

Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15885"

Copilot

Pull request overview

Restores managed-identity support in AzureCredentialHelper for Azure App Service deployments by detecting system-assigned managed identity signals and selecting a managed-identity credential path instead of falling back to development credentials.

Changes:

Detects IDENTITY_ENDPOINT (in addition to AZURE_CLIENT_ID) to decide when to use ManagedIdentityCredential.
Adds an inline comment clarifying why IDENTITY_ENDPOINT is checked.

src/Shared/AzureCredentialHelper.cs

When system-assigned managed identities are enabled the IDENTITY_ENDPOINT and IDENTITY_HEADER environment variables are defined. It should be enough to detect the endpoint variable for this purpose. AZURE_CLIENT_ID is still used by user-managed identities. Reference: https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=portal%2Chttp#rest-endpoint-reference

DavidZidar · 2026-04-04T11:38:02Z

Copilot pointed out that the code doesn't seem to be working for user-assigned managed identities either so I made the suggested adjustments (with some minor tweaks) to account for this too.

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

radical · 2026-04-07T01:13:04Z

@eerhardt

JamesNK

@eerhardt Please take a look before merge.

eerhardt · 2026-04-07T14:23:53Z

src/Shared/AzureCredentialHelper.cs


-        if (Environment.GetEnvironmentVariable("AZURE_CLIENT_ID") is not null)
+        var azureClientId = Environment.GetEnvironmentVariable("AZURE_CLIENT_ID");
+        var identityEndpoint = Environment.GetEnvironmentVariable("IDENTITY_ENDPOINT");


I have a few concerns with this approach.

Aspire by default configures a user-assigned identity. In order to use a system-assigned identity, you need to customize the app. It isn't unreasonable to also need to configure the settings.Credential property inside the app as well. See the comment that said "just use ManagedIdentityCredential because that's the only credential type that Aspire Hosting enables by default." (which is now wrong because it also says system-assigned)

Looking at the Azure SDK code, I see an unused property (EnvironmentVariables.IdentityEndpoint) reading the IDENTITY_ENDPOINT environment variable. But no one reads that property. So I'm not sure if this is the right env var to read.

cc @scottaddie @m-nash @christothes

That would be fine if this was code intended to be run only in Aspire. But currently the AzureCredentialHelper class is incompatible with Azure without extra modification and the documentation do not say that Credential must be replaced to be able to deploy to Azure.

That is the correct environment variable, see https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=portal%2Chttp#rest-endpoint-reference

IDENTITY_ENDPOINT is only expected to be present in App Service or Azure Functions - it's not a general indicator of the presence of a system assigned identity, if that was your intent here.

That's good to know, is there a general way to detect this? My intent is to restore functionality that's currently broken because DefaultAzureCredential is no longer in use like before. I understand it's not recommended in production but the current solution is worse.

Perhaps the logic can be reversed so that it detects Aspire instead and customizes credentials for that use case? When not detected use DefaultAzureCredential like before.

I'm using the Aspire.Azure.Security.KeyVault package to add KeyVault secrets to my configuration using AddAzureKeyVaultSecrets. This has been working well for a while now but suddenly broke when I tried to deploy my solution to Azure after I updated packages recently and I had to spend 2 hours figuring out what had happened.

Before the change in #14951 the package was using DefaultAzureCredential which correctly figured out to use system-assigned managed identity, but it no longer works out of the box in Azure and Credential has to be set manually if one wants to use the Aspire packages.

Plus, the documentation makes no mention that Credential must be set manually to be able to use system-managed identities which didn't help.

https://aspire.dev/integrations/cloud/azure/azure-key-vault/azure-key-vault-client/

https://aspire.dev/integrations/cloud/azure/azure-default-credential/

Might I suggest a different approach.

If Aspire must use custom heuristics to figure out what credentials to use then at least fall back to the DefaultAzureCredential with all options enabled if no certain option could be determined and perhaps log a warning in non development environments that it's recommended to set Credential explicitly. If DefaultAzureCredential needs to be avoided in production completely then at least throw a more informative exception referring to best practices and what to do.

The current failure mode is not good, it throws a pretty obtuse message that lists a lot of providers and it's up to the user to figure out what might be wrong. This is why it took me so long to get unblocked.

We've been trying to encourage, via our APIs in Azure.Identity, that developers be explicit with which managed identity they expect, since the defaults can cause unexpected behavior. For example, if no preference is expressed in how the credential is configured, the following will occur:

No system assigned identity is configured

no user-assigned MI is configured

error

exactly 1 UAMI is configured

the UAMI is used

More than 1 UAMI is configured

error

SAMI is configured

no user-assigned MI is configured

SAMI is used

exactly 1 UAMI is configured

the UAMI is used

More than 1 UAMI is configured

error

I'm not opposed to encouraging, it's good to steer people into the pit of success. That's why I suggested logging a warning. But the current solution breaks people apps, that's more than some encouraging. I already spent the time and figured out why my app suddenly broke but there will be more people that will be hit by this change when they try to deploy their things to Azure, hopefully not directly to production.

eerhardt · 2026-04-07T14:27:03Z

src/Shared/AzureCredentialHelper.cs

+            var managedIdentityId = !string.IsNullOrWhiteSpace(azureClientId)
+                ? ManagedIdentityId.FromUserAssignedClientId(azureClientId)
+                : ManagedIdentityId.SystemAssigned;


If we are going to take this approach, I think I'd prefer less branches. Something like:

if (Environment.GetEnvironmentVariable("AZURE_CLIENT_ID") is not null) { // When we don't see DefaultEnvironmentVariableName, but we do see AZURE_CLIENT_ID, // we just use ManagedIdentityCredential because that's the only credential type that // Aspire Hosting enables by default. // If this doesn't work for applications, they can override the TokenCredential in their settings. return new ManagedIdentityCredential(new ManagedIdentityCredentialOptions()); } else if (Environment.GetEnvironmentVariable("IDENTITY_ENDPOINT") is not null) { // <insert reasoning> return new ManagedIdentityCredential(new ManagedIdentityCredentialOptions(ManagedIdentityId.SystemAssigned)); } // when we can't detect a known Azure environment, fall back to the development credential return CreateDevelopmentAzureCredential();

Copilot AI review requested due to automatic review settings April 4, 2026 00:48

Copilot started reviewing on behalf of DavidZidar April 4, 2026 00:50 View session

Copilot AI reviewed Apr 4, 2026

View reviewed changes

src/Shared/AzureCredentialHelper.cs Outdated Show resolved Hide resolved

src/Shared/AzureCredentialHelper.cs Outdated Show resolved Hide resolved

github-actions bot mentioned this pull request Apr 4, 2026

[pull requests] Review required #13834

Open

DavidZidar force-pushed the fix-system-assigned-credential-support branch from 60f26ad to 05cce1c Compare April 4, 2026 11:35

DavidZidar requested a review from Copilot April 5, 2026 13:42

Copilot started reviewing on behalf of DavidZidar April 5, 2026 13:43 View session

Copilot AI reviewed Apr 5, 2026

View reviewed changes

JamesNK approved these changes Apr 7, 2026

View reviewed changes

eerhardt reviewed Apr 7, 2026

View reviewed changes

Conversation

DavidZidar commented Apr 4, 2026

Description

Checklist

Uh oh!

github-actions bot commented Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

DavidZidar commented Apr 4, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

radical commented Apr 7, 2026

Uh oh!

JamesNK left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

github-actions bot commented Apr 4, 2026 •

edited

Loading