Comment concevoir et mettre en œuvre une stratégie efficace de microsegmentation des conteneurs avec Kubernetes

Microsegmentation est souvent considéré comme difficile à mettre en œuvre à grande échelle. Si votre objectif est de créer un segment (une limite de confiance) autour de chaque charge de travail dans l'ensemble de votre structure cloud, plusieurs facteurs doivent être pris en compte lors de la phase d'architecture. Les hôtes déployés en tant que serveurs virtuels ou en tant que machines virtuelles sont des entités familières, et leur comportement est bien connu du point de vue de la mise en réseau et de la sécurité. Toutefois, lorsque vous incluez des environnements de conteneurs dans l'architecture globale, vous introduirez probablement certaines mises en garde qui ne sont normalement pas importantes dans les architectures de réseau et de sécurité traditionnelles.

Lorsque vous déployez des conteneurs dans l'ensemble de votre cloud hybride, plusieurs questions se poseront éventuellement en matière de sécurité :

• Comment automatiser le déploiement et la gestion de microsegmentation de toutes les charges de travail des conteneurs?
• Comment intégrer la politique de segmentation des conteneurs et l'automatisation dans les outils de sécurité existants utilisés pour gérer les hôtes bare-metal et les machines virtuelles ?
• Aurai-je besoin de gérer deux solutions de microsegmentation distinctes : l'une pour les conteneurs et l'autre pour tout le reste ?

Les conteneurs peuvent se comporter de façon étrange, du point de vue du réseau et de la sécurité. Par exemple, les pods peuvent mourir subitement et être redémarrés automatiquement par la suite, mais avec une adresse IP différente. D'autre part, les services sont déployés devant des pods et agissent comme un équilibreur de charge. Alors, pour laquelle de ces entités dois-je définir un segment ? Un espace de noms peut s'étendre sur ces entités, alors comment le segmenter ? Et combien de charges de travail vais-je finir par créer une fois que tout sera entièrement déployé ?

Les conteneurs peuvent être un sujet difficile à comprendre en eux-mêmes et essayer de résoudre le « problème » de microsegmentation des conteneurs peut facilement compliquer encore plus les choses.

Comment pouvez-vous résoudre le défi de la microsegmentation afin de pouvoir introduire des conteneurs dans votre environnement existant sans enfreindre la stratégie de sécurité actuelle ou vous heurter accidentellement à un obstacle au fur et à mesure de l'évolution de l'architecture ?

Heureusement, ce est un problème qui peut être résolu. Laisse-moi t'expliquer.

Considérations à prendre en compte lors de l'ajout de conteneurs à une stratégie de microsegmentation existante

Un bon point de départ pour aborder la question des conteneurs et de la microsegmentation est d'aborder la question de l'échelle. Lorsque vous concevez une stratégie de segmentation pour toutes vos charges de travail sur l'ensemble de votre cloud hybride, la mise à l'échelle constitue toujours une mise en garde importante. Quelle sera l'ampleur de l'environnement global ?

En général, la réponse à cette question est d'additionner tous vos hôtes, qu'il s'agisse de machines virtuelles ou de machines virtuelles, puis de doubler ou tripler ce nombre pour tenir compte de la croissance future attendue. Ce chiffre sera un peu flou car certaines applications s'exécutent sur un cluster d'hôtes ou de machines virtuelles ; un hôte ne correspond pas toujours à une charge de travail. Mais assimiler une charge de travail à un hôte constitue un point de référence utile pour estimer les chiffres d'échelle. Ce nombre total final est ensuite comparé aux limites supérieures des charges de travail gérées qu'un fournisseur de microsegmentation spécifique peut prendre en charge.

Les hôtes bare-metal ne migrent pas souvent, ce sont donc des entités assez statiques autour desquelles définir des segments. Les machines virtuelles, en revanche, peuvent être un peu imprévisibles. Par exemple, ils peuvent être dynamiquement orientés vers le haut et vers le bas, migrés d'un segment de réseau à un autre et attribuer plusieurs adresses IP au cours de leur cycle de vie. Le nombre total d'hôtes sera donc un peu fluide. Cela dit, vous pouvez généralement estimer le nombre de machines virtuelles qui devraient être actives dans votre cloud afin d'atteindre le nombre total de charges de travail à gérer et à segmenter. Souvent, ce chiffre final se chiffre en centaines, voire en milliers.

Par conséquent, si l'on considère les limites d'échelle supérieures que les différents fournisseurs de microsegmentation peuvent prendre en charge, ces valeurs maximales semblent souvent « suffisantes ». Par exemple, si 1 000 charges de travail sont exécutées aujourd'hui dans un cloud et que ce nombre risque de doubler, voire de tripler au cours des prochaines années, il ne devrait pas y avoir d'inquiétude quant à l'atteinte de la limite supérieure de 20 000 charges de travail gérées d'un fournisseur spécifique dans un avenir proche. Les grands chiffres sont considérés comme une préoccupation lointaine.

Mais que se passe-t-il lorsque vous ajoutez des conteneurs à l'image ? Une charge de travail conteneurisée est une instance de calcul qui se comporte différemment des machines virtuelles et des hôtes bare-metal.

Par exemple, Kubernetes appelle « nœud » l'hôte sous-jacent, qu'il s'agisse d'une machine virtuelle ou d'un ordinateur nu, qui exécute des conteneurs. Sur chaque nœud, un ou plusieurs « pods » sont créés, et c'est dans chaque pod que s'exécutent les instances d'exécution du conteneur. Kubernetes recommande de déployer un maximum de 110 pods sur un nœud donné.

Par conséquent, si vous avez 100 nœuds dans votre cloud exécutant Kubernetes et que chaque nœud exécute 110 pods, vous pouvez vous retrouver avec 11 000 instances de calcul possibles qui doivent d'une manière ou d'une autre être définies comme des segments distincts. Si vous avez 200 nœuds, vous pouvez vous retrouver avec 22 000 instances de calcul possibles. Cela mérite d'être répété : seuls 200 nœuds de votre environnement de conteneurs peuvent générer 22 000 segments de charge de travail possibles.

Et ce n'est que dans votre environnement de conteneurs. Vous devrez ajouter toutes les charges de travail non conteneurisées sur l'ensemble de votre cloud hybride afin d'estimer le nombre attendu de charges de travail gérées et les segments possibles. La leçon apprise est que le nombre maximum de charges de travail gérées, que les différents fournisseurs de microsegmentation peuvent prendre en charge, ne semble plus si inaccessible.

Une solution pour les conteneurs et les non-conteneurs

Lorsque vous envisagez de segmenter un environnement de conteneurs, plusieurs fournisseurs permettent la microsegmentation au sein et entre les clusters dans Kubernetes ou OpenShift. Cependant, la plupart de ces solutions se concentrent spécifiquement sur les environnements de conteneurs et non sur les charges de travail non conteneurisées de votre cloud hybride. En réalité, la plupart des réseaux dotés de charges de travail en conteneurs ont également des charges de travail non conteneurisées, du matériel nu et des machines virtuelles, qui coexistent tous dans la même structure cloud.

Si vous choisissez de déployer une solution de segmentation pour les conteneurs et une autre solution de segmentation pour les machines virtuelles et les machines virtuelles, vous obtiendrez deux ensembles d'outils distincts qui n'automatisent ni ne corrélent les événements entre eux. Cette approche peut fonctionner à petite échelle, mais elle deviendra difficile à mettre en œuvre et à gérer à mesure que le déploiement se développera. Vous devez éviter cette approche cloisonnée de la segmentation de la charge de travail. Les charges de travail conteneurisées doivent être gérées de la même manière sur l'ensemble de la structure informatique afin de créer une solution unifiée pour le déploiement et la gestion de tous segmentation des charges de travail.

Illumio, par exemple, fonctionne sur toutes les charges de travail, des machines virtuelles aux conteneurs en passant par les machines virtuelles. Il n'existe aucune disparité de fonctionnalités entre les charges de travail conteneurisées et les charges de travail non conteneurisées. Vous bénéficiez donc d'une microsegmentation avec visualisation, automatisation et gestion des politiques pour toutes les charges de travail.

Espaces de noms, pods ou services ?

Kubernetes définit trois entités de conteneurs principales dans lesquelles le trafic réseau entrant et sortant peut être contrôlé : un pod, un service ou un espace de noms. (Remarque : les nœuds ne sont pas considérés comme une destination entre ces entités, et un cluster est défini comme la limite la plus large autour d'un ensemble de nœuds). En outre, un équilibreur de charge est souvent déployé sur le périmètre du cluster, ce qui permet de segmenter quatre entités possibles. Lors de la définition de votre architecture de microsegmentation, laquelle de ces entités doit être classée en tant que segment ? Certains d'entre eux ou tous ?

Un pod est la plus petite entité à laquelle Kubernetes peut attribuer une adresse IP. Les instances d'exécution de Containers s'exécuteront dans un ou plusieurs pods, et ces pods devront souvent communiquer entre eux. Chaque pod peut être défini comme un segment, mais le défi est que Kubernetes peut ralentir puis relancer des pods, ce qui, du point de vue de la mise en réseau, signifie que les adresses IP de destination ou source peuvent soudainement disparaître. Les équipes chargées des réseaux et de la sécurité n'apprécient pas que des entités disparaissent soudainement dans la structure globale, ce qui complique la gestion des outils de convergence des routes et de sécurité.

Kubernetes peut déployer un service, qui est déployé devant un nombre donné de pods, agissant presque comme un équilibreur de charge pour les modules situés derrière celui-ci. Les services sont beaucoup plus stables, et bien que Kubernetes puisse lancer et ralentir les pods de manière dynamique, il le fait rarement avec les services. Par conséquent, il est recommandé de définir un service comme un segment, et non comme un module individuel.

Il est important que vous demandiez à votre fournisseur de microsegmentation s'il peut définir un pod ou un service en tant que segment, en laissant le choix à votre administrateur de sécurité.

Les applications déployées dans des conteneurs sont généralement déployées en tant qu'espace de noms, le code s'exécutant essentiellement de manière distribuée dans un ou plusieurs pods. Un espace de noms de conteneurs est une abstraction entre plusieurs pods et services.

Illumio, par exemple, vous permet de définir un « profil » par rapport à un espace de noms, puis de définir ce profil en tant que segment. Le résultat est qu'Illumio permet de définir un segment en fonction d'un pod, d'un service ou d'un espace de noms. Et, contrairement aux outils de microsegmentation conçus spécifiquement pour les environnements conteneurisés, Illumio peut également définir des segments par rapport à l'hôte sous-jacent, aux points d'entrée/sortie à la limite du cluster et aux charges de travail existantes environnantes qui doivent accéder aux ressources des conteneurs. Les segments n'existent pas uniquement dans les conteneurs, ils existent dans l'ensemble de la structure cloud.

C'est pourquoi vous devez vous assurer que votre fournisseur de microsegmentation peut gérer plus de 100 000 charges de travail. Plus les environnements de conteneurs sont déployés dans une structure cloud, plus ces chiffres élevés sont rapidement pris en compte. Et ces chiffres concernent les charges de travail qui, dans des conteneurs, sont souvent éphémères, les charges de travail prenant vie et disparaissant de manière dynamique. Cela signifie que votre solution de microsegmentation doit répondre aux changements en temps réel.

En utilisant l'instance Kubelink d'Illumio déployée dans un cluster de conteneurs, vous pouvez découvrir de manière dynamique les charges de travail déployées et mises hors service, activer notre carte des dépendances des applications, et appliquez des outils pour réagir en temps réel à toute modification des charges de travail gérées. L'automatisation et l'orchestration sont deux concepts importants dans les conteneurs, et Illumio les met en œuvre pour rendre opérationnelle la gestion de la microsegmentation à la fois à l'intérieur et à l'extérieur de l'environnement des conteneurs.

Le déploiement de conteneurs dans votre cloud ne doit pas impliquer de sacrifier la capacité à définir des segments autour des charges de travail, quelle que soit la manière dont elles sont déployées. Assurez-vous que votre solution de segmentation continuera à évoluer pour atteindre les mêmes niveaux élevés que les charges de travail conteneurisées le permettent, sans aucun obstacle. Avec Illumio Core, votre entreprise peut atteindre Confiance zéro autour de chaque charge de travail dans l'ensemble de votre infrastructure cloud, quelle que soit l'échelle.

Vous en voulez plus ? Consultez nos dernières fiche technique qui explique comment Illumio Core s'étend aux conteneurs.