Tech Radar - Empowering

Adopt

Kyverno

Open source, simple d’utilisation et efficace, Kyverno permet d’assurer le respect de bonnes pratiques de sécurité au runtime dans Kubernetes.

Si la plupart des paramètres de sécurité des workloads doivent être vérifiés au plus tôt, notamment en CI/CD, l’imposition de policy directement intégrée au moteur de validation de Kubernetes permet le respect des bonnes pratiques de manière certaine.

Kubernetes étant un élément critique des infrastructures, il est nécessaire d’y imposer des bonnes pratiques de sécurité. Nativement, le control plane de Kubernetes n’offre pas la possibilité de définir finement des politiques de sécurité custom (les Pods Admission Policies disponibles depuis la 1.25 permettent une gestion basique).

Kyverno est un policy engine dans Kubernetes. La puissance de Kyverno réside dans la simplicité d’écriture des policies en yaml. En status Incubating depuis 2020 au sein de l’incubateur CNCF, Kyverno a connu depuis une traction très forte comparée à son concurrent principal OPA Gatekeeper.

Basé sur les validationWebhook et mutationWebhook Kubernetes, l’outil propose une large gamme de policies pré-rédigées. Par exemple, exiger la présence de request/limit pour tous les pods ou interdire la création de pods privilégiés.

Kyverno offre également un moyen élégant d’ajouter des configurations de sécurité à la volée via des mutations Webhooks :

Ajouter un proxy HTTP en variable d’environnement des pods
Créer des droits RBAC dynamiquement à la création d’un namespace

Nous conseillons néanmoins de limiter l’usage des mutationPolicies qui peuvent nuire à la compréhension lors d’incidents : la ressource n’étant plus exactement définie as code, la personne en charge du debug doit avoir connaissance de ce mécanisme.

Warning : Comme tous les outils tirant parti des webhooks Kubernetes, Kyverno peut être un SPOF si sa FailurePolicy est en Fail : si Kyverno est down, l’API Server ne peut pas valider les requêtes et n’autorise donc aucune action. Une bonne pratique est de whitelister les namespaces critiques tels que kube-system pour éviter tout problème.

Vault

Vault est un outil de gestion de secrets incontournable pour toutes les organisations.

Hashicorp Vault a déjà plus de 8 ans et est toujours l'outil de gestion de secrets le plus plébiscité par la communauté. Cela est possible grâce aux innombrables features et améliorations que Vault a apporté à ce secteur :

La génération de secrets dynamiques
La gestion fine d'accès aux secrets en suivant un pattern RBAC applicable à n’importe quel type d'identité (utilisateurs, groupes, machines)
L’intégration de différentes sources d'authentification (e.g Kubernetes)
La gestion de certificats directement via une API

Deux différences majeures font que Vault s’impose face à ses concurrents. Tout d’abord, son intégration avec différentes sources d’identités (e.g AWS, GCP, Kubernetes) qui permettent à vos workloads de s’authentifier et d’être autorisés à récupérer automatiquement leurs différents secrets. Mais également les différents moteurs de secrets dynamiques (Database, AWS, GCP) qui permettent une rotation des secrets à chaque utilisation.

Nous n’avons qu’une seule mise en garde quant à son adoption en mode auto-hébergé : Vault est un outil complexe et peut ne pas convenir à une petite organisation. Il ajoute comme toute technologie un coût d'opérabilité, et une mauvaise gestion de vos backups ou une mauvaise anticipation d’une mise à jour pourrait vous mener droit dans le mur.

La gestion de secrets étant une feature centrale de toute plate-forme, ne minimisez pas ce coût d'opérabilité. Si votre équipe est déjà surchargée, préférez l'utilisation de la version SaaS de Vault ou alors les services de gestion de secrets de vos Cloud Provider.

Nous ne pouvons que le recommander aujourd'hui tant il nous a permis de répondre à des problématiques complexes (e.g. mTLS on premise) sans ajouter un coût de maintenance prohibitif.

Hub and Spoke

Le Hub and Spoke est un modèle organisationnel et réseau utilisé pour la gestion des comptes cloud. Il permet d’isoler des ressources utilisées par des applications ou des business (Spoke) avec un compte (Hub) qui centralise les communications réseau et partage des outils à tous les spokes.

Il est facile de créer des ressources dans le cloud, mais c’est infiniment plus complexe de les organiser à grande échelle et de garantir leur sécurité. Le modèle Hub and Spoke est principalement adopté par les entreprises avec un grand nombre d’applications et un fort besoin de gouvernance.

Le compte Hub est le compte central. Il permet de centraliser les communications (entrantes, sortantes), de les monitorer et de renforcer l’isolation entre les réseaux des différents environnements ou des différentes applications. Il permet aussi de centraliser les politiques de sécurité qui seront ensuite héritées par les comptes Spokes.

Les Spokes contiennent tout ce qu’il faut pour héberger des workloads. Ces comptes sont provisionnés en tenant compte des besoins de vos applications, en héritant des bonnes pratiques et politiques de votre organisation et en étant connectés au Hub pour profiter de la gestion centralisée du réseau. Le niveau d’autonomie des équipes sur les Hub sera à définir en fonction de votre organisation et de vos contraintes de sécurité.

Une infrastructure Hub and Spoke permet en conclusion de garantir un haut niveau de sécurité sur une infrastructure à grande échelle. Implémenter un Hub and Spoke est souvent utilisé pour des grandes organisations, mais il a tout intérêt à être implémenté dans des petites organisations pour avoir des fondations solides et scalables.

SonarQube

SonarQube est outil open source d’analyse permettant d’assurer la qualité et la sécurité de votre code. Il supporte un grand nombre de langages de programmation différents.

La qualité et la sécurité du code applicatif doivent être assurées tout au long du processus de développement, notamment par des outils intégrés à la CI/CD. SonarQube combine une analyse statique et dynamique du code à la recherche de bugs, de code smell et de vulnérabilités afin d’assurer une bonne sécurité, fiabilité et maintenabilité du code.

SonarQube possède un grand nombre de set de règles disponibles (e.g. Top 10 de l’OWASP) sur plus d’une vingtaine de langages de programmation. De plus, vous pouvez ajouter vos propres règles.

Un niveau de criticité est aussi proposé pour chaque résultat, et permet d’avoir un score global d’une analyse divisée en 4 catégories. Il est ainsi possible de définir des standards bloquants sur les pipelines de déploiement, et d’imposer un certain niveau de qualité ou de sécurité du code tout au long du process de développement.

Une console d’administration intuitive est disponible, où sont recensés les différents problèmes rencontrés dans le code. Elle permet d’avoir une vue d’ensemble sur les différents projets scannés.

Attention néanmoins, la console d’administration contient un grand nombre d’informations sensibles et son accès doit être correctement protégé. Le système de gestion des droits RBAC dans Sonarqube est simple mais efficace.

Trial

Checkov

Checkov est un outil d’analyse de code statique pour votre Infrastructure As Code permettant de renforcer et de vérifier l’application des bonnes pratiques, notamment sur la sécurité.

L’automatisation des flux de développements, de déploiement et de gestion de l’infrastructure donne l’opportunité aux équipes sécurité de contrôler plus facilement l’application des bonnes pratiques.

Checkov est un outil open source, gratuit, d'analyse de code statique qui permet de vérifier la conformité de votre Infrastructure as Code (IaC).

Checkov supporte plusieurs backends, tel que :

Terraform, Ansible, Cloudformation, pour la gestion de votre infrastructure
Dockerfile, Helm, Kubernetes pour le déploiement de vos applications et outils
Argo Workflows, Azure Pipelines, BitBucket Pipelines, Circle CI Pipelines, GitHub Actions et GitLab CI workflow pour vos flux de CI/CD
Mais aussi Serverless Framework

L’outil s'intègre aisément dans une pipeline CI/CD, idéalement avant d’appliquer vos changements (ou de les merger dans notre branche principale). Il déchargera une partie de la code review en automatisant le contrôle de sécurité. Vous pourrez à la fois ajouter de nouvelles règles liées à vos contraintes (réglementaires par exemple), tout en désactivant certaines qui ne seraient pas pertinentes par rapport à votre contexte. C’est aussi un très bon outil d’audit de contrôle dans un contexte réglementaire comme ISO 27001, PCIDSS ou encore SOC2.

Comme tout outil d’analyse de code statique avec des jeux de règles par défaut, Checkov nécessitera une période d’ajustement (exclusion) des règles pour l’adapter à vos besoins et éviter les faux positifs. Il faudra aussi prévoir un processus de gouvernance (contrôle, audit, ajustement) pour éviter que les bypass manuels ne prolifèrent dans votre code, le rendant inutile.

Checkov pourrait devenir un outil essentiel pour les équipes de sécurité en automatisant une partie des contrôles. C’est une option intéressante, agnostique, si vous n’avez pas déjà cela dans une suite d’outil sécurité payante.

gVisor

gVisor est une technologie qui permet de sécuriser l’exécution de conteneurs en fournissant une couche d’isolation entre les applications conteneurisées et le système hôte. Simple et efficace, il ne supporte cependant pas tous les appels systèmes Linux.

L’exécution d’applications conteneurisées présente un avantage certain en termes d’opérabilité et de coûts comparé aux machines virtuelles. Néanmoins, le niveau d’isolation d’une VM et d’un conteneur ne sont pas identiques. Une VM possède son propre noyau, alors que les conteneurs partagent le noyau de l’hôte. De nombreuses attaques existent pour s’échapper d’un conteneur : mauvaise configuration, noyau vulnérable, montage dangereux…

gVisor implémente un environnement virtuel qui permet d’exécuter des conteneurs de façon isolée et sécurisée. Il utilise un environnement dit “sandboxé” dans lequel les conteneurs sont exécutés. Cette isolation permet un filtrage des appels systèmes (syscall) effectués par l’application vers le kernel de l’hôte.

Un appel système est une demande faite par un programme à un système d'exploitation pour effectuer une opération spécifique, comme lire ou écrire des données sur le disque. gVisor a la capacité d’intercepter les appels systèmes effectués par les applications conteneurisées. Il agit comme un intermédiaire filtrant entre l’application et le noyau du système d’exploitation. Ainsi, en filtrant les appels dangereux, gVisor permet de renforcer la sécurité de votre environnement.

gVisor agit donc comme une couche d’isolation pour l’exécution de vos conteneurs. Il est dans son fonctionnement similaire à Kata Container que nous avons également inclus dans ce tech radar, mais implémentation n’est pas basée sur la virtualisation. gVisor est plus léger car il n’implémente pas une virtualisation complète mais une simple sandbox de contrôle des syscall. Ceci permet une exécution plus rapide sans nécessiter de mise en place de ressources supplémentaires comme c’est le cas pour la virtualisation.

Par contre, gVisor ne supporte pas encore la totalité des appels systèmes linux pour l’architecture amd64 (la liste est présente dans la documentation). Ainsi, nous vous conseillons de tester chaque application avant de la migrer sur un runtime gVisor.

Nous avons aimé gVisor pour sa facilité de fonctionnement et d’implémentation. gVisor est implémentable en un clic sur GKE. Il n’est cependant pas compatible avec tous les syscalls comme évoqué précédemment, ce qui peut être un frein à son implémentation.

Cilium

Cilium est un plugin réseau open source extrêmement puissant pour Kubernetes qui offre des fonctionnalités avancées de sécurité et d'observabilité, avec une grande facilité d'accès. Actuellement, il est considéré comme la référence du marché en la matière.

Cilium est un projet open source de CNI réseau pour Kubernetes, graduated CNCF depuis octobre 2022. Il possède des fonctionnalités avancées comme le chiffrement transparent du trafic entre les pods, du filtrage réseau avancé, une observabilité accrue du trafic ou la communication multi-cluster.

La grande force de Cilium est que ce CNI est basé eBPF (Extended Berkeley Packet Filter). eBPF est une technologie du noyau Linux qui peut exécuter des programmes isolés dans l'espace noyau. Elle est utilisée pour étendre de manière sûre et efficace les capacités du noyau sans avoir à modifier le code source de celui-ci ou à charger des modules kernel complémentaires.

Il en résulte plusieurs bénéfices : les performances sont nettement plus élevées comparées à iptables qui est utilisé par kube-proxy. Grâce à ePBF, Cilium ne nécessite pas d’installation de module kernel et peut donc s’exécuter sans prérequis sur n’importe quel serveur qui possède un noyau linux suffisamment récent (kernel 4.19).

Cilium offre de nombreuses fonctionnalités indispensables lorsque votre cluster Kubernetes devient le point central et critique de votre infrastructure, en particulier en matière de sécurité et d'observabilité. Par exemple, il est possible de réaliser un filtrage réseau en couche 7 grâce à la CRD CiliumNetworkPolicy, ou encore d'obtenir une visibilité approfondie sur le trafic de couche 7 en utilisant les métriques exposées par Cilium.

Cilium permet également de chiffrer le trafic entre les pods sans difficulté. Pour tous ceux qui utilisent un Service Mesh uniquement pour avoir du chiffrement mTLS, Cilium apporte une solution plus simple.

Cilium est devenu aujourd’hui le CNI par excellence dans Kubernetes, à tel point qu’il est désormais utilisé par Datadog ou dans les dataplane v2 de GKE (Google Kubernetes Engine). Cependant, cette technologie reste complexe à utiliser et nécessite de bonnes compétences techniques au sein de vos équipes.

Falco Security

Falco est un outil de détection d’intrusion pour Kubernetes. Il repose sur l’analyse dynamique des conteneurs pour lever des alertes de sécurité en cas de comportement suspect.

Falco est un outil open source développé par Sysdig qui fait partie de la CNCF depuis 2018. Il permet de détecter les comportements suspects dans les environnements conteneurisés. Il s’intègre donc parfaitement à Kubernetes.

Falco utilise des règles d’analyse dynamique et monitore les syscall. Un avantage majeur de Falco par rapport à d’autres HIDS (Host-based intrusion detection systems) est la possibilité d’écouter les événements de l’API Server. En cas de détection de menace potentielle, Falco envoie une alerte fournissant les informations détaillées sur l'événement qui l’a déclenché. Il peut notamment détecter les mutations de binaires, les élévations de privilèges, l’utilisation suspecte des services SSH, etc.

Falco est hautement personnalisable, permettant aux utilisateurs de créer leurs propres règles et alertes pour répondre à leurs besoins de sécurité spécifiques. Il peut être facilement intégré à d'autres outils et services de sécurité pour fournir une solution de sécurité complète.

Falco est un élément essentiel pour assurer la sécurité d'un cluster Kubernetes. Nous recommandons sa mise en place dans la mesure où vos équipes ont le temps de traiter et de configurer les alertes. Comme tous les outils de détection d’intrusion, la grande difficulté réside dans le fine-tuning de la configuration pour produire le bon volume d’alerte. Il convient d’avoir simultanément des alertes qualitatives sur les règles les plus critiques, et des alertes quantitatives pour détecter des attaques plus bruyantes.

Il est à noter également que des problèmes persistent quant à l’interconnexion de Falco avec le kernel : par exemple, dans un cluster EKS, les modules kernel Falco sont publiés en général 2 semaines après la publication d’une nouvelle AMI par AWS, ce qui retarde la mise à jour des nodes.

Nous recommandons donc cet outil dans la mesure où votre équipe possède la bande passante nécessaire pour traiter les alertes au quotidien, autrement vous alimenterez juste “l'alert fatigue”.

Linkerd

Linkerd est une technologie de Service Mesh très prometteuse qui permet de mettre en place simplement le chiffrement et l’autorisation des communications dans les clusters Kubernetes.

Linkerd est un Service Mesh Kubernetes “graduated” par la CNCF depuis Juillet 2021. La promesse de Linkerd est d’offrir à la communauté un Service Mesh extrêmement simple et rapide.

Un Service Mesh est un composant d’infrastructure qui facilite la communication entre les microservices. Il permet de nombreuses fonctionnalités avancées, notamment le chiffrement mTLS des communications inter-service, une observabilité forte, de l’injection de fautes, etc…

Linkerd propose une architecture extrêmement simple comparé à d’autres services Mesh comme Istio. La raison principale est que le nombre de fonctionnalités de Linkerd est volontairement limité, est peut s’étendre grâce plusieurs plugins : par exemple le tracing grâce à Jaeger, les canary releases grâce à Flagger. Certaines fonctionnalités manquent encore à l’appel pour Linkerd, notamment le JWT header based routing.

Les performances de Linkerd sont très bonnes grâce à son proxy minimaliste écrit en Rust. Les différents benchmarks disponibles sur internet indiquent une consommation mémoire et CPU de l’ordre de 10% de la consommation d’Istio.

Enfin, un point très important concernant le coût de mise en place de ce service Mesh, est que Linkerd ne contient pas d’ingress controller. Cela vous permet de l’ajouter lorsque le besoin se fait sentir, sans être contraint de changer les ingressClass de tous les services.

Nous recommandons d’essayer Linkerd qui a l’avantage d’être beaucoup plus simple à installer et à maintenir que ses concurrents les plus connus. Ce service Mesh offre la plupart des fonctionnalités attendues, notamment via le système de plugin.

Assess

BuildKit

Buildkit est un moteur de build d’images de conteneurs qui fonctionne avec un faible niveau de privilèges tout en ayant une couverture complète des instructions possibles pour un Dockerfile.

Le build d’images de conteneurs est aujourd’hui une problématique centrale de la CI/CD des applications conteneurisées. Mais c’est aussi souvent une opération coûteuse qui peut impliquer la compilation de binaires, et donc une forte charge RAM et CPU.

Ainsi, afin de s’adapter à une charge forte mais très variable en fonction des développements en cours, il est confortable de réaliser ces builds dans des clusters Kubernetes souvent partagés avec d’autres outils.

Pour assurer la sécurité de ces clusters, il est important que les outils qu’ils hébergent, et donc notamment les outils de build d’images de conteneurs, soient exécutés sans privilèges.

Or, historiquement, les builds d’images de conteneurs nécessitent un processus privilégié. Par conséquent, un développeur qui a le droit de lancer une pipeline de build pourrait prendre le contrôle de tous les conteneurs qui tournent sur le même node.

Heureusement, de nombreuses évolutions du noyau Linux réalisées ces dernières années ont permis de voir apparaître la possibilité de lancer des conteneurs quasiment sans privilèges. Et les moteurs de build se sont adaptés en conséquence. Ainsi des outils comme Buildkit, Buildah, ou encore Kaniko, prennent désormais en compte chacun à leur manière ces nouvelles possibilités.

Parmis ces outils nous favorisons aujourd’hui Buildkit sur nos projets car il semble être le seul parmi eux à vraiment gérer toutes les instructions possibles d’un Dockerfile. Par ailleurs, il est bâti sur un modèle client - serveur qui permet de profiter d’un cache commun et d’offrir de belles performances et donc de diminuer le temps nécessaire au build.

Un élément de sécurité qui accélère les développeurs, c’est possible !

Zero-trust architecture

Le Zero Trust est un modèle d’architecture qui ne base plus la sécurité d’un système informatique uniquement sur la défense de son périmètre, mais sur l’absence totale de confiance entre les parties. C’est un modèle extrêmement sécurisé et difficile à mettre en place, dans lequel chaque connexion doit être autorisée.

Le principe de base de l'architecture Zero Trust est de ne faire confiance à personne ou à aucun périphérique par défaut, même s'ils se trouvent à l'intérieur du réseau, et de vérifier en permanence l'identité et les autorisations de tout ce qui tente d'accéder aux ressources de l'entreprise. Aucune confiance implicite n’est accordée à un utilisateur ou à un service en fonction de l’endroit d’où provient la requête.

Attention, Zero trust ne signifie pas qu’il faut arrêter de restreindre l’accès aux ressources via du filtrage réseau ! Le modèle Zero Trust part simplement du principe que le réseau sera nécessairement compromis, ou que le périmètre sera défaillant, ce qui contraint les utilisateurs et les appareils à prouver leur légitimité.

Le Zero Trust est particulièrement adapté aux infrastructures Cloud, qui possèdent souvent une typologie réseau complexe, composées de plusieurs réseaux virtuels interconnectés, exposés sur internet, où la notion même de périmètre finit par perdre son sens, notamment dans les infrastructures serverless…

Cette approche est séduisante, mais complexe à mettre en place. Chaque utilisateur et chaque application doit utiliser un système d’authentification centralisé (par exemple, MFA pour les utilisateurs, certificats SSL pour les serveurs). Généralement, un broker d’identité fait le lien entre les terminaux externes (postes utilisateurs) et les services hébergés dans l’infrastructure (e.g Boundary). À noter que des services comme CloudFlare Zerotrust permettent de grandement simplifier la mise en place de ce type d’architecture.

Le concept de Zero-Trust est donc particulièrement adapté pour les entreprises ayant un besoin accru de protection de leurs données, mais nécessite un gros investissement de mise en place.

Boundary

Boundary est un outil voué à remplacer les systèmes existants qui permettent d'accéder à vos réseaux internes.

Boundary est un outil développé par Hashicorp et open sourcé en 2020. Il a pour vocation de remplacer vos solutions de Bastion, voire de VPN, en améliorant leur gestion, leur sécurité ainsi que leur expérience utilisateur.

Boundary permet d'obtenir la même expérience utilisateur que la feature de "port-forwarding" de Kubernetes mais sur l'ensemble de votre infrastructure (e.g. BDD, VMs, WebServices etc.). Il s’exécute sans pour autant oublier l’auditabilité et la ségrégation d’accès nécessaires pour ce genre d’outils via des audits logs, la possibilité de révoquer des sessions en cours et également toute une logique RBAC de gestion d’accès basée sur des utilisateurs ou des groupes.

Il se décompose en 2 parties :

Un contrôleur central qui contiendra la configuration des différentes cibles auxquelles vos employés auraient besoin d'accéder mais également toute la gestion de droits.
Des workers qui auront accès à vos différents réseaux internes et qui servent de passerelle

La grande force de Boundary réside dans sa simplicité d'installation et d'opérabilité. Sa configuration peut-être complexe mais son intégration avec Terraform lui permet d'être automatisée de la même façon que le reste de la configuration de votre infrastructure.

Boundary est encore jeune et nous ne sommes pas encore pleinement satisfaits de l'expérience utilisateur qu'il propose. Le CLI nécessite notamment que l’utilisateur connaisse des identifiants de ressources Boundary qui ne sont pas intuitifs. Nous sommes tout de même confiants pour la suite et pensons que le projet deviendra une référence dans ce type d'outils.

Nous le plaçons donc en “Assess” et continuons également d'évaluer ses principaux concurrents (e.g. Teleport).

Kata containers

Kata Containers est une technologie de virtualisation pour la mise en place de conteneurs. Il fournit une isolation forte pour les applications conteneurisées, mais peut être complexe à installer.

L’exécution d’applications conteneurisées présente un avantage certain en termes d’opérabilité et de coûts par rapport aux machines virtuelles. Néanmoins, le niveau d’isolation d’une VM et d’un conteneur ne sont pas identiques. Une VM possède son propre noyau, alors que les conteneurs partagent le noyau de l’hôte. De nombreuses attaques existent pour s’échapper d’un conteneur : mauvaise configuration, noyau vulnérable, montage dangereux…

Kata Containers utilise des machines virtuelles “lightweight” pour fournir une isolation matérielle des conteneurs, cela permet ainsi de protéger les systèmes hôtes des vulnérabilités potentielles apportées par les conteneurs. Chaque conteneur fonctionne comme s'il était exécuté sur une VM distincte, tout en bénéficiant des avantages de la virtualisation légère, tels que la rapidité de démarrage et la faible utilisation de ressources.

Cependant, Kata est uniquement un runtime, c'est-à-dire qu’elle se limite à créer et faire fonctionner le conteneur, là où Docker fournit des fonctionnalités supplémentaires, telles que la gestion des images, le stockage des données, la mise en réseau ou l'orchestration.

Tout comme gVisor, Kata Containers intercepte les appels systèmes effectués par les applications conteneurisées. Contrairement à lui, il utilise une approche de virtualisation légère basée sur des hyperviseurs pour fournir cette isolation. C’est ce qui lui permet de garantir une sécurité supplémentaire en empêchant les applications de s'exécuter directement sur l'hôte. Néanmoins, cela nécessite des ressources supplémentaires et un démarrage plus lent. D’un autre côté, les benchmarks montrent que les conteneurs s’exécutent plus rapidement sur Kata Containers que sur gVisor.

Kata Containers, contrairement à gVisor qui a une implémentation “built-in” dans GKE, n’est implémenté nativement chez aucun Cloud Provider (GCP, Azure, AWS). La mise en place de l’outil est ainsi plus difficile que celle de gVisor, nécessitant la modification de configuration des nodes des clusters managés.

Pour résumer : dans nos cas d’usages, nous préférons l’utilisation de gVisor pour sa simplicité d’implémentation. Cependant, Kata Containers s’avère plus “isolant” que gVisor, possède une meilleure compatibilité avec les différents syscalls et se révèle plus rapide dans l’exécution de ses conteneurs, bien que nécessitant davantage de ressources.

Hold

Istio

Istio est un outil complexe permettant un contrôle extrêmement fin des différentes communications entre vos applications

Istio est ce qu'on appelle communément un "Service Mesh". Il permet via le même pattern utilisé par Kubernetes de contrôler l'entièreté des communications à l'intérieur de votre cluster, mais également toutes les communications vers l'extérieur.

Il est aujourd'hui incontournable et tout le monde connaît son existence, mais il est cependant très complexe dans sa mise en place et son opérabilité, ce qui rebute beaucoup de personnes quant à son utilisation. Nous avons déjà essuyé beaucoup de plâtres dans nos projets à cause de lui, notamment le passage à la version 1.6 qui a marqué de nombreux utilisateurs.

Nous avons pu également observer chez nombre de nos clients que la feature principale qui poussait à l'utilisation d'un Service Mesh était le mTLS (mutual TLS), notamment afin de répondre à des exigences de sécurité. Cette feature n'étant pas seulement supportée par Istio mais également par ses alternatives plus simples (e.g Linkerd, Consul). Nous favorisons l'installation de ces outils plutôt qu'Istio.

Une autre des features différenciantes qui nous a déjà amené à utiliser Istio est la capacité de contrôle sur les flux de sortie, notamment via l'utilisation des Egress Gateway. Dans les environnements qui nécessitent un niveau de sécurité plus important, cette feature peut faire la différence.

Istio doit rester un outil qui nécessite une analyse importante avant d'être adopté afin de ne pas rajouter un coût de maintenance important sur des équipes qui sont parfois déjà surchargées.

Secure