sécurité des conteneurs difficile — Aikido AutoFix pour la faciliter

sécurité des conteneurs par votre image de base.
Mais voici le hic :

• La simple mise à niveau vers la version « la plus récente » d'une image de base peut compromettre le fonctionnement de votre application.
• Vous êtes contraint de choisir entre livrer des vulnérabilités connues ou passer des jours à corriger des problèmes de compatibilité.
• Et souvent... vous n'êtes même pas sûr qu'une mise à niveau en vaille la peine.

Dans cet article, nous explorerons pourquoi la mise à jour des images de base est plus complexe qu'il n'y paraît, nous examinerons des exemples concrets et nous montrerons comment automatiser des mises à niveau sûres et intelligentes sans compromettre votre application.

Le Problème : « Mettez simplement à jour votre image de base » — Plus facile à dire qu'à faire

Si vous lisez ceci, vous avez probablement cherché sur Google quelque chose comme « Comment sécuriser vos conteneurs » et le premier point de chaque article bâclé généré par IA que vous avez lu est le suivant : mettez à jour votre image de base. Simple, n'est-ce pas ? Eh bien, pas si vite. 

Votre image de base est votre point central de sécurité ; si elle contient des vulnérabilités, votre application les transporte avec elle. Déroulons ce scénario. 

Vous lancez un scan sur votre image de conteneur et une CVE de haute gravité est détectée. La recommandation utile est de mettre à jour l'image de base, fantastique, vous aurez terminé avant le déjeuner. 

⚠️ CVE-2023-37920 détectée dans ubuntu:20.04
Gravité : Élevée
Corrigée dans : 22.04
Recommandation : Mettre à jour l'image de base

…mais vous découvrez un problème. 

En effectuant une mise à niveau aveugle depuis ubuntu:20.04 à ubuntu:22.04, votre application s'effondre.

Examinons quelques exemples de mise à jour d'une image de base et ce qui se passe en réalité. 

Exemple 1 : Un Dockerfile qui ne fonctionne plus après une mise à niveau

Dockerfile initial :

FROM python:3.8-buster‍
RUN apt-get update && apt-get install -y libpq-dev
RUN pip install psycopg2==2.8.6 flask==1.1.2
COPY . /appCMD ["python", "app.py"]

L'équipe passe à :

FROM python:3.11-bookworm‍
RUN apt-get update && apt-get install -y libpq-dev
RUN pip install psycopg2==2.8.6 flask==1.1.2COPY . /appCMD ["python", "app.py"]

Résultat :

• psycopg2==2.8.6 ne parvient pas à compiler avec des versions plus récentes libpq en-têtes activés lecteur assidu.
• flask==1.1.2 ne prend pas en charge Python 3.11 fonctionnalités d'exécution (les API dépréciées causent des ruptures).
• Le build échoue en CI.
• Votre équipe de développement est furieuse et votre déjeuner est gâché. 

Exemple 2 : Mises à niveau d'images de base introduisant des bugs subtils au runtime

Original :

FROM node:14-busterCOPY . /app
RUN npm ci
CMD ["node", "server.js"]

Mettre à niveau vers :

FROM node:20-bullseye
COPY . /app
RUN npm ci
CMD ["node", "server.js"]

Problème d'exécution :

• node:20 utilise des versions plus récentes OpenSSL versions — la vérification TLS stricte rompt les configurations axios plus anciennes.
• L'application lève une erreur UNABLE_TO_VERIFY_LEAF_SIGNATURE erreurs en runtime HTTP appels aux services hérités.

Pourquoi « latest » est un piège

L'écosystème Docker encourage l'utilisation des tags `latest` ou des versions de pointe. Mais cela signifie souvent que votre application qui fonctionnait lundi tombe en panne subitement mardi. C'est souvent un piège qui entraînera des maux de tête, des pannes et un ralentissement du développement, car vous passerez du temps à corriger des bugs. 

La solution est donc évidemment de se fixer à une version mineure que vous avez testée… Pas si vite, car vous êtes maintenant entré dans le jeu du « whack-a-mole » de la sécurité où vous découvrirez sans cesse de nouvelles CVE qui pourraient vous laisser vulnérable. 

Paralysie décisionnelle : Faut-il mettre à niveau ou non ?

Les équipes de sécurité insistent pour des mises à niveau.
Les développeurs s'y opposent en raison de la stabilité.

Qui a raison ? Cela dépend.

MAIS, pour même comprendre la décision, vous devez examiner toutes les options, ce qui signifie créer une feuille de calcul massive de toutes les versions, des risques de sécurité, des risques de stabilité et de la disponibilité. 

Voyons à quoi cela pourrait ressembler. 

Cela vous laisse face à des choix complexes, médiocres et impossibles. 

1. Restez sur l'ancienne image et acceptez les vulnérabilités
2. Mettre à niveau et casser votre application, au risque d'une interruption de production
3. Tentative de test de compatibilité manuel — des jours de travail

Le flux de travail de mise à niveau manuelle :

Si vous faites cela manuellement, voici à quoi cela ressemble :

• Vérifier les CVE : trivy python:3.8-buster
• Rechercher chaque CVE : Est-elle atteignable dans le contexte de votre application ?
• Décider du candidat à la mise à niveau 
• Tester la nouvelle image :
  
  • Build
  • Exécutez des tests unitaires
  • Exécutez des tests d'intégration
• En cas d'échec, essayez de corriger le code ou de mettre à jour les bibliothèques.
• À répéter pour chaque conteneur.

C'est épuisant.

Le coût de l'immobilisme

Vous pourriez penser : « Si ça marche, ne le changez pas. »

Mais les CVEs de conteneurs non corrigées contribuent massivement aux failles de sécurité : « 87 % des images de conteneurs exécutées en production présentaient au moins une vulnérabilité critique ou de gravité élevée. » source 

Il existe également de nombreux exploits connus dans les images de base populaires. 

• Vulnérabilité de Path Traversal (décompression) (CVE-2020-27350) — est resté dans des millions de conteneurs pendant des années.
• Heartbleed (CVE-2014-0160) sont restées dans des conteneurs legacy longtemps après les correctifs officiels.
• PHP-FPM RCE (CVE-2019-11043) permettent à des attaquants distants d'exécuter du code arbitraire via des requêtes HTTP spécialement conçues et était extrêmement courant dans les images de base de conteneurs avec PHP-FPM préinstallé avant d'être patché

Comment notre fonctionnalité Auto-Fix contribue

Pour résoudre ce problème précis, Aikido a déployé notre fonctionnalité de correction automatique des conteneurs, car nous sommes également confrontés à cette difficulté. 

La fonctionnalité fonctionne ainsi : Aikido vos conteneurs à la recherche de vulnérabilités. Si (ou plutôt quand) nous trouvons des vulnérabilités, comme toujours, nous vous alertons, puis, au lieu de vous demander de mettre à jour votre image de base, nous vous proposons différentes options. Nous créons un tableau qui vous indique quelle version de l'image de base permettra de résoudre quelles CVE. Vous pouvez ainsi voir très rapidement qu'une mise à jour mineure peut supprimer toutes ou la plupart des CVE élevées, ce qui signifie qu'il s'agit d'une mise à niveau adéquate de l'image de base. 

Si la mise à niveau est mineure, vous pouvez créer automatiquement une pull request pour augmenter la version. 

Cela représente des heures de travail économisées.

Conclusion :

• La mise à niveau des images de base de conteneurs est vraiment difficile.
• Le conseil de « simplement mettre à niveau » simplifie à l'excès un processus complexe et risqué.
• Vos équipes ont raison d'être prudentes — mais elles ne devraient pas avoir à choisir entre sécurité et stabilité.
• La correction automatique des conteneurs Aikidofait le travail à votre place afin que vous puissiez prendre une décision éclairée. 
• Ainsi, la prochaine fois que vous verrez une alerte de vulnérabilité d'image de base, vous ne paniquerez pas. Vous recevrez une PR.