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.