Secure Client-Specific Access for Pulling Images from Azure Container Registry to Azure Kubernetes Service

Question

I’m currently working on a Cloud FinOps platform where we host application container images in Azure Container Registry (ACR). At present, we share the registry username and password with clients so they can pull images into their Azure Kubernetes Service (AKS) clusters. However, this approach raises security concerns because shared credentials could potentially be misused, leading to unauthorized access to the registry.

We are looking for a more secure and scalable way to provide client-specific pull access to ACR images, preferably using identity-based authentication, scoped permissions, or another recommended best practice that avoids credential sharing. Since most clients pull images directly into AKS environments, we are particularly interested in the best secure approach for AKS-to-ACR image pulls on the ACR Standard tier, ideally leveraging Azure AD integration or workload identity federation to ensure least-privilege, tenant-specific access without exposing static credentials.

Answer 1

Hello @RajKumar Kannan,

To enhance security when providing client-specific access to Azure Container Registry (ACR) images, consider implementing Azure Active Directory (Azure AD) authentication. This allows clients to authenticate using their Azure AD identities, which can be managed centrally. By assigning roles through Microsoft Entra role-based access control (RBAC), you can grant clients specific permissions to pull images from ACR without sharing credentials. This method not only secures access but also allows you to revoke permissions easily if needed.

Another recommended practice is to use service principals for AKS to ACR authentication. A service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. By creating a service principal for each client and granting it the necessary permissions to pull images from ACR, you can ensure that each client has a unique identity and access scope, reducing the risk of unauthorized access.

---

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 2

Hello RajKumar,

Thanks for reaching out Q/A.

For AKS‑to‑ACR image pulls, Azure provides secure and scalable identity‑based alternatives that work on the ACR Standard tier and support least‑privilege, client‑specific access, without relying on shared credentials.

The recommended approach is to integrate Azure Kubernetes Service with Microsoft Entra ID and authenticate to ACR using the AKS managed identity. Each AKS cluster is assigned its own identity, and that identity is granted only the AcrPull role on the registry using Azure RBAC.

AKS securely pulls images using Entra‑issued tokens, eliminating stored passwords, Docker pull secrets, or shared admin accounts. This enables least‑privilege access and allows permissions to be managed or revoked per client.

For scenarios where client AKS clusters exist in different Microsoft Entra tenants, you can create a dedicated service principal per client and assign it the AcrPull role on the registry. This avoids shared credentials while maintaining strong access isolation and auditability.

We also recommend disabling the ACR Admin User once identity‑based access is configured, to ensure all authentication flows through Entra ID and Azure RBAC.

References:

• Authenticate with Azure Container Registry (ACR) from Azure Kubernetes Service (AKS
• Authenticate with Azure Container Registry
• Azure Container Registry Entra permissions and role assignments overview
• Use Kubernetes RBAC with Microsoft Entra ID in AKS

Hope this helps! Please let me know if you have any queries.