Share via

How to pull image from ACR?

Padmanabhan M 220 Reputation points
2026-03-19T07:18:45.0366667+00:00

We are deploying an AKS cluster and pulling container images from Azure Container Registry (ACR) without assigning the AcrPull role to the managed identity .

Instead, our ARM template deployment script uses a User Assigned Managed Identity to call az acr login --expose-token, which returns a short-lived ACR token.

This token is then used as the password in a Kubernetes docker-registry secret (cloudcadi-acr-secret) and also for helm registry login during Helm chart deployment — with 00000000-0000-0000-0000-000000000000 as the fixed username.

Our pods reference this secret via imagePullSecrets in the Helm chart, allowing AKS nodes to pull images from ACR at runtime. Is this a supported and recommended approach for ACR authentication in AKS?

Can we pull the images using the username and password instead of assigning any roles?

Is it correct way to get the image from tha acr?

Azure Container Registry
Azure Container Registry

An Azure service that provides a registry of Docker and Open Container Initiative images.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Manish Deshpande 6,835 Reputation points Microsoft External Staff Moderator
    2026-03-19T07:49:09.91+00:00

    Thank you for sharing the details of your setup.

    While using az acr login --expose-token to generate a short‑lived token and storing it in a Kubernetes docker-registry secret can work technically, this approach is not the recommended or supported primary authentication model for Azure Kubernetes Service (AKS) when pulling images from Azure Container Registry (ACR).

    For AKS clusters, Microsoft strongly recommends using managed identities with Azure RBAC to authenticate to ACR. Specifically:

    • Assign the AcrPull role (or Container Registry Repository Reader for ABAC‑enabled registries) to the AKS kubelet (node) managed identity.
    • This enables AKS nodes to pull images natively and securely, without storing credentials or tokens in Kubernetes secrets.

    This integration is built into AKS and is the most secure, scalable, and supported pattern for AKS–ACR authentication.

    AKS automatically uses the kubelet managed identity to authenticate to ACR when the appropriate role is assigned, eliminating the need for image pull secrets.
    https://learn.microsoft.com/en-us/azure/aks/cluster-container-registry-integration?tabs=azure-cli

    Your current approach—using a short‑lived ACR token generated via --expose-token and storing it in an imagePullSecrets—has the following limitations:

    • Tokens are short‑lived and require rotation; expired tokens can cause unexpected image pull failures.
    • Credentials are stored as Kubernetes secrets, which increases operational and security overhead.
    • This pattern is not the recommended model for AKS, and is primarily intended for:
      • Non‑AKS Kubernetes clusters
        • External or cross‑tenant registries
          • Specialized scenarios where managed identity cannot be used

    Microsoft documentation explicitly notes that image pull secrets are mainly intended for external or non‑AKS clusters, not for native AKS–ACR integration.

    Authenticate ACR from Kubernetes
    https://docs.azure.cn/en-us/container-registry/authenticate-kubernetes-options

    For a production‑ready and fully supported configuration, we recommend:

    1. Identify the AKS kubelet managed identity.
    2. Assign the AcrPull role (or Container Registry Repository Reader if ABAC is enabled) at the ACR scope.
    3. Remove dependency on imagePullSecrets for ACR authentication.

    If the issue persists or if you have specific constraints that prevent using managed identity–based authentication, please share the details in the Comment section, and we will be happy to assist you further and respond promptly.

    Also I have requested few details over the private chat please respond at your earliest.

    Thanks.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-03-19T07:19:05.3766667+00:00

    Using a short‑lived ACR access token in a Kubernetes docker-registry secret technically works for pulling images, but it is not the recommended or supported primary pattern for AKS–ACR integration.

    Supported and recommended patterns from the context are:

    1. AKS managed identity + AcrPull / Container Registry Repository Reader role
      • AKS is designed to pull from ACR by assigning a registry pull role to the kubelet (node) managed identity.
      • The documented integration assigns either:
        • AcrPull for non‑ABAC registries, or
        • Container Registry Repository Reader for ABAC‑enabled registries,
          directly to the kubelet identity so nodes can pull images without storing credentials in Kubernetes secrets.
      • This is the native, recommended approach for AKS:
        • “You can set up the AKS to Container Registry integration… This integration assigns either the Container Registry Repository Reader role … or the AcrPull role … for the kubelet identity that’s associated with the AKS cluster to pull images from a container registry.”
    2. Image pull secrets for non‑AKS or external registries
      • Image pull secrets (type: kubernetes.io/dockerconfigjson / docker-registry) are documented primarily for:
        • AKS Arc / on‑prem clusters, or
        • pulling from private external registries.
      • The pattern is:
        • Create a secret with kubectl create secret docker-registry … --docker-server=<REGISTRY_NAME>.azurecr.io --docker-username=<appId> --docker-password=<password>.
        • Reference it via imagePullSecrets in pod/deployment specs.
      • This is a supported pattern, but the examples use service principal credentials, not short‑lived az acr login --expose-token tokens.

    Security and limitations of the token‑in‑secret approach compared to AcrPull on kubelet identity:

    • Credential storage:
      • With kubelet managed identity + AcrPull, no registry credentials are stored in Kubernetes; access is via Microsoft Entra tokens and RBAC.
      • With your approach, a bearer token is stored in a Kubernetes secret. Anyone with read access to that secret can reuse the token while it is valid.
    • Token lifetime and rotation:
      • az acr login --expose-token returns a short‑lived token. Once it expires, image pulls using that secret will fail until the secret is updated and pods are recreated or restarted.
      • The managed identity + AcrPull model handles token issuance and rotation automatically; there is no need to update Kubernetes objects.
    • Role granularity and least privilege:
      • The recommended model is to grant pull‑only roles (AcrPull or Container Registry Repository Reader) to the kubelet identity.
      • In your flow, the User Assigned Managed Identity has Contributor on the resource group, which is broader than necessary. Best practice is to grant the minimal ACR role directly to the identity that needs it.
    • Operational complexity:
      • Using az acr login --expose-token in deployment automation requires a reliable rotation mechanism and re‑deployment/restart of workloads when tokens change.
      • Native AKS–ACR integration avoids this complexity.

    Summary:

    • The correct and recommended way for AKS to pull images from ACR is to assign AcrPull (or Container Registry Repository Reader for ABAC) to the AKS kubelet managed identity and let AKS authenticate natively.
    • Image pull secrets are supported and recommended mainly for on‑prem/AKS Arc or external registries; using short‑lived expose-token values in secrets is functional but introduces token‑expiry and secret‑management overhead and is less secure than identity‑based integration.
    • For long‑term, production‑grade AKS–ACR integration, switching to kubelet managed identity + AcrPull is recommended.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.