Azure Container Registry – repository permissions

Azure Container Registry – repository permissions, to manage access to specific repositories within your Azure Container Registry, you can utilize repository-scoped tokens for more detailed control. While Role-Based Access Control (RBAC) allows you to assign permissions for the entire Container Registry, these repository-scoped tokens enable you to tailor access at a more granular level to individual repositories.

Use Cases

Here are some scenarios where repository-scoped tokens are ideal:

  • Granting IoT devices unique tokens to fetch an image from a particular repository.
  • Allowing an external organization access to a designated repository.
  • Regulating access to repositories for various user groups within your organization, such as giving developers who create images for certain repositories write and read permissions, and offering read-only access to teams responsible for deploying from those repositories.

Azure Container Registry – repository permissions – Terraform components

To establish this setup using Terraform, the following components are required:

  • Azure Key Vault: This is where the generated token will be stored for security, as it’s only accessible post-creation.
  • Azure Container Registry: The registry where tokens will be created for.
  • Scope Map: This acts as a permissions blueprint, allowing you to define which repositories are accessible and the level of access permitted.
  • Token: This is the actual token resource. You need to create a token for the chosen scope maps (multiple scope maps can be linked) and registries.
  • Token Password: This represents the token’s value. When you create it, you set an expiration date. It’s important to note that changing the expiration date will prompt Terraform to regenerate the token value, rendering any previous values obsolete and restricting access to the repository for users with old tokens.

For just the Terraform script, you can download it directly from the provided link. For a more detailed explanation, including some interesting Terraform functionalities, refer to the section below.

Repository permissions – repository permissions – relations

In the below diagram, I explain dependencies between resources for granting access using repository permissions:

Azure Container Registry – repository permissions

In the Scope Map, you set the repository access levels, and then you generate a Token linked to this specific scope map. Following that, two passwords can be created for the token. These passwords are utilized for authentication in the Azure Container Registry.

Azure Container Registry – token usage

Once you’ve created a password for a token, you can use it to access the registry. The command for this is shown below:

 docker login -u TOKEN_NAME -p PASSWORD_VALUE

Scope permissions

For now, the below scope permissions are available:

content/deleteRemove data from the repositoryDelete a repository or a manifest
content/readRead data from the repositoryPull an artifact
content/writeWrite data to the repositoryUse with content/read to push an artefact
metadata/readRead metadata from the repositoryList tags or manifests
metadata/writeWrite metadata to the repositoryEnable or disable read, write, or delete operations
Azure Container Registry repository-scoped permissions

Terraform Setup for Scope Map and Token

In this segment, I’ll outline the process of configuring Terraform for the creation of a Scope Map and Token in Azure Container Registry. A particularly intriguing aspect of this configuration is the token regeneration process. We need to assign an expiration date to the key, but if this date is altered with each deployment, the key will be renewed. The challenge lies in controlling when this regeneration occurs.

Let’s delve into the code below to understand this better:

resource "time_offset" "key1_year" {
  offset_days = 365

  triggers = {
    "key_version" = var.key1_version

resource "time_offset" "key2_year" {
  offset_days = 365

  triggers = {
    "key_version" = var.key2_version

I employ time_offset to add 365 days to the current date. This date will then be set as the expiration date for both key1 and key2. Additionally, I’ve implemented a trigger for this resource, which will prompt the creation of a new value whenever there’s a change in the var.key1_version or var.key2_version variable. Therefore, to regenerate the key, you simply need to modify the value of one mentioned variable. As a result, key1_year gets updated, triggering the regeneration of our key, right?

I’ve also incorporated an important guideline: You should change only one version at a time. This is crucial because it’s necessary to maintain at least one active key to ensure uninterrupted access to the repository. This approach guarantees that access is not disrupted while updating or regenerating keys.

Furthermore, I’ve enabled the creation of multiple scope maps, allowing you to customize the parameters according to your specific requirements:

variable "scope_maps" {
  type = map(object({
    name = string,
    actions   = list(string)

  default = {
    v1 = {
      name = "messagereader",
      actions = [
    v2 = {
      name = "adoagent",
      actions = [

In the above, the map variable is illustrated. Here, you designate the name and the permissions for each map. You have the flexibility to add as many maps as needed. When setting up the action, the format to follow is: repositories/REPO_NAME/PERMISSION.

I truly hope you found it enjoyable, and if that’s the case, I would be grateful for a Like or a Comment on my LinkedIn profile.

Leave a Reply

Your email address will not be published. Required fields are marked *