Comment sécuriser les échanges dans un cluster Kubernetes ?

Article

Avec les orchestrateurs de conteneurs, associés à une transformation globale vers des architectures Microservices, il est nécessaire de repenser les mesures de sécurité existantes au sein de nos systèmes d’information.   En effet, les échanges inter-applicatifs se démultiplient alors que les équipements de filtrage et de contrôle d’accès deviennent inopérants.      

Comment alors, garantir l’intégrité des échanges au sein d’un orchestrateur comme Kubernetes via des pratiques de sécurisation adaptées aux architectures Microservices, et compatibles avec l’industrialisation DevOps ?

Les mécanismes de sécurité natifs de Kubernetes

Kubernetes permet de déployer et de superviser des conteneurs, tout en assurant leurs échanges internes au cluster. Kubernetes intègre déjà nativement quelques mécanismes pour sécuriser les échanges A2A1,  il crée ainsi son propre sous-réseau uniquement pour les conteneurs présents sur un cluster. Il n’est donc pas nécessaire d’exposer ceux-ci vers l’extérieur. Il est aussi possible de mettre en place des ClusterIP locaux afin d’ouvrir certains Pods2 du cluster. Afin de limiter l’interaction entre ces Pods, Kubernetes intègre des Network Policies3. Celles-ci fonctionnent comme des pares-feux et empêchent les Pods définis avec certains tags d’échanger avec des conteneurs possédant d’autres tags ou s’exécutant dans d’autres namespaces4. Cependant, ces fonctionnalités s’avèrent insuffisantes et ne protègent pas contre plusieurs types d’attaques, Kubernetes n’intégrant pas une sécurisation accrue au niveau des échanges entre Pods.

Quelles sont les limites de sécurité de Kubernetes ?

Kubernetes ne dispose pas nativement de mécanismes suffisants pour sécuriser les échanges A2A. Certes ces échanges se font sur un réseau interne, mais tous les échanges sont en clair : le pirate lambda qui parvient à capturer les transactions réseau pourra alors espionner l’ensemble des données échangées entre les applications. De plus, les Network Policies sont de simples règles de pare-feu. Elles peuvent facilement être contournées, puisque ces dernières se limitent à l’usage des tags au niveau des Pods Kubernetes. Imaginons le scénario suivant : il suffirait de déployer un Pod malveillant avec le tag adéquat, pour qu’un pirate ait accès à l’ensemble des ressources du cluster Kubernetes. Enfin, lorsqu’un applicatif est en dehors du cluster, il devient nécessaire de mettre en place des mécanismes de sécurité au niveau applicatif, ou externes (pare-feu applicatif, sonde, proxy…), afin d’assurer la sécurité de ces échanges externes, non garantis par Kubernetes. Il existe donc plusieurs vecteurs d’attaque sur ce type d’orchestrateur. Nexworld préconise l’usage d’outils additionnels spécialisés dans la sécurisation de ces échanges

Comment les outils de Services Mesh permettent-ils d’assurer la sécurité dans les clusters ?

Les outils assurant la sécurisation des échanges entre Pods offrent généralement une fonctionnalité assurant également l’exploration des services (le service mesh5). Le fonctionnement de ces outils consiste généralement à ajouter un sidecar6 aux applications afin de visualiser l’ensemble des services du ou des clusters. Un sidecar étant un proxy conteneurisé pour un Pod. Ce sidecar échange en local au sein du Pod applicatif et se positionne en proxy afin d’être responsable de la sécurisation de tous les échanges avec ce Pod. Ces outils chiffrent l’ensemble des connexions en mutual TLS (ou mTLS). Chaque sidecar possède donc un certificat émis par une autorité de certification. Cette autorité peut être portée par l’outil de service mesh, mais peut aussi être déléguée à une autorité de certification externe. Par ailleurs, le service mesh ne se limite pas à la sécurisation des échanges mais joue également un rôle d’inventaire de service. Ce dernier permet de détecter d’éventuels Pods intrus, ou de contrôler le fonctionnement et les échanges entre ces Pods. Le CNCF (Cloud Native Computing Foundation), la fondation qui standardise les technologies autour du cloud, propose une liste d’outils à l’état de l’art dont voici une liste non exhaustive :  
  • LinkerD, la seule solution Incubating de la CNCF, c’est à dire en cours de standardisation
  • Istio, la solution la plus utilisée actuellement, elle permet un meilleur contrôle de sa politique de sécurité.
  • Consul, solution Hashicorp compatible avec des services en dehors d’un cluster Kubernetes, qui fonctionne de paire avec les autres solutions Hashicorp telles que Terraform et Vault.

Istio, l’atout sécurité qui a manqué à l’écosystème Kubernetes

Istio est l’un des outils de service mesh open source les plus matures aujourd’hui. En effet, certains éditeurs se basent sur Istio pour développer leur propre solution propriétaire (par exemple Google avec sa solution Anthos Service-Mesh). Istio permet de visualiser l’ensemble des services, tout en assurant la sécurité des échanges entre les Pods. La grande force d’Istio est sa personnalisation. Il est possible de mettre en place des règles de sécurisation (forcer le mTLS par exemple, ou encore faire du TLS simple sur certains Pods) permettant de coller au plus près de la politique de sécurité. Afin de faciliter cette mise en place, Istio intègre son propre gestionnaire de certificats et les distribuer automatiquement aux Pods concernés. Istio intègre aussi des fonctions supplémentaires sur les Ingress, les reverse-proxy servant d’entrée au cluster. Il est possible d’y appliquer des règles de sécurités spécifiques, tout en mettant en place un filtrage plus restrictif que les simples Network Policies de Kubernetes. Enfin la dernière grande force d’Istio est son utilisation en multi-cluster. En effet, tous ses services peuvent être utilisés sur plusieurs clusters, permettant ainsi de disposer d’un service-mesh sécurisé entre différents clusters Kubernetes.
En synthèse, les échanges entre micro-services constituent un enjeu majeur dans la sécurisation des systèmes d’informations modernes. Kubernetes n’intégrant pas de mécanismes suffisants pour assurer une sécurité optimale, il est nécessaire de recourir des outils spécifiques. Istio répond à ce besoin en étant l’un des plus complets à ce jour. Il permet avant tout, de par sa personnalisation, de créer une politique de sécurité au plus près des besoins.
En synthèse, les échanges entre micro services constituent un enjeu majeur dans la sécurisation des systèmes d’informations modernes. Kubernetes n’intégrant pas de mécanismes suffisants pour assurer une sécurité optimale, il est nécessaire de recourir à une solution externe. Istio répond à ce besoin en étant l’un des plus complets à ce jour. Il permet avant tout, de par sa personnalisation, de créer une politique de sécurité au plus près des besoins.

Glossaire:

1. A2A : Acronyme d’Application to Application. A2A caractérise une communication se déroulant entre deux applications.

2. Pods : Les Pods sont les plus petites unités informatiques déployables qui peuvent être créées et gérées dans Kubernetes.

3. Network Policies (En français, les règles de réseau) : Les politiques réseau sont des ressources Kubernetes qui contrôlent le trafic entre les Pods et/ou les points d’extrémité du réseau. Elles utilisent des étiquettes pour sélectionner les Pods et spécifient le trafic qui est dirigé vers ces Pods à l’aide de règles. Les règles de réseaux permettent de limiter les connexions entre les Pods, réduisant ainsi les risque de sécurité.

4. Namespace : Un namespace est un moyen de séparer logiquement un cluster physique en plusieurs clusters virtuels.

5. Service Mesh : Un Service Mesh est un moyen de contrôler la façon dont différents éléments d’une application partagent des données les uns avec les autres. C’est une couche d’infrastructure dédiée, créée directement dans l’application. Pour en savoir plus sur les services mesh, lire Service Mesh, pour une intégration optimale des Microservices.

6. Sidecar : Le sidecar est placé en front de chaque Microservice et s’impose comme un point de passage obligé pour l’ensemble des appels entrants et sortants. (Pour en savoir plus sur les sidecars, lire Le sidecar : la simplification des Services Mesh)

Auteur

  • onepoint

    beyond the obvious

Ces contenus peuvent vous intéresser…