La conteneurisation a amené de nombreuses entreprises et organisations à développer et à déployer des applications différemment. Un rapport récent de Gartner indique que d’ici 2022, plus de 75 % des organisations mondiales utiliseront des applications conteneurisées en production, contre moins de 30 % en 2020. Cependant, si les conteneurs présentent de nombreux avantages, ils restent certainement une source d’exposition aux cyberattaques s’ils ne sont pas correctement sécurisés.
Auparavant, la cybersécurité consistait à protéger un seul « périmètre ». En introduisant de nouvelles couches de complexité, les conteneurs ont rendu ce concept obsolète. Les environnements conteneurisés ont beaucoup plus de niveaux d’abstraction, ce qui nécessite l’utilisation d’outils spécifiques pour interpréter, surveiller et protéger ces nouvelles applications.
La sécurité des conteneurs consiste à utiliser un ensemble d’outils et de politiques pour les protéger contre les menaces potentielles. Ces dernières peuvent affecter l’application, l’infrastructure, les bibliothèques système, le temps d’exécution, etc. La sécurité des conteneurs implique la mise en œuvre d’un environnement sécurisé pour la pile de conteneurs, qui se compose des éléments suivants :
La plupart des professionnels du logiciel partent automatiquement du principe que Docker et les noyaux Linux sont à l’abri des logiciels malveillants, une hypothèse facilement surestimée.
Les conteneurs sont isolés de l’hôte, bien qu’ils partagent tous deux les ressources du noyau. Souvent négligé, cet aspect rend plus difficile, mais pas impossible, pour un attaquant de compromettre le système d’exploitation par le biais d’un exploit du noyau afin d’obtenir un accès racine à l’hôte.
Les hôtes qui exécutent vos conteneurs doivent disposer de leur propre ensemble d’accès de sécurité en place en s’assurant que le système d’exploitation hôte sous-jacent est à jour. Par exemple, il exécute la dernière version du moteur de conteneur. Idéalement, vous devrez mettre en place une surveillance pour être alerté de toute vulnérabilité sur la couche hôte. Choisissez également un « système d’exploitation léger », qui accélérera le déploiement de votre application et réduira la surface d’attaque en supprimant les paquets inutiles et en réduisant au maximum votre système d’exploitation.
Essentiellement, dans un environnement de production, il n’est pas nécessaire de laisser un administrateur humain se connecter en SSH à l’hôte pour appliquer des changements de configuration. Au lieu de cela, il serait préférable de gérer tous les hôtes par le biais de l’IaC avec Ansible ou Chef, par exemple. De cette manière, seul l’orchestrateur peut avoir un accès permanent pour lancer et arrêter les conteneurs.
Des analyses régulières des vulnérabilités de votre conteneur ou de votre hôte doivent être effectuées pour détecter et corriger les menaces potentielles que les pirates pourraient utiliser pour accéder à votre infrastructure. Certains registres de conteneurs proposent ce type de fonctionnalité ; lorsque votre image est transférée au registre, celui-ci l’analyse automatiquement pour détecter d’éventuelles vulnérabilités.
Une façon d’être proactif est de mettre en place une analyse des vulnérabilités dans votre pipeline CI en adoptant la philosophie « shift left », ce qui signifie que vous mettez en œuvre la sécurité dès le début de votre cycle de développement. Là encore, Trivy serait un excellent choix pour y parvenir.
Supposons que vous essayiez de mettre en place ce type d’analyse sur vos nœuds sur site. Dans ce cas, Wazuh est une option solide qui enregistrera chaque événement et le vérifiera par rapport à plusieurs bases de données CVE (Common Vulnerabilities and Exposure).
Les registres de conteneurs constituent un moyen pratique et centralisé de stocker et de distribuer des images. Il est courant de voir des organisations stocker des milliers d’images dans leurs registres. Étant donné que le registre est si important pour le fonctionnement d’un environnement conteneurisé, il doit être bien protégé. C’est pourquoi vous devriez envisager de consacrer du temps à la surveillance et à la prévention des accès non autorisés à votre registre de conteneurs.
Une autre mesure que vous pouvez prendre consiste à renforcer la sécurité autour de votre orchestration de conteneurs, par exemple en prévenant les risques liés aux comptes sur-privilégiés ou aux attaques sur le réseau. En suivant le modèle de l’accès le moins privilégié, la protection des communications de pod à pod limiterait les dommages causés par une attaque. Un outil que nous recommandons dans ce cas est Kube Hunter, qui agit comme un outil de test de pénétration. En tant que tel, il vous permet d’exécuter une variété de tests sur votre cluster Kubernetes afin que vous puissiez commencer à prendre des mesures pour améliorer la sécurité autour de lui.
Vous pouvez également être intéressé par Kubescape, qui est similaire à Kube Hunter ; il analyse votre cluster Kubernetes, les fichiers YAML et les HELM Charts pour vous fournir un score de risque :
Un conteneur ou un fichier Docker ne devrait pas contenir de secrets (certificats, mots de passe, jetons, clés API, etc.) et pourtant, on voit souvent des secrets codés en dur dans le code source, les images ou le processus de construction. Le choix d’une solution de gestion des secrets vous permettra de stocker les secrets dans un coffre-fort sécurisé et centralisé.
Il s’agit là de quelques-unes des mesures de sécurité proactives que vous pouvez prendre pour protéger vos environnements conteneurisés. Ceci est vital car Docker n’existe que depuis peu, ce qui signifie que ses capacités de gestion et de sécurité intégrées n’en sont qu’à leurs balbutiements. Heureusement, la bonne nouvelle est qu’il est facile d’assurer une sécurité décente dans un environnement conteneurisé à l’aide de plusieurs outils, tels que ceux que nous avons énumérés dans cet article.
