Intégrer la sécurité aux 3 phases de déploiement de conteneurs

Entretien avec Hari Srinivasan, Director, Product management, Cloud and Virtualization Security, Qualys Ces dernières années, l'adoption des conteneurs a explosé, de même que la préoccupation visant à sécuriser les applications créées et déployées par les équipes DevOps à l'aide de conteneurs. La protection fournie par les équipes chargées de la sécurité doit s'appliquer à l'ensemble du cycle de vie du conteneur et s'intégrer au pipeline DevOps de manière transparente et non invasive. Pour ce faire, il est nécessaire de comprendre la technologie des conteneurs Docker et d'adopter des processus et des outils dédiés à ces environnements.

- contenu BFM partenaire -

Défis liés à la sécurité des conteneurs

Les conteneurs sont à l’origine de problèmes de sécurité et de conformité spécifiques dont beaucoup sont liés à des critères jugés attractifs par les développeurs, notamment le lancement d'une application et de ses dépendances sans OS invité. Parmi ces défis citons l'utilisation de logiciels non validés issus de référentiels publics souvent truffés de vulnérabilités non corrigées ainsi que le déploiement de conteneurs ayant une configuration médiocre.

En outre, les conteneurs communiquent directement entre eux via des ports réseau exposés qui permettent de contourner les contrôles opérés par l'hôte et qui sont difficiles à suivre tellement ils sont éphémères.

Objectifs de la sécurité des conteneurs

Les équipes de sécurité doivent poursuivre quatre objectifs majeurs pour sécuriser les conteneurs, à commencer par avoir de la visibilité sur leur environnement de conteneurs en découvrant et en suivant tous les déploiements aussi bien sur site que dans les clouds.

Ensuite, ils doivent à la fois gérer les vulnérabilités au sein des conteneurs et prévenir et détecter les intrusions. Le troisième objectif consiste à exploiter les API REST pour intégrer des outils de sécurité des conteneurs au sein des produits DevOps.

En quatrième et dernier lieu, le programme de sécurité des conteneurs doit repenser la réaction aux incidents (IR), plus particulièrement si des conteneurs vulnérables ne sont pas patchés mais plutôt remplacés par des nouveaux à partir d'une image mise à jour.

Les équipes doivent donc adapter leur programme IR pour collecter des informations sur le nouvel environnement d'exploitation des conteneurs, notamment la plateforme d'orchestration et envisager le modèle de remplacement complet comme un élément IR.

Protection du pipeline de conteneurs

Les trois premières phases de déploiement d'un conteneur, à savoir Build (création d’un environnement de développement d’applications), Ship (mise à disposition, stockage et sécurisation des images de conteneurs) et Runtime (création d’un environnement de production), doivent être sécurisées, chacune ayant des exigences spécifiques. Examinons maintenant chaque phase de plus près.

Build

Au cours de cette première phase, l’objectif premier en termes de sécurité est d'empêcher les images vulnérables de pénétrer dans les référentiels de votre entreprise. Ceci revêt une importance toute particulière pour les images qui ne sont pas créées ex nihilo mais qui proviennent en partie ou totalement d'un référentiel public, une pratique souvent adoptée par les développeurs de conteneurs.

Pour tenir ces images dangereuses loin des référentiels Docker, il est important de s'appuyer sur des API REST ou sur des plug-ins natifs que les contrôles de sécurité peuvent exécuter automatiquement à l'aide des outils à intégration continue (CI) et à développement continu (CD) préférés de votre équipe DevOps. Il devrait également être possible de déterminer des paramètres pour bloquer les images, notamment celles hébergeant des vulnérabilités ayant un niveau de gravité 3, 4 ou 5, celles qui n'adhérent pas aux normes de conformité ou qui utilisent ouvertement des secrets.

Ces intégrations permettront aussi à l'équipe en charge de la sécurité d'autoriser les développeurs à accéder aux outils de sécurité. Ces derniers pourront ainsi lancer de manière proactive certaines fonctions de sécurité directement depuis leur outil CI/CD, sans devoir se reposer sur ni attendre l'équipe de sécurité. Les développeurs pourront par exemple consulter les données de résultats des scans et lancer des actions de remédiation depuis l'interface de leur outil CI/CD.

Ship

Au cours de cette phase, il est indispensable de vérifier les vulnérabilités au sein des images déjà présentes dans vos référentiels. Il doit être procédé à un inventaire des registres et des référentiels et à une recherche de vulnérabilités dans les images ajoutées. Pensez aussi à programmer des scans quotidiens et automatisés qui rechercheront les nouvelles vulnérabilités et vérifieront les nouvelles images ajoutées chaque jour aux référentiels.

Assurez-vous également que les images stockées dans votre entreprise proviennent bien de sources de confiance et qui ont bonne réputation et aussi que les images sont bien mises à jour et débarrassées de toute vulnérabilité divulguée. Utilisez des services de notaire comme celui de Docker ou un service similaire pour signer les images et veillez à n'utiliser que des images de confiance dans votre environnement.

Runtime

Une fois que les images de conteneur sont dans votre registre et utilisables en mode production, il est indispensable d'avoir de la visibilité sur les environnements runtime et de pouvoir les superviser en continu et aussi d’être en mesure de prévenir les failles et de les remédier.

Il incombe aux équipes de sécurité de détecter les conteneurs non conformes ou vulnérables, de les localiser et d'évaluer leur impact éventuel selon l'ampleur de leur présence dans votre environnement.

Il est donc essentiel de repérer les conteneurs déjà exécutés sur le système et qui violent le comportement « immuable » de leur image parente, ce qui pourrait révéler une faille.

Comme les conteneurs suivent l'image, il est vital d'identifier le comportement de l'application conteneurisée et de détecter toute activité suspecte, notamment des appels système, des processus ou des communications inattendus.

Les équipes en charge de la sécurité doivent trouver où ces images sont mises en cache dans l'environnement runtime et identifier celles qui sont actives et dormantes.

Après avoir identifié les conteneurs non conformes, votre outil de sécurité doit vous permettre de déployer des contre-mesures de blocage ou de mise en quarantaine. Il doit aussi vous permettre d'analyser en détail les anomalies afin de pouvoir cerner les problèmes. Ce processus ne devrait avoir aucune incidence sur vos opérations dans la mesure où vous pouvez remplacer un conteneur non conforme par un nouveau conteneur à partir de l'image parente.

Pour plus d'efficacité, il est possible de valider automatiquement l'image par rapport aux politiques de sécurité au moyen de votre outil et d'empêcher l'utilisation d'images non approuvées comme conteneurs. Dans ce cas-là, s'appuyer sur des orchestrateurs tels que Kubernetes empêchera les conteneurs non conformes de s'introduire dans l'environnement via des contrôleurs d'admission.

De plus, il est recommandé de respecter les pratiques de sécurité indiquées pour les environnements d'orchestration pour disposer d'environnements basés sur un modèle à « moindre accès » et sécurisé. Si vous avez accès à l'hôte sous-jacent, renforcez-le pour satisfaire aux exigences en matière de vulnérabilités et de conformité.

En résumé                                                   

Nous espérons que cet article vous aura permis de mieux comprendre les défis de sécurité liés aux conteneurs et aussi de savoir comment les relever tout au long de leur cycle de vie. Pour ce faire, il faut donc empêcher les images vulnérables de pénétrer dans vos référentiels pendant la phase de création d’un environnement de développement d’applications (Build), sécuriser les images poussées vers vos registres au cours de la phase de mise à disposition, de stockage et de sécurisation des images de conteneurs (Ship) et également lancer des analyses pendant la phase de création d’environnements de production (Runtime) pour identifier et gérer les conteneurs compromis.