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

La microsegmentation est souvent considérée 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 en nuage, plusieurs facteurs doivent être pris en compte lors de la phase d'architecture. Les hôtes déployés sous forme de bare-metal ou de VM sont des entités familières, et leur comportement est bien connu du point de vue du réseau et de la sécurité. Mais lorsque vous incluez des environnements de conteneurs dans l'architecture globale, vous allez probablement introduire 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 votre nuage hybride global, plusieurs questions relatives à la sécurité finiront par se poser :

• Comment automatiser le déploiement et la gestion de la microsegmentation pour 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 machines nues et les hôtes virtuels ?
• Devrai-je gérer deux solutions de microsegmentation distinctes : une pour les conteneurs et une autre pour tout le reste ?

Les conteneurs peuvent se comporter de manière étrange, du point de vue du réseau et de la sécurité. Par exemple, les pods peuvent mourir soudainement 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 les 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 plusieurs entités, alors comment le segmenter ? Et combien de charges de travail vais-je créer lorsque tout sera entièrement déployé ?

Les conteneurs peuvent être un sujet difficile à comprendre en soi et essayer de résoudre le "problème" de la microsegmentation avec des conteneurs peut facilement compliquer la question encore plus.

Comment pouvez-vous résoudre le défi de la microsegmentation afin d'introduire des conteneurs dans votre environnement existant sans rompre la stratégie de sécurité actuelle ou sans vous heurter accidentellement à des obstacles au cours de l'évolution de l'architecture ?

Heureusement, ce problème peut être résolu. Je m'explique.

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

Un bon point de départ pour la conversation sur les conteneurs et la microsegmentation est d'aborder la question de l'échelle. Lors de la conception d'une stratégie de segmentation pour toutes vos charges de travail dans l'ensemble de votre nuage hybride, la mise à l'échelle est toujours une mise en garde importante. Quelle sera la taille de l'environnement global ?

En règle générale, la réponse à cette question consiste à additionner tous vos hôtes - bare-metal et VM - puis à doubler ou tripler ce nombre pour tenir compte de la croissance future prévue. Ce chiffre est un peu flou car certaines applications sont exécutées sur une grappe d'hôtes ou de machines virtuelles ; un seul hôte n'est pas toujours synonyme d'une seule charge de travail. Mais l'assimilation d'une charge de travail à un hôte est un point de repère utile pour estimer les chiffres de mise à l'é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 nus ne migrent pas souvent, ce sont donc des entités assez statiques autour desquelles il faut définir des segments. Les machines virtuelles, en revanche, peuvent être un peu imprévisibles. Par exemple, ils peuvent être activés et désactivés de manière dynamique, migrer entre les segments du réseau et se voir attribuer plusieurs adresses IP tout au long de leur cycle de vie. Le nombre total d'hôtes sera donc un peu fluctuant. Cela dit, vous pouvez généralement estimer le nombre de machines virtuelles qui devraient être actives dans votre nuage afin d'atteindre le nombre total de charges de travail qui doivent être gérées et segmentées. Souvent, ce chiffre final se situe dans les centaines, voire les quelques milliers d'euros.  

Par conséquent, lorsque l'on considère les limites supérieures de l'échelle que les différents fournisseurs de microsegmentation peuvent prendre en charge, ces chiffres maximaux sembleront souvent "suffisants". Par exemple, si un nuage compte aujourd'hui 1 000 charges de travail et que ce nombre est susceptible de doubler, voire de tripler, au cours des prochaines années, il n'y a pas lieu de craindre que la limite supérieure de 20 000 charges de travail gérées fixée par un fournisseur spécifique soit atteinte de sitôt. Les grands chiffres sont considérés comme une préoccupation lointaine.

Mais que se passe-t-il lorsque vous ajoutez des conteneurs au tableau ? Une charge de travail conteneurisée est une instance de calcul qui se comporte différemment des machines virtuelles et des hôtes nus.

Par exemple, Kubernetes appelle "nœud" l'hôte sous-jacent, qu'il s'agisse d'une VM ou d'un bare-metal, qui exécute des conteneurs. Sur chaque nœud, un ou plusieurs "pods" sont créés, et c'est au sein de chaque pod que les instances d'exécution des conteneurs sont exécutées. 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 qui exécutent 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. Il faut le répéter : 200 nœuds seulement dans votre environnement de conteneurs peuvent donner lieu à 22 000 segments de charge de travail possibles.

Et ce, uniquement dans votre environnement de conteneurs. Vous devrez ajouter toutes les charges de travail non conteneurisées dans l'ensemble de votre nuage hybride afin d'estimer le nombre prévu de charges de travail gérées et de segments possibles. L'enseignement tiré 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 unique pour les conteneurs et les non-conteneurs

Lorsque vous réfléchissez à la manière de segmenter un environnement de conteneurs, il existe plusieurs fournisseurs qui 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 dans votre nuage hybride. En réalité, la plupart des réseaux qui ont des charges de travail conteneurisées ont également des charges de travail non conteneurisées, bare-metal et VM, qui coexistent toutes dans la même structure de nuage.

Si vous choisissez de déployer une solution de segmentation pour les conteneurs et une autre solution de segmentation pour les machines nues et les machines virtuelles, vous obtiendrez deux ensembles d'outils distincts qui n'automatisent pas les événements et ne les mettent pas en corrélation. Cette approche peut fonctionner à petite échelle, mais il sera difficile de la rendre opérationnelle et de la gérer au fur et à mesure que le déploiement prendra de l'ampleur. 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 l'ensemble de la segmentation des charges de travail.

Illumio, par exemple, fonctionne avec toutes les charges de travail, du bare-metal aux VM en passant par les conteneurs. Il n'y a pas de 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 règles pour toutes les charges de travail.

Namespaces, pods ou services ?

Kubernetes définit trois principales entités de conteneurs 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 une grappe est définie comme la limite la plus large autour d'une collection de nœuds). En outre, il y a souvent un équilibreur de charge déployé au périmètre du cluster, ce qui donne quatre entités possibles qui peuvent être segmentées. Lors de la définition de votre architecture de microsegmentation, laquelle de ces entités doit être classée comme 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 des conteneurs s'exécutent dans un ou plusieurs pods, et ces pods doivent souvent communiquer entre eux. Chaque pod peut être défini comme un segment, mais la difficulté réside dans le fait que Kubernetes peut désactiver puis réactiver des pods, ce qui, du point de vue du réseau, signifie que les adresses IP de destination ou de 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 le tissu global, ce qui complique la gestion de la convergence des routes et des outils 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 pods derrière lui. Les services sont beaucoup plus stables, et bien que Kubernetes puisse dynamiquement activer et désactiver les pods, il le fera rarement avec les services. Par conséquent, la meilleure pratique consiste à définir un service en tant que segment, et non en tant que pods individuels.

Il est important que vous demandiez à votre fournisseur de microsegmentation s'il peut définir un pod ou un service comme segment, afin de laisser 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 comme un segment. Il en résulte qu'Illumio permet de définir un segment par rapport à un pod, un service ou 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 et de sortie à la limite de la grappe et aux charges de travail patrimoniales environnantes qui ont besoin d'accéder aux ressources dans les conteneurs. Les segments n'existent pas seulement à l'intérieur des conteneurs, ils existent dans l'ensemble de la structure du nuage.

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 en nuage, plus ces chiffres élevés apparaissent rapidement. Et ces chiffres concernent des charges de travail qui, dans les conteneurs, sont souvent éphémères, avec des charges de travail qui naissent et disparaissent 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 une grappe de conteneurs, vous pouvez découvrir dynamiquement les charges de travail qui sont déployées et mises hors service, activer notre carte de dépendance des applications et appliquer des outils pour réagir en temps réel à tous les changements dans les 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 à l'intérieur et à l'extérieur de l'environnement des conteneurs.

Déployer des conteneurs dans votre cloud ne doit pas signifier 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 vers les mêmes nombres élevés que les charges de travail conteneurisées, sans rencontrer d'obstacles. Avec Illumio Core, votre entreprise peut atteindre la confiance zéro pour chaque charge de travail dans l'ensemble de votre structure d'informatique en nuage, quelle que soit l'échelle.

Vous en voulez plus ? Découvrez comment Illumio Core peut sécuriser Kubernetes et OpenShift.

Contactez-nous dès aujourd'hui pour savoir comment sécuriser vos conteneurs avec la Segmentation Zéro Confiance d'Illumio.