Concevoir une stratégie d’orchestration de conteneurs et d’architecture en conteneurs sécurisée
Si vous utilisez des conteneurs, vous savez probablement que l’orchestration de conteneurs est essentielle pour gérer des workloads complexes à l’échelle.
Cependant, l’orchestration de conteneurs ne se limite pas à la gestion des conteneurs. Elle revêt également des aspects essentiels pour la sécurité des conteneurs . En définissant votre architecture en conteneur et la manière dont les conteneurs peuvent interagir entre eux, votre approche en matière d’orchestration des conteneurs contribue à déterminer le degré de sécurité de votre environnement par défaut et la probabilité qu’une brèche se propage d’un conteneur à l’ensemble du cluster.
C’est la raison pour laquelle la planification d’une stratégie d’orchestration sécurisée de conteneurs, ainsi que l’intégration de la sécurité au sein de votre architecture basée sur les conteneurs, constituent deux aspects fondamentaux de la sécurité globale des conteneurs. Cet article explique comment sécuriser les conteneurs sur le plan de l’orchestration et de l’architecture.
Définition de l’orchestration des conteneurs
L’orchestration des conteneurs est l’utilisation d’outils automatisés pour gérer les opérations nécessaires à l’exécution de conteneurs.
Les plates-formes d’orchestration de conteneurs, comme Kubernetes, Amazon ECS et Docker Swarm, gèrent automatiquement des tâches telles que la désignation des nœuds d’un cluster de serveurs devant héberger un conteneur spécifique, ou encore le redémarrage des conteneurs en cas de défaillance ou lorsqu’ils ne répondent plus. Ce travail prendrait beaucoup de temps s’il devait être réalisé manuellement. C’est pourquoi l’orchestration des conteneurs est très pratique, car elle permet de déployer des environnements en conteneurs à grande échelle comprenant des dizaines, des centaines, voire des milliers de conteneurs répartis sur un grand nombre de nœuds.
Sécurité et orchestration des conteneurs
Le principal objectif de l’orchestration des conteneurs n’est pas de sécuriser les conteneurs, et les plates-formes d’orchestration de conteneurs ne sont pas des plates-formes de sécurité. La plupart des exigences en matière de sécurité d’un environnement en conteneurs sont gérées par des outils externes qui peuvent surveiller et détecter les menaces, et aider à y remédier.
Néanmoins, l’approche que vous adoptez en matière d’orchestration et la plate-forme d’orchestration que vous choisissez contribuent à définir votre positionnement global vis-à-vis de la sécurité des conteneurs.
En effet, votre stratégie en matière d’orchestration des conteneurs joue un rôle majeur dans la définition de la configuration de votre environnement en conteneurs, ainsi que du type d’architecture que vous utilisez pour lancer, déployer et gérer les conteneurs. Il y a des stratégies en matière d’orchestration et des architectures basées sur des conteneurs qui sont plus sécurisées que d’autres. Ceci s’explique en raison de différents facteurs, tels que le degré d’isolement des conteneurs et les outils mis en place pour appliquer les exigences de sécurité et de gouvernance lors de la gestion d’opérations de conteneurs.
Concevoir une architecture en conteneurs sécurisée
Plusieurs considérations essentielles en matière de sécurité doivent être prises en compte lors de la planification d’une stratégie d’orchestration et de la conception de l’architecture de votre environnement.
Isolation des conteneurs
Le facteur le plus important à évaluer est la capacité de votre architecture et votre orchestrateur à isoler chaque conteneur.
En général, il faut trouver un juste équilibre entre trop d’isolation et pas assez. Si les conteneurs n’arrivent pas du tout à partager des données avec d’autres conteneurs sur le réseau, à accéder aux mêmes volumes de stockage de données et à interagir de toute autre manière, vous aurez probablement beaucoup de difficulté à déployer une application viable à l’aide de conteneurs. C’est tout particulièrement vrai si votre application utilise une architecture de microservices, dans laquelle chaque microservice est déployé dans son propre ensemble de conteneurs et doit communiquer avec d’autres conteneurs pour que l’application, dans son intégralité, fonctionne.
Des tâches comme la surveillance peuvent également être difficiles à réaliser lorsque l’isolation que vous avez appliquée à votre architecture en conteneurs est trop importante. Bien souvent, les outils de surveillance pour les environnements en conteneurs reposent sur une architecture « sidecar », dans laquelle un conteneur hébergeant un agent de surveillance s’exécute en parallèle à des conteneurs d’application qu’il doit surveiller. Si l’agent de surveillance ne peut pas communiquer avec les autres conteneurs, il ne pourra pas collecter les journaux et les métriques dont il a besoin pour assurer correctement la surveillance.
D’autre part, une isolation trop faible entre les conteneurs peut engendrer des problèmes de sécurité. Une attribution excessive d’autorisations à chaque conteneur n’engendre pas directement une brèche de sécurité. Cependant, elle peut considérablement en aggraver d’autres, dont l’origine des problèmes pourrait être des vulnérabilités dans une image de conteneur, un runtime de conteneur non sécurisé ou un OS hôte. Vous pouvez gérer ces risques grâce à des contrôles tels que les contextes de sécurité Kubernetes, qui restreignent les actions que les conteneurs sont autorisés à effectuer.
Pour trouver le juste milieu entre une isolation trop faible et une isolation trop importante, appliquez le principe du « privilège minimum » à vos conteneurs. Assurez-vous que chaque conteneur a la possibilité d’accéder aux ressources externes dont il a besoin pour remplir son rôle au sein de l’environnement, mais pas plus. Vérifiez également que les autorisations sont définies de manière granulaire. Résistez à la tentation d’appliquer des contextes de sécurité génériques à un namespace entier ou (pire encore) à un cluster. Les autorisations granulaires exigent un travail de configuration et de gestion plus important, mais elles renforcent la sécurité globale.
Runtimes de conteneurs
Un runtime de conteneurs est une application qui exécute des conteneurs individuels. De nombreux runtimes existent, tels que containerd et runC. Les runtimes font tous la même chose, ils exécutent des conteneurs, mais ils le font de manière légèrement différente.
Comme tous les orchestrateurs ne prennent pas en charge tous les runtimes, la solution d’orchestration que vous choisissez définira le ou les runtimes de conteneurs que vous pouvez utiliser pour déployer des conteneurs. Par exemple, Kubernetes prend en charge la plupart des principaux runtimes de conteneurs, tandis qu’Amazon ECS ne prend en charge que le runtime de conteneurs propriétaire d’Amazon.
En général, aucun runtime de conteneurs n’est fondamentalement plus sécurisé que les autres. Tous les principaux runtimes de conteneurs ont fait l’objet de vulnérabilités importantes en matière de sécurité.
Cependant, certains projets, comme Kata Containers, ont pour but de créer des runtimes intrinsèquement plus sécurisés en apportant des modifications à l’architecture même du runtime. Pour Kata, par exemple, les conteneurs ne partagent pas de noyau, ce qui réduit considérablement le risque d’attaques d’escalade de privilèges et de contrôles d’accès non sécurisés.
En choisissant une stratégie d’orchestration de conteneurs et une architecture en conteneurs globale qui vous permet de tirer parti des runtimes de conteneurs axés sur la sécurité, vous pouvez bénéficier de certains avantages en matière de sécurité qui ne sont pas actuellement disponibles avec les runtimes standards.
Systèmes d’exploitation pris en charge
Aujourd’hui, la plupart des conteneurs fonctionnent sous Linux, et la distribution Linux utilisée pour héberger les conteneurs n’a généralement pas d’importance. Les conteneurs se comportent de la même manière, peu importe l’OS ou la configuration Linux qui les héberge.
Pour autant, des conteneurs Windows existent également pour les équipes qui souhaitent déployer des applications en conteneurs sur Windows.
Le degré de prise en charge de Windows par les différentes solutions d’orchestration varie. Kubernetes peut gérer des machines Windows en tant que nœuds worker, mais pas en tant que nœuds maîtres. Cela signifie que vous pouvez orchestrer des conteneurs Windows avec Kubernetes, mais que vous devrez toujours utiliser des outils Linux pour les gérer. En revanche, Docker Swarm offre une prise en charge assez complète des conteneurs Windows.
Quel est le rapport entre la prise en charge du système d’exploitation et la sécurité des conteneurs ? Pas grand-chose, il faut bien l’avouer, mais il est possible d’affirmer qu’il est plus sécurisé de déployer des conteneurs Windows que des conteneurs Linux. La raison est que les conteneurs Windows sont beaucoup moins populaires, ce qui en fait une cible moins commune pour les personnes mal intentionnées. (C’est bien sûr assez ironique, quand on sait que c’est tout l’inverse lorsqu’on parle de logiciels de bureau, où Linux est une cible beaucoup moins privilégiée que Windows. Cependant, la plupart des conteneurs sont conçus pour héberger des workloads serveur plutôt que des applications de bureau).
Par conséquent, dans le cas où vous souhaitez vous orienter vers une stratégie de sécurité prête à l’emploi, envisagez de mettre en place une architecture de conteneurs qui vous permette d’utiliser des conteneurs Windows.
Plugins tiers
Une dernière considération essentielle à prendre en compte pour la conception d’une architecture de conteneurs sécurisée est la mesure dans laquelle vous devrez vous appuyer sur des plugins tiers pour concevoir l’environnement dans son ensemble.
Certains orchestrateurs, comme Kubernetes, sont conçus de façon à être très modulaires. En général, Kubernetes exploite les plugins de projets tiers pour permettre la gestion des données, la gestion du réseau, etc.
D’autres orchestrateurs, comme Amazon ECS, ont fait le choix d’adopter une architecture moins modulaire. Ils vous donnent un ensemble d’outils intégrés et limitent les possibilités de passer à des solutions alternatives.
Du point de vue de la sécurité, les plugins tiers sont à la fois une aubaine et un défi. D’une part, de bons plugins tiers peuvent vous permettre de bénéficier d’une surveillance et d’une visibilité de la sécurité supérieures à ce que vous pouvez obtenir avec les outils natifs de l’orchestrateur.
D’autre part, une plus grande dépendance vis-à-vis des modules tiers se traduit souvent par un plus grand nombre de potentielles expositions à des problèmes de sécurité, ainsi qu’à plus de vulnérabilités que vous devrez suivre et gérer. Si vous utilisez uniquement les outils natifs mis à disposition par votre orchestrateur, les seules vulnérabilités auxquelles vous vous exposez sont celles associées à ces outils. Si vous déployez Kubernetes en utilisant de nombreux plugins externes, vous devrez gérer les risques en matière de sécurité pour chaque plugin utilisé, en plus du travail de sécurisation de Kubernetes en soi.
De manière générale, les avantages d’une architecture modulaire l’emportent vraisemblablement sur les risques. Cependant, si vous préférez la simplicité, optez pour un orchestrateur moins modulaire.
La conception d’une architecture en conteneurs et une stratégie d’orchestration sécurisée par défaut ne vous protège pas des menaces. D’autres risques divers et variés peuvent encore s’immiscer dans votre environnement par le biais d’images corrompues, d’attaques au niveau de l’OS ou d’autres menaces similaires. Cependant, une architecture et un orchestrateur sécurisés vous permettront d’isoler les menaces et d’y remédier efficacement lorsqu’elles apparaîtront.