Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure Container Registry (ACR) offers a set of built-in roles that provide Entra-based permissions management to an ACR registry. Using Azure role-based access control (Azure RBAC), you can assign a built-in role to users, managed identities, or service principals to grant Entra-based permissions defined within the role. You can also define and assign custom roles with fine-grained permissions tailored to your specific needs if the built-in roles below don't meet your requirements.
Supported role assignment identity types
ACR roles can be assigned to the following identity types to grant permissions to a registry:
- Individual user identity
- Managed identity for Azure resources
- Azure DevOps - Azure Pipelines identity
- Azure Kubernetes Service (AKS) node's kubelet identity to enable the AKS node to pull images from ACR. ACR supports role assignments for both AKS-managed kubelet identity and AKS pre-created kubelet identity for AKS nodes to pull images from ACR.
- Azure Container Apps (ACA) identity
- Azure Container Instances (ACI) identity
- Azure Machine Learning (AML) workspace identity
- AML-attached Kubernetes cluster node kubelet identity to allow the Kubernetes cluster's nodes to pull images from ACR.
- AML online endpoint identity
- Azure App Service identity
- Azure Web Apps identity
- Azure Batch identity
- Azure Functions identity
- Service principal
- AKS cluster service principal to enable AKS nodes to pull images from ACR. ACR also supports cross-tenant AKS node to ACR authentication through cross-tenant service principal role assignments and authentication.
- ACI service principal
- Hybrid or on-premises AKS clusters on Azure Stack Hub using service principal
Take note that ACR connected registry, ACR's on-premises registry offering that differs from cloud-based ACR, doesn't support Azure role assignments and Entra-based permissions management.
Performing role assignments to grant permissions
See Steps to add a role assignment for information on how to assign a role to an identity. Role assignments can be made using:
Recommended built-in roles by scenario
Apply the principle of least privilege by assigning only the permissions necessary for an identity to perform its intended function. These common scenarios each have a recommended built-in role.
Scenario: Identities that need to pull images and validate supply chain artifacts such as developers, pipelines, and container orchestrators (for example, Azure Kubernetes Service node kubelet identity, Azure Container Apps, Azure Container Instances, Azure Machine Learning workspaces)
- Role:
AcrPull
- Purpose: Grants data plane read-only access to pull images and artifacts, view tags, repositories, Open Container Initiative (OCI) referrers, and artifact streaming configurations. Doesn't include any control plane or write permissions.
- Role:
Scenario: Identities such as CI/CD build pipelines and developers that build and push images, as well as manage image tags
- Role:
AcrPush
- Permissions: Grants data plane access to push and pull images and artifacts, manage tags, work with OCI referrers, and configure artifact streaming for repositories and images. Doesn't include any control plane permissions.
- Role:
Scenario: Pipelines, identities, and developers that sign images
- For signing images with OCI referrers such as Notary Project:
- Role:
AcrPush
- Permissions: Grants data plane access to push signatures in the form of OCI referrers attached to images and artifacts. Doesn't include any control plane permissions.
- Role:
- For signing images with Docker Content Trust (DCT):
- Role:
AcrImageSigner
- Permissions: Sign images in the registry with Docker Content Trust (DCT).
- Note: Docker Content Trust is being deprecated.
- Role:
- For signing images with OCI referrers such as Notary Project:
Scenario: Pipelines, identities, and developers that need to create, update, or delete ACR registries
- Role:
Container Registry Contributor and Data Access Configuration Administrator
- Permissions:
- Grants control plane access to create, configure, manage, and delete registries, including:
- configure registry SKUs
- authentication access settings (admin user login credentials, anonymous pull, tokens and scope maps, and Entra authentication-as-arm token audience),
- high availability features (geo-replications, availability zones, and zone redundancy),
- on-premises features (connected registries),
- registry endpoints (dedicated data endpoints)
- network access (private link and private endpoint settings, public network access, trusted services bypass, network firewall rules, and Virtual Network (VNET) service endpoints)
- registry policies (retention policy, registry-wide quarantine enablement, soft-delete enablement, and data exfiltration export policy)
- diagnostics and monitoring settings (diagnostic settings, logs, metrics, webhooks for registries and geo-replications, and Event Grid)
- manage a registry's system-assigned managed identity
- Note: this role grants permissions to delete the registry itself.
- Note: this role doesn't include data plane operations (for example, image push/pull), role assignment capabilities, or ACR task.
- Note: to manage a registry's user-assigned managed identity, the assignee must also have the
Managed Identity Operator
role.
- Grants control plane access to create, configure, manage, and delete registries, including:
- Role:
Scenario: Pipelines, infrastructure engineers, or control plane observability/monitoring tools that need to list registries and view registry configurations, but not access to registry images
- Role:
Container Registry Configuration Reader and Data Access Configuration Reader
- Permissions: Read-only counterpart of the
Container Registry Contributor and Data Access Configuration Administrator
role. Grants control plane access to view and list registries and inspect registry configurations, but not modify them. Doesn't include data plane operations (for example, image push/pull) or role assignment capabilities.
- Role:
Scenario: Vulnerability scanners and tools that need to audit registries and registry configurations, as well as access to registry images to scan them for vulnerabilities
- Roles:
AcrPull
andContainer Registry Configuration Reader and Data Access Configuration Reader
- Permissions: Grants control plane access to view and list ACR registries, as well as to audit registry configurations for audit and compliance. Also grants permissions to pull images, artifacts, and view tags to scan and analyze images for vulnerabilities.
- Roles:
Scenario: Pipelines and identities that orchestrate ACR tasks
- Role:
Container Registry Tasks Contributor
- Permissions: Manage ACR tasks, including task definitions and task runs, task agent pools, quick builds with
az acr build
and quick runs withaz acr run
, and task logs. Doesn't include data plane permissions or broader registry configuration - Note: to fully manage task identities, the assignee must have the
Managed Identity Operator
role.
- Role:
Scenario: Identities such as pipelines and developers that import images with
az acr import
- Role:
Container Registry Data Importer and Data Reader
- Permissions: Grants control plane access to trigger image imports using
az acr import
, and data plane access to validate import success (pull imported images and artifacts, view repository contents, list OCI referrers, and inspect imported tags). Doesn't allow pushing or modifying any content in the registry.
- Role:
Scenario: Identities such as pipelines and developers that manage ACR transfer pipelines for transferring artifacts between registries using intermediary storage accounts across network, tenant, or air gap boundaries
- Role:
Container Registry Transfer Pipeline Contributor
- Permissions: Grants control plane access to manage ACR import/export transfer pipelines and pipeline runs using intermediary storage accounts. Doesn't include data plane permissions, broader registry access, or permissions to manage other Azure resource types such as storage accounts or key vaults.
- Role:
Scenario: Management of quarantined images
- Roles:
AcrQuarantineReader
andAcrQuarantineWriter
- Permissions: Manage quarantined images in the registry, including listing and pulling quarantined images for further inspection, and modifying the quarantine status of images. Quarantined images are pushed images that can't be pulled or used until they're unquarantined.
- Roles:
Scenario: Deleting images, artifacts, tags, and OCI referrers
- Role:
AcrDelete
- Permissions: Provides permissions to delete artifacts and tags across all repositories in the registry. This role doesn't grant permissions to delete the registry itself.
- Role:
Scenario: Developers or processes that configure registry auto-purge on ACR Tasks
- Role:
Container Registry Tasks Contributor
- Permissions: Grants control plane permissions to manage auto-purge, which runs on ACR Tasks.
- Role:
Scenario: Visual Studio Code Docker extension users
- Roles:
AcrPush
,Container Registry Tasks Contributor
, andContainer Registry Contributor and Data Access Configuration Administrator
- Permissions: Grants capabilities to browse registries, pull and push images, and build images using
az acr build
, supporting common developer workflows in Visual Studio Code.
- Roles:
Next steps
- For a detailed reference of every ACR built-in role, including the permissions granted by each role, see the Azure Container Registry roles directory reference.
- For more information on creating custom roles that meet your specific needs and requirements, see Azure Container Registry custom roles.