{"id":590,"date":"2020-06-23T00:00:00","date_gmt":"2020-06-23T00:00:00","guid":{"rendered":""},"modified":"2025-06-30T03:57:02","modified_gmt":"2025-06-30T10:57:02","slug":"azure-container-registry-securing-container-workflows","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/azure-container-registry-securing-container-workflows\/","title":{"rendered":"Azure Container Registry: Securing container workflows"},"content":{"rendered":"\n

Securing any environment requires multiple lines of defense. Azure Container Registry recently announced the general availability of features like Azure Private Link<\/a>, customer-managed keys<\/a>, dedicated data-endpoints<\/a>, and Azure Policy definitions<\/a>. These features provide tools to secure Azure Container Registry as part of the container end-to-end workflow.<\/p>\n\n\n\n

Customer-managed keys<\/h2>\n\n\n\n

By default, when you store images and other artifacts in an Azure Container Registry, content is automatically encrypted at rest with Microsoft-managed keys.<\/p>\n\n\n\n

Choosing Microsoft-managed keys means that Microsoft oversees managing the key\u2019s lifecycle. Many organizations have stricter compliance needs, requiring ownership and management of the key\u2019s lifecycle and access policies. In such cases, customers can choose customer-managed keys that are created and maintained in a customer\u2019s Azure Key Vault<\/a> instance. Since the keys are stored in Key Vault, customers can also closely monitor the access of these keys using the built-in diagnostics and audit logging capabilities<\/a>  in Key Vault. Customer-managed keys supplement the default encryption capability with an additional encryption layer using keys provided by customers. See details on how you can create a registry enabled for customer-managed keys<\/a>.<\/p>\n\n\n\n

Private links<\/h2>\n\n\n\n

Container Registry previously had the ability to restrict access using firewall rules<\/a>. With the introduction of Private Link<\/a>, the registry endpoints are assigned private IP addresses, routing traffic within your virtual network and the service through a Microsoft backbone network.<\/p>\n\n\n\n

Private Link support has been one of the top asks, allowing customers to benefit from the Azure management of their registry while benefiting from tightly controlled network ingress and egress.<\/p>\n\n\n\n

Private links are available across a wide range of Azure resources with more coming soon, allowing a wide range of container workloads with the security of a private virtual network. See documentation on how to configure Azure Private Link for Container Registry<\/a>.<\/p>\n\n\n\n

\"Architecture<\/figure>\n\n\n\n

Dedicated data-endpoints<\/h2>\n\n\n\n

Private Link<\/a> is the most secure way to control network access between clients and the registry as network traffic is limited to the Azure Virtual Network. When Private Link can’t be used, dedicated data-endpoints<\/a> can minimize data exfiltration concerns. Enabling dedicated data endpoints means they can configure firewall rules with fully qualified domain names ([registry].[region].data.azurecr.io<\/code>) rather than a rule with wildcard (*.blob.core.windows.net<\/code>) for all storage accounts.<\/p>\n\n\n\n

You can enable dedicated data-endpoints using the Azure portal or the Microsoft Azure CLI. The data endpoints follow a regional pattern, ..data.azurecr.io.<\/code> In a geo-replicated registry, enabling data endpoints allows endpoints in all replica regions. Review the documentation on how to enable dedicated data endpoints<\/a> to learn more.<\/p>\n\n\n\n

Azure built-in policies<\/h2>\n\n\n\n

Having security capabilities will secure your workflows if they\u2019re implemented. To assure your Azure resources are following the best security practices, Azure Container Registry has added built-in Azure Policy definitions<\/a> that you can leverage to enforce security rules. Here are some of the built-in policies that you can enable for your container registry:<\/p>\n\n\n\n