Tout comprendre à la sécurité des conteneurs

Si nous parlons de sécurité des conteneurs, il ne s’agit pas de logistique et de transport international. Dans le monde de la technologie, un conteneur est un environnement logiciel conteneurisé : il contient l’ensemble des paquets, bibliothèques et dépendances nécessaires pour exécuter un composant d’application logicielle de façon autonome.

Ces environnements peuvent être envisagés comme des systèmes d’exploitation (OS) virtualisés minimalistes : les conteneurs sont des systèmes portables, réutilisables et automatisés destinés à exécuter une application logicielle.

Pour répondre aux évolutions des besoins des équipes de développement logiciel, les conteneurs sont orchestrés et adaptés. Aujourd’hui, ils permettent aux entreprises de mettre rapidement sur le marché de nouvelles fonctionnalités et de réduire les cycles de publication, conformément à la philosophie des frameworks SDLC comme DevOps et Agile.

La sécurisation de ces conteneurs peut être intimidante pour une équipe de développement habituée à faire des contrôles de sécurité après le cycle de développement. Mais à l’heure où la sécurité se déplace vers l’amont du cycle dans les équipes DevOps, voyons ce que recouvre réellement la sécurité des conteneurs.

Conteneurs et virtualisation traditionnelle

Voyons en quoi les technologies de conteneurs diffèrent du modèle de virtualisation traditionnel, dans lequel la couche OS et les dépendances sont partagées entre différents composants logiciels.

La technologie de conteneurs présente les grandes caractéristiques suivantes :

Portable

Les technologies de conteneur peuvent être déplacées tout au long du pipeline SDLC. Une fois qu’une image de conteneur a été créée pour le développement, elle peut être employée dans les phases de test, d’assurance qualité et de production sans modification, dès lors que les configurations, dépendances et bibliothèques requises sont correctement partagées.

Le conteneur peut également être transféré d’une plateforme à l’autre et circuler entre différents modèles de prestation de service. Par exemple, le conteneur peut s’exécuter dans un cloud public ou privé, dans un environnement multicloud ou dans un data center virtualisé, tant que l’OS de l’hôte sous-jacent le prend en charge.

Minimaliste

Le conteneur d’application est créé avec le strict minimum de paquets logiciels nécessaires à l’exécution d’un composant d’application. Il n’exécute que les fonctionnalités d’OS requises par le processus applicatif : les autres fonctions d’OS sont assurées par l’hôte.

Si une application complexe nécessite un ensemble complexe de fonctions d’OS, il est possible de développer plusieurs conteneurs dans le cadre d’une architecture en microservices. 

Un conteneur est une méthode d’empaquetage, de déploiement et d’exécution d’un logiciel. On peut tout à fait créer une application monolithique géante en tant que conteneur. Mais on peut aussi créer une application avec des microservices qui n’utilise aucun conteneur.

Déclaratif

La technologie de conteneur repose sur une programmation déclarative, ce qui permet aux utilisateurs d’analyser des données qui décrivent le processus opérationnel du matériel sous-jacent. Ces données fournissent des informations sur la configuration de l’OS, des paquets et du réseau.

Immuable

L’état d’un conteneur reste constant, même pendant son déploiement et son exécution. Cela a plusieurs implications :

• Il n’est pas possible d’introduire des modifications en cours d’exécution.
• Les utilisateurs peuvent être contraints de créer un conteneur entièrement nouveau pour inclure les modifications nécessaires.
• Il faut utiliser des variables d’environnement pour modifier la configuration et le comportement des applications pendant l’exécution.

Immuabilité et persistance des données

Naturellement, ces caractéristiques influencent la façon dont les applications interagissent avec les données, et notamment sur la persistance des données, autrement dit la durée de vie et la récupération des données après la fin de vie du conteneur. Comme le conteneur est conçu pour fonctionner de façon autonome et éphémère, il doit être intégré à des systèmes externes de base de données ou de stockage en cluster pour assurer la persistance des données.

En raison de la nature portable et déclarative des technologies de conteneur, différentes équipes peuvent adopter des configurations communes et une approche cohérente de la mise en place de l’environnement d’exécution des conteneurs.

L’immuabilité des conteneurs apporte également une réponse à un problème courant, qu’on peut résumer par la phrase : « Chez moi, ça marche. » Dans la mesure où le conteneur contient toutes les dépendances et bibliothèques requises, les utilisateurs n’ont pas besoin d’adapter l’environnement d’exécution pour le faire fonctionner sur différentes machines ou différents OS hôtes.

Défis de la sécurité des conteneurs

Naturellement, ces caractéristiques créent leur propre éventail de défis en matière de cybersécurité, surtout lorsqu’on les compare aux machines virtuelles :

Nombreux composants d’environnement discrets

Les environnements monolithiques reposent sur un ensemble complet d’objets d’environnement pour exécuter une application. Il s’agit notamment de ressources qui ne sont pas portables, mais pensées pour exécuter plusieurs composants applicatifs au sein du même environnement d’infrastructure.

De leur côté, les conteneurs et les microservices incluent plusieurs composants discrets, provisionnés pour chaque composant d’application exécuté dans un conteneur isolé.

Une VM de service web, par exemple, n’aura besoin que d’une VM de serveur web front-end et d’une infrastructure de base de données en back-end. Dans le cas des microservices, en revanche, il faudra exécuter plusieurs conteneurs en front-end et en back-end pour prendre en charge les différents composants d’application et services.

Fréquence de modification élevée

L’agilité est un argument de poids pour l’adoption des technologies de conteneur, parce qu’elle permet aux développeurs de déployer rapidement de nouvelles fonctionnalités. Les nouveaux environnements de conteneurs et les changements fréquents dans les processus SDLC basés sur des microservices imposent l’utilisation d’outils et de pratiques de sécurité à la hauteur de ces opérations dynamiques. 

Distribution des responsabilités de cybersécurité

Il appartient davantage aux développeurs de mettre en place une stratégie de sécurité efficace pour les conteneurs qu’ils créent et distribuent sur les processus SDLC en amont. Par exemple, les développeurs sont tenus de mettre à jour une image de conteneur si l’un de ses composants s’avère vulnérable et qu’il existe un correctif de sécurité. Il faut donc une collaboration étroite entre les développeurs, les équipes d’infrastructure, les équipes d’exploitation et les experts en cybersécurité de l’entreprise.

La cybersécurité doit être portable

Comme le conteneur est distribué sur différentes plateformes d’infrastructure, les aspects de sécurité deviennent imprévisibles et changeants. Les développeurs ne peuvent avoir aucune certitude concernant ces plateformes, en particulier lorsqu’ils utilisent des services cloud tiers.

Il faut donc miser sur une stratégie de sécurité holistique, qui va impliquer les outils, les processus, les configurations et topologies de réseau, les systèmes d’exploitation hôte et d’autres dépendances susceptibles de varier tout au long du pipeline SDLC.

Vraiment éphémère ?

Contrairement aux VM, qui s’appuient sur des adresses IP statiques, les conteneurs dépendent des outils d’orchestration qui leur attribuent des adresses IP de façon dynamique. Les règles de sécurité et de pare-feu doivent donc être reconfigurées (souvent au prix d’une intervention humaine) au cours de la distribution du conteneur.

Système d’exploitation hôte

Le système d’exploitation hôte n’est pas nécessairement optimisé sur le plan de la sécurité, en particulier dans les environnements de cloud public qui sont conçus pour un usage généraliste.

Certes, le système de conteneur lui-même ne contient que quelques composants spécifiques à l’application, et les utilisateurs peuvent anticiper l’atténuation et la gestion des risques. Il reste toutefois que les conteneurs utilisent des composants généralistes de l’OS hôte qui peuvent être vulnérables sans que le développeur ne le sache.

Risque à l’exécution du conteneur

Relativement rare, le risque à l’exécution du conteneur désigne le cas où un paquet logiciel vulnérable inclus dans le conteneur peut permettre à des acteurs malveillants d’installer et propager des malwares sur le réseau. Si un conteneur est compromis alors que les outils et les processus de sécurité en place ne sont pas adaptés à ce type d’architecture, le trafic du conteneur peut échapper aux inspections visant à détecter les menaces de sécurité.

Risque lié à l’orchestration et aux images de conteneur

Le risque lié à l’orchestration et aux images de conteneur, qui se manifeste par des insuffisances dans les contrôles des identités et des accès, représente un défi supplémentaire du point de vue de la cybersécurité.

C’est particulièrement le cas du trafic réseau entre conteneurs : la circulation de ce trafic est assurée et gérée par un réseau virtuel superposé. Les outils d’orchestration qui régissent ce type de réseau ne possèdent pas nécessairement les capacités des outils de sécurité réseau existants.

Optimisation de la sécurité des conteneurs

Pour relever ces défis, vous pouvez optimiser la sécurité des conteneurs en misant sur trois aspects :

• la responsabilisation des développeurs et la sensibilisation aux questions de sécurité,
• l’orchestration des conteneurs et la threat intelligence réseau,
• l’atténuation des risques liés aux plateformes d’infrastructure cloud tierces.

Les conteneurs ne sont pas intrinsèquement plus ou moins sécurisés que les environnements non conteneurisés, mais leur complexité crée des défis de sécurité que les équipes doivent gérer avec soin. Bon nombre de ces vulnérabilités sont dues à des erreurs de configuration. En effet, 67 % des participants à une étude avaient de graves erreurs de configuration dans leur environnement de conteneurs ou Kubernetes. Toujours dans la même étude, 90 % des personnes interrogées avaient subi un incident de sécurité dans leur environnement de conteneurs ou Kubernetes au cours des 12 derniers mois.

Les conteneurs résidant dans un environnement cloud-native doivent être aussi sécurisés que tout autre type d’infrastructure informatique. Mais naturellement, la sécurisation de l’environnement est plus un chemin qu’une destination.