Add Azure Managed Identity authentication support

[nightflight-dk]

What does the PR do?

Adds Azure Managed Identity (MI) and DefaultAzureCredential authentication support for Azure Storage-backed model repositories, addressing a long-standing request from enterprise users who cannot distribute or rotate shared storage account keys.

This PR contains the server-side changes (documentation + integration tests). The companion core changes (C++ implementation in ASCredential / ASFileSystem) are in triton-inference-server/core#468.

New authentication modes (controlled via AZURE_STORAGE_AUTH_TYPE env var or credential file):

auth_type	Credential used	Use case
"key" (default)	Shared key (AZURE_STORAGE_KEY)	Backwards-compatible, existing behavior
"managed_identity"	ManagedIdentityCredential	Production on Azure VMs / AKS / VMSS
"default"	DefaultAzureCredential chain	Local dev, CI, multi-cloud

For user-assigned MI, optionally set AZURE_STORAGE_CLIENT_ID (env var or client_id in credential file).

Checklist

• I have read the Contribution guidelines and signed the Contributor License Agreement
• PR title reflects the change and is of format <commit_type>: <Title>
• Changes are described in the pull request.
• Related issues are referenced.
• Populated github labels field
• Added test plan and verified test passes.
• Verified that the PR passes existing CI.
• I ran pre-commit locally (pre-commit install, pre-commit run --all)
• Verified copyright is correct on all changed files.
• Added succinct git squash message before merging ref.
• All template sections are filled out.
• Optional: Additional screenshots for behavior/output changes with before/after.

Commit Type:

• build
• ci
• docs
• feat
• fix
• perf
• refactor
• revert
• style
• test

Related PRs:

• Dependency: triton-inference-server/core#468 — C++ implementation adding azure-identity-cpp dependency, extending ASCredential with auth_type_/client_id_, and branching ASFileSystem constructor for MI/Default/Key credential flows. This server PR requires core#468 to be merged first.

Third-party build changes

The existing azure-sdk ExternalProject_Add in third_party/CMakeLists.txt already clones the full Azure/azure-sdk-for-cpp monorepo at tag azure-storage-blobs_12.13.0. That monorepo builds all SDK packages by default — including azure-identity-cpp — so the installed artifacts at ${TRITON_THIRD_PARTY_INSTALL_PREFIX}/azure-sdk/ should already contain:

share/azure-identity-cpp/azure-identity-cppConfig.cmake
lib/libazure-identity.a
include/azure/identity/...

The only change needed is to verify (or bump) the tag so that the installed azure-identity-cpp version is compatible with the headers used in core#468. If core's find_package(azure-identity-cpp CONFIG REQUIRED) fails at build time, bump the tag to a newer monorepo release (e.g. azure-identity_1.10.0) that includes both packages:

# In third_party/CMakeLists.txt — only if tag bump is needed:
ExternalProject_Add(azure-sdk
  ...
  GIT_TAG "azure-identity_1.10.0"   # was: azure-storage-blobs_12.13.0
  ...
)

No other third-party changes are required — azure-identity-cpp has no additional external dependencies beyond azure-core (already built as part of the monorepo).

Where should the reviewer start?

1. docs/user_guide/model_repository.md — new "Azure Managed Identity Authentication" subsection documenting env vars, prerequisites, and sovereign cloud support.
2. qa/L0_storage_azure/test.sh — MI integration tests (system MI, user MI, DefaultAzureCredential, invalid auth_type rejection), gated behind TEST_AZURE_MANAGED_IDENTITY.

Test plan:

1. Existing shared-key tests pass unchanged — the for ENV_VAR in "shared_key" loop is untouched.
2. MI tests (gated behind TEST_AZURE_MANAGED_IDENTITY env var, require MI-capable host):
   • System-assigned MI: starts Triton with AZURE_STORAGE_AUTH_TYPE=managed_identity, runs inference.
   • User-assigned MI: additionally sets AZURE_STORAGE_CLIENT_ID, runs inference.
   • DefaultAzureCredential: sets AZURE_STORAGE_AUTH_TYPE=default, runs inference.
   • Invalid auth_type: sets AZURE_STORAGE_AUTH_TYPE=invalid_type, verifies server rejects it with "Unable to create Azure filesystem client".
3. Manual validation: DefaultAzureCredential → AzureCliCredential chain successfully listed and fetched blobs from a real Azure Storage account using the Python Azure SDK as a smoke test.

Caveats:

• MI tests cannot run on bare macOS/non-Azure hosts (no IMDS at 169.254.169.254). They are gated behind the TEST_AZURE_MANAGED_IDENTITY env var and should be enabled only in CI jobs running on Azure VMs or AKS nodes with a configured managed identity.
• The third-party azure-sdk tag may need a bump if the current tag's azure-identity-cpp version is too old for the headers used in core#468. See Third-party build changes above.

Backwards compatibility:

• Existing credential files without auth_type and client_id fields continue to work as before (defaults to shared key authentication).
• No changes to the existing shared-key or environment-variable workflows.

Background

GitHub issue #8614 requested Azure Managed Identity support for Triton model repositories. Enterprise deployments on Azure (AKS, VMs, VMSS) strongly prefer MI over shared keys for security, compliance, and operational simplicity — no secrets to rotate, no keys to distribute, and built-in RBAC integration via Storage Blob Data Reader.

The Azure C++ SDK ships azure-identity-cpp which provides ManagedIdentityCredential and DefaultAzureCredential classes, making the implementation straightforward as an extension of the existing ASCredential/ASFileSystem code in the core repo.

Related Issues:

• Closes GitHub issue: Support Azure Managed Identity authentication for Azure Storage-backed model repositories (in addition to key-based auth) #8614

[whoisj]

LGTM

[whoisj]

Fixing copyright headers.