As part of the continual quest to secure container environments, we’ve received a number of questions about how ACR can be secured.

Using firewall rules, you can lock down specific secured domains, [registry].azurecr.io. You can even use specific published IPs to lock down access. However, the registry url/ip is just part of the interactions needed to manage access as a registry is hosted as a REST endpoint with storage urls being returned representing the container layers.

Overview of a Container Registry:

A docker host is actually a client/server configuration. When docker pull contoso.azurecr.io/widget/webapi is executed, the request is sent to the associated docker daemon. When running docker for windows/mac, the client is installed on the developers machine, and a VM is run to host the docker daemon. It’s the docker daemon that makes the actual requests.

If running kubernetes, using kubectl, the cli is communicating with the k8 cluster, which makes requests of each node to pull the specified image. In each case, it’s a docker daemon with it’s own IP that’s making the requests.

As the docker daemon makes requests of a registry, there are two very distinct endpoints to understand:

1. Registry REST API – handles auth validation and manifest negotiations to determine what, if any image layers must be returned. As an image is requested, a manifest representing the layer ids are returned. The daemon examines it’s local cache to determine what layers it has, and determines the delta required. This includes newer layers for an updated tag.
   The daemon then requests storage urls for the missing layers, which are returned with sas encoded fully qualified storage urls.
2. Storage Endpoint– as the daemon determines the missing layers, it makes direct requests of storage. The daemon can make multiple concurrent requests.

Auth validations are handled through the ACR REST endpoint. All layers are routed with time based SAS URLs.

With this understanding, there are actually two sets of endpoints that must be enabled.

Geo-replicated Registries

Azure Container Registry provides geo-replication, a powerful, productive and secure feature enabling a single URL that provides the closest enabled region to your users. As users may roam between locations, they will automatically be routed to the closest replicated region. For example, as you fly to visit different customers, or perhaps a car that uses containers for it’s app – yeah, that’s really happening.

To configure geo-replicated registries, you may want to enable all regions, or the specific replicated regions. Be sure to enable both the storage and REST endpoints for each configured region to avoid mysterious errors. 

Securing the ACR REST endpoint

If you can configure your firewall rules to use the registry url [registry].azurecr.io, you’ll account for the REST endpoint.

Securing the Storage URLs

The storage URLs are a little more challenging as ACR manages the storage on behalf of the each registry. This allows ACR to automatically scale the registry for more concurrent throughput using the Premium tier, enable CDN or configure a VNet.

To configure firewall rules for ACR Storage by DNS, use the following: *.blob.core.windows.net

Securing by IP Range

If specific IPs are required, download the IP ranges: Azure IP Ranges and Service Tags – Public Cloud

To find the ACR REST Endpoint IP ranges, search for “AzureContainerRegistry“.

ACR REST IPs for All Regions:

{
  "name": "AzureContainerRegistry",
  "id": "AzureContainerRegistry",
  "properties": {
    "changeNumber": 3,
    "region": "",
    "platform": "Azure",
    "systemService": "AzureContainerRegistry",
    "addressPrefixes": [
      "13.66.140.72/29",
      ...

ACR REST IPs for Specific Regions

Search for the specific region:

{
  "name": "AzureContainerRegistry.AustraliaEast",
  "id": "AzureContainerRegistry.AustraliaEast",
  "properties": {
    "changeNumber": 1,
    "region": "australiaeast",
    "platform": "Azure",
    "systemService": "AzureContainerRegistry",
    "addressPrefixes": [
      "13.70.72.136/29",
      ...

ACR Storage IPs for All Regions:

{
  "name": "Storage",
  "id": "Storage",
  "properties": {
    "changeNumber": 13,
    "region": "",
    "platform": "Azure",
    "systemService": "AzureStorage",
    "addressPrefixes": [
      "13.65.107.32/28",
      ...

ACR Storage IPs for Specific Regions

Search for the specific region:

{
  "name": "Storage.AustraliaCentral",
  "id": "Storage.AustraliaCentral",
  "properties": {
    "changeNumber": 1,
    "region": "australiacentral",
    "platform": "Azure",
    "systemService": "AzureStorage",
    "addressPrefixes": [
      "52.239.216.0/23"
      ...

Microsoft Container Registry

All Microsoft official software is discoverable on Docker Hub, however images are served from the Microsoft Container Registry.

See this blog post for more info on the Microsoft Container Registry.

ACR REST IPs

Search MicrosoftContainerRegistry 

{
  "name": "MicrosoftContainerRegistry",
  "id": "MicrosoftContainerRegistry",
  "properties": {
    "changeNumber": 3,
    "region": "",
    "platform": "Azure",
    "systemService": "MicrosoftContainerRegistry",
    "addressPrefixes": [
      "13.66.140.64/29",
      ...

Microsoft Container Registry Storage

MCR storage is backed by Azure CDN.

Filter by: *.cdn.mscr.io

With this information, we hope you’ll have what you need to limit access to just the nodes you require.

Steve