|
| 1 | +--- |
| 2 | +title: Mitigate data exfiltration with dedicated data endpoints |
| 3 | +description: Azure Container Registry is introducing dedicated data endpoints available to mitigate data-exfiltration concerns. |
| 4 | +ms.topic: article |
| 5 | +author: tejaswikolli-web |
| 6 | +ms.author: tejaswikolli |
| 7 | +ms.date: 12/22/2022 |
| 8 | + |
| 9 | +--- |
| 10 | +# Azure Container Registry mitigating data exfiltration with dedicated data endpoints |
| 11 | + |
| 12 | +Azure Container Registry introduces dedicated data endpoints. The feature enables tightly scoped client firewall rules to specific registries, minimizing data exfiltration concerns. |
| 13 | + |
| 14 | +Dedicated data endpoints feature is available in **Premium** service tier. For pricing information, see [container-registry-pricing.](https://azure.microsoft.com/pricing/details/container-registry/) |
| 15 | + |
| 16 | +Pulling content from a registry involves two endpoints: |
| 17 | + |
| 18 | +*Registry endpoint*, often referred to as the login URL, used for authentication and content discovery. A command like docker pulls `contoso.azurecr.io/hello-world` makes a REST request, which authenticates and negotiates the layers, which represent the requested artifact. |
| 19 | +*Data endpoints* serve blobs representing content layers. |
| 20 | + |
| 21 | + |
| 22 | +:::image type="content" source="./media/dedicated-data-endpoints/endpoints.png" alt-text="Diagram to illustrate endpoints."::: |
| 23 | + |
| 24 | + |
| 25 | +## Registry managed storage accounts |
| 26 | + |
| 27 | +Azure Container Registry is a multi-tenant service. The registry service manages the data endpoint storage accounts. The benefits of the managed storage accounts, include load balancing, contentious content splitting, multiple copies for higher concurrent content delivery, and multi-region support with [geo-replication.](container-registry-geo-replication.md) |
| 28 | + |
| 29 | +## Azure Private Link virtual network support |
| 30 | + |
| 31 | +The [Azure Private Link virtual network support](container-registry-private-link.md) enables the private endpoints for the managed registry service from Azure Virtual Networks. In this case, both the registry and data endpoints are accessible from within the virtual network, using private IPs. |
| 32 | + |
| 33 | +Once the managed registry service and storage accounts are both secured to access from within the virtual network, then the public endpoints are removed. |
| 34 | + |
| 35 | + |
| 36 | +:::image type="content" source="./media/dedicated-data-endpoints/v-net.png" alt-text="Diagram to illustrate virtual network support."::: |
| 37 | + |
| 38 | + |
| 39 | +Unfortunately, virtual network connection isn’t always an option. |
| 40 | + |
| 41 | +> [!IMPORTANT] |
| 42 | +>[Azure Private Link](container-registry-private-link.md) is the most secure way to control network access between clients and the registry as network traffic is limited to the Azure Virtual Network, using private IPs. When Private Link isn’t an option, dedicated data endpoints can provide secure knowledge in what resources are accessible from each client. |
| 43 | +
|
| 44 | +## Client firewall rules and data exfiltration risks |
| 45 | + |
| 46 | +Client firewall rules limits access to specific resources. The firewall rules apply while connecting to a registry from on-premises hosts, IoT devices, custom build agents. The rules also apply when the Private Link support isn't an option. |
| 47 | + |
| 48 | + |
| 49 | +:::image type="content" source="./media/dedicated-data-endpoints/client-firewall-0.png" alt-text="Diagram to illustrate client firewall rules."::: |
| 50 | + |
| 51 | + |
| 52 | +As customers locked down their client firewall configurations, they realized they must create a rule with a wildcard for all storage accounts, raising concerns for data-exfiltration. A bad actor could deploy code that would be capable of writing to their storage account. |
| 53 | + |
| 54 | + |
| 55 | +:::image type="content" source="./media/dedicated-data-endpoints/client-firewall-2.png" alt-text="Diagram to illustrate client data exfiltration risks."::: |
| 56 | + |
| 57 | + |
| 58 | +So, to address the data-exfiltration concerns, Azure Container Registry is making dedicated data endpoints available. |
| 59 | + |
| 60 | +## Dedicated data endpoints |
| 61 | + |
| 62 | +Dedicated data endpoints, help retrieve layers from the Azure Container Registry service, with fully qualified domain names representing the registry domain. |
| 63 | + |
| 64 | +As any registry may become geo-replicated, a regional pattern is used: `[registry].[region].data.azurecr.io`. |
| 65 | + |
| 66 | +For the Contoso example, multiple regional data endpoints are added supporting the local region with a nearby replica. |
| 67 | + |
| 68 | +With dedicated data endpoints, the bad actor is blocked from writing to other storage accounts. |
| 69 | + |
| 70 | + |
| 71 | +:::image type="content" source="./media/dedicated-data-endpoints/contoso-example-0.png" alt-text="Diagram to illustrate contoso example with dedicated data endpoints."::: |
| 72 | + |
| 73 | + |
| 74 | +## Enabling dedicated data endpoints |
| 75 | + |
| 76 | +> [!NOTE] |
| 77 | +> Switching to dedicated data-endpoints will impact clients that have configured firewall access to the existing `*.blob.core.windows.net` endpoints, causing pull failures. To assure clients have consistent access, add the new data-endpoints to the client firewall rules. Once completed, existing registries can enable dedicated data-endpoints through the `az cli`. |
| 78 | +
|
| 79 | +To use the Azure CLI steps in this article, Azure CLI version 2.4.0 or later is required. If you need to install or upgrade, see [Install Azure CLI](/cli/azure/install-azure-cli) or run in [Azure Cloud Shell](../cloud-shell/quickstart.md). |
| 80 | + |
| 81 | +* Run the [az acr update](/cli/azure/acr#az-acr-update) command to enable dedicated data endpoint. |
| 82 | + |
| 83 | +```azurecli-interactive |
| 84 | +az acr update --name contoso --data-endpoint-enabled |
| 85 | +``` |
| 86 | + |
| 87 | +* Run the [az acr show](/cli/azure/acr#az-acr-show-endpoints) command to view the data endpoints, including regional endpoints for geo-replicated registries. |
| 88 | + |
| 89 | +```azurecli-interactive |
| 90 | +az acr show-endpoints --name contoso |
| 91 | +``` |
| 92 | + |
| 93 | +Sample output: |
| 94 | + |
| 95 | +```json |
| 96 | +{ |
| 97 | + "loginServer": "contoso.azurecr.io", |
| 98 | + "dataEndpoints": [ |
| 99 | + { |
| 100 | + "region": "eastus", |
| 101 | + "endpoint": "contoso.eastus.data.azurecr.io", |
| 102 | + }, |
| 103 | + { |
| 104 | + "region": "westus", |
| 105 | + "endpoint": "contoso.westus.data.azurecr.io", |
| 106 | + } |
| 107 | + ] |
| 108 | +} |
| 109 | + |
| 110 | +``` |
| 111 | + |
| 112 | +## Next steps |
| 113 | + |
| 114 | +* Configure to access an Azure container registry from behind a [firewall rules.](container-registry-firewall-access-rules.md) |
| 115 | +* Connect Azure Container Registry using [Azure Private Link](container-registry-private-link.md) |
0 commit comments