Proposal: Consolidate MSAL Region Discovery onto the IMDS `/compute` Endpoint

[gladjohn]

Task: Use the newer IMDS /compute endpoint for region discovery

Why

/metadata/instance/compute with API version 2021-02-01 is the newer, more reliable IMDS endpoint. Use it for region discovery.

Change

RegionManager calls:

GET http://169.254.169.254/metadata/instance/compute?api-version=2021-02-01
Headers: Metadata: true

Parse the JSON response and read the location field. Cache the result process-wide. REGION_NAME env var still wins first.

Result

• Newer, more reliable IMDS endpoint.
• No public API change. Existing region telemetry unchanged.

Acceptance

• RegionManager calls /compute with 2021-02-01.
• location parsed from the JSON response.
• Existing region discovery tests pass.

[github-actions]

Here are some similar issues that might help you. Please check if they can solve your problem.

• [Feature Request] Add Compute Metadata Detection API for MSI mTLS PoP Capability on IMDS #5969

---

Possible solution (Extracted from existing issue, might be incorrect; please verify carefully)

Solution 1:

Updated the issue description with a consolidated design:

public sealed class AzureComputeMetadata
{
    // Cloud / location
    public string AzureCloudEnvironment { get; }
    public string Location { get; }
    public string Zone { get; }

    // Identity
    public string VmId { get; }
    public string VmName { get; }
    public string VmSize { get; }
    public string SubscriptionId { get; }
    public string ResourceGroupName { get; }
    public string ResourceId { get; }

    // OS — explicit per ask
    public string OsType { get; }       // "Windows" / "Linux"
    public string OsVersion { get; }

    // Security (strongly typed)
    public AzureSecurityProfile SecurityProfile { get; }

    // The primary answer to the issue — rule lives here, not in every caller
    public bool SupportsMtlsPop { get; }

    // Forward-compat: any IMDS field MSAL hasn't promoted yet
    public IReadOnlyDictionary<string, JsonElement> AdditionalProperties { get; }
}

public sealed class AzureSecurityProfile
{
    public AzureVmSecurityType SecurityType { get; }   // enum, not magic string
    public bool IsTrustedLaunch          { get; }
    public bool IsConfidentialVm         { get; }
    public bool IsSecureBootEnabled      { get; }
    public bool IsVirtualTpmEnabled      { get; }
    public bool IsEncryptionAtHostEnabled{ get; }
}

public enum AzureVmSecurityType { Unknown = 0, Standard, TrustedLaunch, ConfidentialVM }

This shape lands both asks at once:

• Explicit IsTrustedLaunch, IsSecureBoot, OsType etc., no string comparisons.
• The API stays generic; new IMDS fields land as new strongly-typed properties (non-breaking) and unknown fields are still accessible via AdditionalProperties.

Reference:

• [Feature Request] Add Compute Metadata Detection API for MSI mTLS PoP Capability on IMDS #5969 (comment)

Solution 2:

Thinking more on this - it makes sense to extend the current GetSources API to be more generic, maybe a GetAzureSourceAndCapabilities API.

Reference:

• [Feature Request] Add Compute Metadata Detection API for MSI mTLS PoP Capability on IMDS #5969 (comment)

Powered by issue-sentinel