O que muda com o suporte a ACR como fonte de cache?
O recurso de artifact cache do Azure Container Registry (ACR) sempre foi uma ferramenta eficiente para mitigar dependências diretas de registros públicos (como Docker Hub ou GitHub Container Registry). A grande novidade agora é a capacidade de utilizar instâncias do próprio ACR como upstream source, permitindo uma integração nativa e muito mais segura.
Como funciona o fluxo de artifact cache
O artifact cache funciona como um pull-through proxy. A lógica é simples para a operação:
- O cliente solicita uma imagem do registro local (ex:
docker pull meu-registro.azurecr.io/api:1.0). - O ACR verifica o cache local; caso não encontre, ele busca a imagem no upstream configurado.
- O ACR realiza o proxy do conteúdo e, simultaneamente, executa uma cópia assíncrona para o armazenamento local.
- O próximo pull já será servido diretamente de baixa latência pelo seu registro regional.
Cenários práticos para empresas brasileiras
Essa atualização é um divisor de águas para times de engenharia que mantêm arquiteturas complexas na cloud:
- Segurança e conformidade (Quarentena): É possível isolar ambientes. Imagens podem ser puxadas de um registro de 'Dev', scanneadas e promovidas para um registro de 'Prod' de forma automatizada, garantindo que apenas artefatos validados atinjam a produção.
- Arquiteturas hierárquicas: Ideal para empresas com múltiplas unidades de negócio ou grandes clusters de Kubernetes espalhados. Você pode distribuir 'golden images' do seu registro central (Hub) para registros regionais/específicos (Spoke), reduzindo o tráfego de rede e o latency.
- Fim do credential sprawl: Com o suporte às UAMI (User-assigned Managed Identities), eliminamos a fragilidade de gerenciar secrets em Key Vaults para cada regra de cache, delegando essa responsabilidade ao controle de acesso do Azure (IAM).
Matriz de suporte e autenticação
É importante manter a atenção ao planejar a implementação:
| Networking on Source ACR | Same Tenant | Cross Tenant |
|---|---|---|
| Pública (All networks) | Creds, SP, Token, UAMI | Creds, SP, Token |
| Pública (Selected) | Creds, SP, Token, UAMI (+ Trusted Services) | Creds, SP, Token (+ Trusted Services + CIDR) |
| Private VNet (Private Link) | Creds, SP, Token, UAMI (+ Trusted Services) | Não suportado |
Design note: Diferente dos credential sets, aqui a identidade é vinculada diretamente à regra de cache. Isso evita abusos, onde um token com permissão excessiva poderia ser reutilizado indevidamente em outros contextos da sua infraestrutura.
Considerações sobre implementação e limitações
Atualmente, a gestão é feita principalmente via Azure CLI (az acr cache create com o novo parâmetro --identity). Embora a interface via portal esteja prevista para breve, é fundamental que o time de DevOps alinhe as permissões RBAC no nível do registro de origem (Container Registry Repository Reader).
O que você precisa ter no radar:
- Delete propagation: A exclusão de uma imagem no registro de origem NÃO causa a exclusão automática no cache de destino.
- Configuração: O Azure não automatiza as atribuições de papéis nas regras de RBAC; isso deve ser parte do seu pipeline de infraestrutura (Terraform/Bicep).
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
