Concepts : Mise à jour corrective continue dans Azure Container Registry

La fonctionnalité de mise à jour corrective continue d’Azure Container Registry automatise la détection et la correction des vulnérabilités au niveau du système d’exploitation dans les images conteneur. En planifiant des analyses régulières avec Trivy et en appliquant des correctifs de sécurité à l’aide de Copa, vous pouvez conserver des images sécurisées, up-to-date dans votre Registre, sans avoir à accéder au code source ou aux pipelines de build. Personnaliser librement les images planifiées et cibles pour assurer la sécurité et la conformité de votre environnement Azure Container Registry(ACR)

Cas d’usage

Voici quelques scénarios pour utiliser la mise à jour corrective continue :

• Application de la sécurité et de l’hygiène des conteneurs : La mise à jour corrective continue permet aux utilisateurs de corriger rapidement les CVE des conteneurs OS (vulnérabilités et expositions courantes) sans avoir à reconstruire complètement à partir de la source.
• Vitesse d’utilisation : Le patching continu élimine la dépendance aux mises à jour en amont pour des images spécifiques en mettant à jour automatiquement les paquets. Les vulnérabilités peuvent apparaître tous les jours, tandis que les éditeurs d’images populaires peuvent uniquement proposer une nouvelle version une fois par mois. Avec la mise à jour corrective continue, vous pouvez vous assurer que les images conteneur au sein de votre registre sont corrigées dès que le plus récent ensemble de vulnérabilités du système d’exploitation est détecté.

Tarification

La mise à jour corrective continue fonctionne selon un modèle de consommation. Chaque correctif utilise des ressources de calcul, qui sont facturées par la tarification de la tâche ACR par défaut de 0,0001 $/seconde de tâche en cours d’exécution. Pour plus d’informations, consultez la page de tarification ACR.

Limitations de l'aperçu

La mise à jour corrective continue est actuellement en préversion publique. Les limites suivantes s'appliquent :

• Les images conteneur basées sur Windows ne sont pas prises en charge.
• Seules les vulnérabilités au niveau du système d’exploitation provenant des packages système seront corrigées. Cela inclut les packages système dans l’image conteneur gérée par un gestionnaire de package de système d’exploitation tel que « apt » et « yum ». Les vulnérabilités qui proviennent des packages d’application, tels que les packages utilisés par des langages de programmation tels que Go, Python et NodeJS, ne peuvent pas être corrigés.
• Les images de Fin de vie de service (EOSL) ne sont pas prises en charge par la mise à jour corrective continue. Les images EOSL font référence aux images où le système d’exploitation sous-jacent n’offre plus de mises à jour, de correctifs de sécurité et de support technique. Les exemples incluent des images basées sur des versions antérieures du système d’exploitation telles que Debian 8 et Fedora 28. Les images d’EOSL sont ignorées par le correctif malgré des vulnérabilités. L’approche recommandée consiste à mettre à niveau le système d’exploitation sous-jacent de votre image vers une version prise en charge.
• Les images à plusieurs arches ne sont pas prises en charge.
• Une limite d’image de 100 est appliquée pour la mise à jour corrective continue
• La mise à jour corrective continue n’est pas compatible avec les registres activés par ABAC (Contrôle d’accès basé sur les attributs) et avec les référentiels avec les règles PTC (Pull Through Cache) activées.
• Les abonnements Azure en "essai gratuit" utilisant des crédits gratuits ne sont pas disponibles, car les comptes d'essai gratuit n'ont pas accès aux tâches ACR.

Concepts clés

Étant donné que l'application de correctifs continue dans ACR crée une image par correctif, ACR s’appuie sur une convention de balise pour versionner et identifier les images corrigées. Les deux approches principales sont incrémentielles et flottantes.

Catégorisation incrémentielle

Fonctionnement :

Chaque nouveau correctif incrémente un suffixe numérique (par exemple, -1, , -2etc.) sur la balise d’origine. Par exemple, si l’image de base est python :3.11, le premier correctif crée python:3.11-1et un deuxième correctif sur cette même balise de base crée python:3.11-2.

Règles de suffixe spéciales :

• -1 à -999: ces balises sont considérées comme des balises correctives.
• -x où x > 999: ces balises ne sont pas interprétées comme des balises correctives ; au lieu de cela, le suffixe entier est traité comme faisant partie de la balise d’origine. (Exemple : ubuntu:jammy-20240530 est considéré comme une balise d’origine, et non une balise corrigée.) Cela signifie que si vous envoyez par accident une nouvelle balise se terminant par -1 à -999, le système de mise à jour continue le traitera comme une image déjà corrigée. Nous vous recommandons d’éviter d’envoyer des balises que vous souhaitez corriger avec le suffixe -1 vers -999. Si -999 versions d’une image corrigée sont atteintes, la mise à jour corrective continue renvoie une erreur.

Balisage flottant

Fonctionnement :

Une seule balise mutable, -patched, référencera toujours la dernière version corrigée de votre image. Par exemple, si votre balise d’image de base est python:3.11, le premier correctif crée python:3.11-patched. Avec chaque correctif suivant, la -patched balise est automatiquement mise à jour pour pointer vers la version corrigée la plus récente.

Que dois-je utiliser ?

Incrémentiel (par défaut) : idéal pour les environnements où l’auditabilité et les restaurations sont critiques, car chaque nouveau correctif est clairement identifié avec une balise unique.

Flottant : idéal si vous préférez un pointeur unique vers le dernier correctif pour vos pipelines CI/CD. Réduit la complexité en supprimant la nécessité de mettre à jour les références dans les applications en aval par correctif, mais sacrifie le contrôle de version strict, ce qui rend difficile la restauration.

Étapes suivantes