Comment sécurisez-vous les images de conteneurs ?
Réponse courte
Partez d'une image de base minimale et de confiance (distroless ou slim) pour réduire la surface d'attaque, analysez les images à la recherche de CVE connues dans la CI et dans le registre, épinglez et vérifiez les empreintes (digests) des images, exécutez avec un utilisateur non-root et évitez d'intégrer des secrets. Signez les images et imposez des politiques d'admission pour que seules les images analysées et signées s'exécutent. Reconstruisez régulièrement pour que les couches de base corrigées se propagent.
Les conteneurs paraissent jetables, alors les équipes sous-investissent dans la sécurité des images — mais une image vulnérable ou empoisonnée s'exécute partout où elle est déployée. L'entretien attend une approche en couches, pas une seule astuce.
Construire une image petite et propre
- Images de base minimales. Une base
distrolessou slim retire les shells, les gestionnaires de paquets et les bibliothèques inutilisées. Moins de paquets signifie moins de surface d'attaque et bien moins de bruit d'analyse — la plupart des CVE proviennent de paquets OS que vous n'utilisez jamais. - Pas de secrets dans les couches. Tout ce qui est
COPY'é ou défini comme argument de build persiste dans l'historique des couches même s'il est retiré ensuite ; récupérez plutôt les secrets à l'exécution. - Exécuter en non-root. Définissez un
USERpour qu'une évasion de conteneur ne démarre pas avec des droits équivalents à root, et combinez cela avec des systèmes de fichiers en lecture seule et des capacités supprimées.
Vérifier et contrôler
- Analyser dans la CI et dans le registre. Des outils comme Trivy ou Grype détectent les CVE connues dans les paquets OS et les dépendances de langage. Faites échouer le build sur les découvertes critiques, et ré-analysez dans le registre car de nouvelles CVE sont divulguées après le build.
- Épingler par empreinte, pas par tag flottant.
:latestest non déterministe ; un épinglage par empreinte garantit que vous exécutez exactement ce que vous avez analysé. - Signer et imposer. Signez les images (Sigstore/cosign) et utilisez le contrôle d'admission (par ex. une politique OPA/Kyverno ou une vérification de signature) pour que le cluster n'exécute que des images analysées et signées.
La maintenir à jour
Une CVE corrigée dans l'image de base n'aide que si vous reconstruisez et redéployez. Automatisez des reconstructions périodiques pour que les correctifs amont se propagent dans les charges de travail en cours d'exécution.
Ce que recherchent les recruteurs
Citer en premier les images de base minimales et l'analyse, puis le non-root, la signature plus le contrôle d'admission, et le point opérationnel selon lequel les images doivent être reconstruites pour hériter des correctifs.
Questions de suivi probables
- Pourquoi une image de base plus petite réduit-elle à la fois la surface d'attaque et le bruit d'analyse ?
- Qu'est-ce que la signature d'image (par ex. Sigstore/cosign) et comment le contrôle d'admission l'utilise-t-il ?
- Comment vous assurez-vous qu'un correctif de CVE d'image de base atteint réellement les charges de travail en cours d'exécution ?