Изменить

Поделиться через


Azure Container Registry Entra permissions and roles overview

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:

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:

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.
  • 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.
  • 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.
    • For signing images with Docker Content Trust (DCT):
  • Scenario: Pipelines, identities, and developers that need to create, update, or delete ACR registries

  • 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.
  • 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 and Container 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.
  • Scenario: Pipelines and identities that orchestrate ACR tasks

  • 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.
  • 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.
  • Scenario: Management of quarantined images

    • Roles: AcrQuarantineReader and AcrQuarantineWriter
    • 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.
  • 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.
  • Scenario: Developers or processes that configure registry auto-purge on ACR Tasks

  • Scenario: Visual Studio Code Docker extension users

    • Roles: AcrPush, Container Registry Tasks Contributor, and Container 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.

Next steps