What Is Azure Container Registry?
Azure Container Registry (ACR) is a cloud-based service for managed, private registries based on Docker Registry 2.0. You can use it to create and maintain Docker container registries in the Azure cloud, using them to manage and store Docker images and artifacts privately.
ACR can integrate with existing container-based application development and deployment pipelines. You can create a container image in Azure by using Azure Container Registry Tasks. This lets you fully automate your builds using triggers like base-image updates and source code commits or build images on-demand .
This is part of our series of articles about container platforms.
In this article:
- Azure Container Registry Features and Capabilities
- Best Practices for Azure Container Registry
- Network-Close Deployment
- Geo-replicate Multi-Region Deployments
- Maximize Pull Performance
- Dedicated Resource Group
- Addressing Container Registry Security Risks in ACR
- Public Registry Images
- Internal Security Controls
- Outdated Packages and Libraries
- Mishandling Secrets
- Container Registry Security with Aqua
Azure Container Registry Features and Capabilities
You can use Azure Container Registry (ACR) service in one of two ways:
- Integrate ACR with an existing development and deployment pipeline
- Use ACR tasks to build a container image in Azure.
You can build images on demand or automate your builds using various triggers, including source code commits or base-image updates.
Each image in the repository is a read-only container snapshot, which is compatible with Docker. Azure Container Registry can contain both Linux and Windows images. Aside from Docker container images, you can use Azure Container Registry to store other content formats, including Open Container Initiative (OCI) images and Helm charts.
You can use Azure Container Registry Tasks (ACR Tasks) to simplify the build, test, push, and deployment phases of the container image pipeline in Azure. Configuring build tasks allows you to automate updates to containers, operating systems, and patches, and automatically build images when your teams commit code to source control.
ACR is available in several service tiers. All tiers offer the same capabilities, but different storage and throughput:
- Basic—included storage and throughput is appropriate for smaller usage scenarios.
- Standard—increased storage and throughput suitable for production scenarios.
- Premium—the highest quantity of storage and concurrent operation, with features like zone redundancy (replicating the repository to three separate zones in the same region), geo-replication, content trust, and private links with private endpoints.
All service tiers provide the following storage features:
- Encrypted storage—all container images in the registry are encrypted at rest. Azure automatically encrypts images before they are stored and decrypts them immediately when they are retrieved.
- Regional storage—ACR automatically stores data in the region where the registry is created to help customers meet their data residency and compliance requirements.
- Unlimited objects—ACR lets you create as many repositories, images, layers, or tags as needed, up to the registry storage limits.
Related content: Read our guide to Azure DevOps
Best Practices for Azure Container Registry
Network-Close Deployment
Ideally, you should create a container registry in the Azure region where you deploy containers. When you place a registry in a region network-close to container hosts, you can lower latency and costs. A network-close deployment is the main driver for using private container registries.
Docker images include a layering construct that enables incremental deployments, but new nodes must pull all layers required for each image. The initial Docker pull can add up to many gigabytes. Placing a private registry close to the deployment minimizes network latency. Since public clouds, including Azure, implement network egress fees, pulling images from one data center to another can incur network egress fees.
Geo-replicate Multi-Region Deployments
When deploying containers to different regions, you should use geo-replication to minimize latency and simplify the management of registries. You can geo-replicate your registry regardless of the location of your data—in local data centers or several locations. Azure lets you configure regional webhooks, which notify of events in specific replicas.
Maximize Pull Performance
Certain characteristics of container images can impact pull performance, including image size, the number of layers, and the service tier. Here is how you can improve their performance:
Minimize image size
You can remove unnecessary layers and reduce the size of layers to minimize the image size. Here are common techniques:
- A multi-stage Docker build approach—can help ensure you include only necessary runtime components.
- User a lighter base operating system image—helps significantly reduce the size.
- Swap an image layer for a cached image—this works when using a deployment environment like Azure Container Instances, which caches base images.
Number of layers
You should balance the number of used layers to improve pull performance. Too few layers do not allow caching on the host and layer reuse. Too many layers cause the deployment environment to spend more time pulling and decompressing. The optimal number of layers is between five to ten.
Azure service tier
Azure Container Registry provides several service tiers, letting you choose the one that suits your performance needs. The Premium tier offers the most bandwidth and the highest rate of concurrent read-write operations. It is ideal for high-volume deployments.
Dedicated Resource Group
Container registries serve as resources used across several container hosts. To ensure the registry works effectively, you should place it in its own resource group. You can use a specific host type, like Azure Container Instances, and delete as needed. Placing a registry in a resource group helps you minimize the risk of deleting an image collection accidentally from the registry when deleting a container instance resource group.
Addressing Container Registry Security Risks in ACR
Public Registry Images
The risk
Some open source images may contain malicious or insecure commands or components, which can introduce vulnerabilities during deployment. You can mitigate this by using official Docker images or only using open source images from trusted sources. However, these precautions do not prevent errors or zero day vulnerabilities, and the only way to ensure an adequate level of security is to continuously scan images using an automated scanning tool.
Addressing the risk in ACR
If you pull public images from Docker Hub for your build and deployment workflows, you should first authenticate via your Docker Hub account. This is safer than making anonymous pull requests.
Some Azure services, including Azure Container Instances and App Service, allow you to pull images from a public registry like Docker Hub as part of a container deployment. When you need to deploy images from Docker Hub, you should configure the settings to enable authentication via your Docker Hub account.
Internal Security Controls
The risk
To deliver high-quality software products, businesses must ensure that the tools they use internally are secure. As part of this process, companies should audit self-managed repositories, including container registries. Access control to registries is critical, because if a repository is compromised, attackers can introduce malicious code or images, or tamper with existing artifacts.
Addressing the risk in ACR
The Azure Security Baseline (ASB) prescribes recommendations and best practices to help you secure your workloads, services, and data on Azure Container Registry.
The ASB emphasizes cloud-based controls consistent with common, trusted security benchmarks. For example, it supports controls based on the security standards described by the National Institute of Standards and Technology (NIST) and the Center for Internet Security (CIS)—SP 800-53 and Controls Version 7.1, respectively.
Outdated Packages and Libraries
The risk
Images do not change—once built, their content is not modified. This means that over time some libraries, packages and dependencies will become outdated and cause security vulnerabilities or functional issues. This means you cannot trust an image and its dependencies, even if it passed a security scan at some point.
In some cases, you might need to continue using older packages for compatibility reasons or because the cost of replacing them is too high. Vulnerability scanners can help you identify security issues in old packages and suggest in-place remediations, which can help resolve vulnerabilities without having to replace the entire package.
Addressing the risk in ACR
Microsoft Defender for Cloud offers built-in vulnerability scanning for virtual machines, SQL databases, and container images.
You can export the scan results at regular intervals and compare them with early scans to confirm if the vulnerabilities were successfully removed. Microsoft Defender for Cloud suggests recommendations to help you manage vulnerabilities, allowing you to pivot to a portal for each selected solution and view the relevant scan data history.
Microsoft handles vulnerability management for your underlying systems supporting Container Registry.
Mishandling Secrets
Sensitive data such as access credentials, known as secrets, are often stored in plaintext within container images. This creates severe security risks—attackers can compromise the image and use those secrets to gain access to sensitive systems and conduct cyber attacks. To solve this, scan images for secrets and ensure all sensitive information is managed through secret management tools.
Azure Container Registry lets you deploy a resource configuration as an Azure Resource Manager template, which could contain secrets and identities. It is best to implement Credential Scanner to discover credentials in your configurations or code. Credential Scanner encourages you to move the identified credentials to a more secure location, such as Azure Key Vault.
Related content: Read our guide to Azure Kubernetes Service (AKS) security
Container Registry Security with Aqua
Aqua enterprise helps you with the full lifecycle container security, from development to production, using the industry’s most advanced container security solution. Discover sophisticated malware hidden in open source packages and 3rd party images, preventing attacks on your container-based applications, including credential theft, cryptocurrency mining, and data exfiltration.
Aqua will help you to adopt the best security practices in Containers, the policies are based on any combination of vulnerability score or severity, malware severity, the presence of sensitive data, use of root privileges or super-user permissions, and more.
Next steps:
- Learn about Aqua for container security
- Learn about Trivy – Aqua’s open source vulnerability scanner with support for ACR
