Conceitos: Aplicação contínua de patches no Registro de Contêiner do Azure

O recurso de Patch Contínuo do Registro de Contêiner do Azure automatiza a deteção e a correção de vulnerabilidades no nível do sistema operacional (SO) em imagens de contêiner. Ao agendar verificações regulares com o Trivy e aplicar correções de segurança usando o Copa, você pode manter imagens seguras e up-toem seu registro, sem exigir acesso ao código-fonte ou pipelines de compilação. Personalize livremente a agenda e as imagens de destino para manter seu ambiente do Azure Container Registry (ACR) seguro e compatível

Casos de uso

Aqui estão alguns cenários para usar o patch contínuo:

• Reforçar a segurança e higiene dos contentores: A aplicação contínua de patches permite que os usuários corrijam rapidamente CVEs (vulnerabilidades e exposições comuns) do contêiner do sistema operacional sem a necessidade de reconstruir totalmente a partir do upstream.
• Velocidade de Utilização: O patch contínuo remove a dependência de atualizações upstream para imagens específicas, atualizando pacotes automaticamente. Vulnerabilidades podem aparecer todos os dias, enquanto editores de imagens populares podem oferecer apenas uma nova versão uma vez por mês. Com a aplicação contínua de patches, você pode garantir que as imagens de contêiner dentro do seu registro sejam corrigidas assim que o mais novo conjunto de vulnerabilidades do sistema operacional for detetado.

Preços

Continuous Patching opera com base num modelo de consumo. Cada patch utiliza recursos de computação, que são cobrados de acordo com o preço padrão da Tarefa ACR de 0,0001 USD/segundo de execução da tarefa. Mais informações na página de preços do ACR.

Limitações da pré-visualização

O Patch Contínuo está atualmente em prévia pública. Aplicam-se as seguintes limitações:

• Não há suporte para imagens de contêiner baseadas no Windows.
• Apenas as vulnerabilidades de "nível OS" originadas de pacotes do sistema serão corrigidas. Isso inclui pacotes de sistema na imagem de contêiner gerenciada por um gerenciador de pacotes do sistema operacional, como "apt" e "yum". As vulnerabilidades originadas de pacotes de aplicativos, como pacotes usados por linguagens de programação como Go, Python e NodeJS, não podem ser corrigidas.
• As imagens EOSL (End of Service Life) não são suportadas pelo patch contínuo. As imagens EOSL referem-se a imagens em que o sistema operacional subjacente não oferece mais atualizações, patches de segurança e suporte técnico. Exemplos incluem imagens baseadas em versões mais antigas do sistema operacional, como Debian 8 e Fedora 28. As imagens EOSL são excluídas do processo de correção apesar de terem vulnerabilidades - a abordagem recomendada é atualizar o sistema operativo da sua imagem para uma versão suportada.
• Não há suporte para imagens com vários arcos.
• Um limite de 100 imagens é imposto para aplicação contínua de patches
• O Patch Contínuo é incompatível com registros habilitados para ABAC (Attribute Based Access Control) e com repositórios com regras PTC (Pull Through Cache) habilitadas.
• As Subscrições do Azure na "Avaliação Gratuita" que utilizam créditos gratuitos não são suportadas, uma vez que as contas de avaliação gratuita não têm acesso à Tarefa ACR.

Conceitos-chave

Como a aplicação contínua de patches no ACR cria uma nova imagem por patch, o ACR depende de uma convenção de tag para a versão e a identificação de imagens corrigidas. As duas abordagens principais são incrementais e flutuantes.

Marcação incremental

Como funciona:

Cada novo patch incrementa um sufixo numérico (por exemplo, -1, , -2etc.) na tag original. Por exemplo, se a imagem base for python:3.11, o primeiro patch criará python:3.11-1, e um segundo patch na mesma tag de imagem base criará python:3.11-2.

Regras especiais de sufixo:

• -1 to -999: Estas são consideradas tags de patch.
• -x onde x > 999: Estes não são interpretados como tags de patch, em vez disso, esse sufixo inteiro é tratado como parte da tag original. (Exemplo: ubuntu:jammy-20240530 é considerada uma tag original, não corrigida.) Isso significa que, se você empurrar uma nova tag terminando em -1 para -999 por acidente, Patching Contínuo a tratará como uma imagem corrigida. Recomendamos que você evite enviar tags que deseja corrigir com o sufixo -1 para -999. Se -999 as versões de uma imagem corrigida forem atingidas, o Patch Contínuo retornará um erro.

Marcação flutuante

Como funciona:

Uma única tag mutável, -patched, sempre fará referência à versão corrigida mais recente da sua imagem. Por exemplo, se a tag da imagem base for python:3.11, o primeiro patch criará python:3.11-patched. Com cada patch subsequente, a -patched tag será atualizada automaticamente para apontar para a versão corrigida mais recente.

Qual devo usar?

Incremental (padrão): Ótimo para ambientes onde a auditabilidade e as reversões são críticas, já que cada novo patch é claramente identificado com uma tag exclusiva.

Flutuante: Ideal se você preferir um único ponteiro para o patch mais recente para seus pipelines de CI/CD. Reduz a complexidade ao remover a necessidade de atualizar referências em aplicativos downstream por patch, mas sacrifica o controle de versão rigoroso, dificultando a reversão.

Próximas Etapas

Configurar aplicação contínua de patches