Share via

"ChainedTokenCredential authentication failed" accessing Key Vault inside container within Pipelines

Samuel Wederell 0 Reputation points
2026-03-10T19:30:10.0233333+00:00

I have a Typescript application that uses secrets stored within Key Vault. That application sits within a generic Docker container that pulls the application from Azure DevOps Repos and runs the code within. This container is used within an Azure DevOps Pipeline which has a Managed Identity assigned to it.

When running the Typescript code locally, I can connect to Key Vault and run the application, however when running within the pipeline I get a 'ChainedTokenCredential authentication failed' message, as though the Managed Identity is not being propagated through.

How do I pass this Managed Identity through to the container so that the Typescript 'DefaultAzureCredential' function can use it to get all the relevant secrets from KV?

Azure DevOps

1 answer

Sort by: Most helpful
  1. Pravallika KV 13,305 Reputation points Microsoft External Staff Moderator
    2026-03-10T19:42:02.6233333+00:00

    Hi @Samuel Wederell ,

    Thanks for reaching out to Microsoft Q&A.

    DefaultAzureCredential and its ChainedTokenCredential under the covers will try a bunch of mechanisms in order environment variables, Azure CLI creds, managed identity, etc. but in your pipeline container there is no managed identity endpoint to hit unless you explicitly wire one up.

    Here are a few patterns you can try:

    1. Use Azure DevOps’ built-in Key Vault task
    • Add the AzureKeyVault@2 task to your pipeline to fetch secrets into pipeline variables (or files).
    • Then pass those values into your Docker container as environment variables or mounted files.
    • Docs

    Authenticate via Workload Identity Federation (OIDC)

    • In Azure AD, create a Federated credential for your DevOps service connection (in your App Registration’s “Certificates & secrets” → “Federated credentials”).
    • Configure your pipeline’s AzureRM or Service Principal connection to emit an OIDC token.
    • In your container, DefaultAzureCredential will detect the OIDC token via the AZURE_FEDERATED_TOKEN_FILE environment variable and exchange it for an Azure AD token.

    Use Azure CLI or Service Principal environment auth

    • Before you spin up the container, run az login --identity (if you’re on a VM/ACI with MI) or az login --service-principal -u <id> -p <secret> --tenant <tid>.
    • Mount the Azure CLI token cache and/or set the standard env vars (AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID) into the container.
    • DefaultAzureCredential will pick up the CLI credential first.

    Move to a runtime that supports Managed Identity natively

    • If you run your container in an Azure Container Instance, Web App for Containers, Azure Kubernetes Service, etc., you can enable a system- or user-assigned MI at the host level.
    • Inside your container DefaultAzureCredential will then find the IMDS endpoint and work as it does locally when your VM has a MI.

    Fetch secrets with AzureKeyVault@2

    Federated credentials for Azure DevOps OIDC

    ChainedTokenCredential / DefaultAzureCredential overview

    Managed Identity guidance

    Hope this helps!


    If the resolution was helpful, kindly take a moment to click on User's imageand click on Yes for was this answer helpful. And, if you have any further query do let us know.

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.