Architecture

En raison de cette infrastructure partagée, le CNI est le même que celui configuré dans le cluster hôte. Il en va de même pour le stockage disponible où les classes de stockage et les volumes sont ceux du cluster hôte.

Pour fournir l’isolement nécessaire, K3k utilise des politiques réseau.

En mode partagé, K3k utilise les 'ResourceQuotas' et 'LimitRanges' de Kubernetes pour gérer le partage des ressources et faire respecter les limites. Puisque toutes les charges de travail des clusters virtuels s’exécutent dans le même espace de noms sur le cluster hôte, les ResourceQuotas sont appliquées à cet espace de noms pour limiter les ressources totales consommées par un cluster virtuel. Les LimitRanges sont utilisés pour définir des demandes et des limites de ressources par défaut pour les pods, garantissant que les charges de travail disposent d’allocations de ressources raisonnables même si elles ne les spécifient pas explicitement.

Chaque pod dans un cluster virtuel se voit attribuer un nom unique qui incorpore le nom du pod, l’espace de noms et le nom du cluster. Cela empêche les collisions de noms dans l’espace de noms partagé du cluster hôte.

Il est important de comprendre que les ResourceQuotas sont appliquées au niveau de l’espace de noms. Cela signifie que tous les pods au sein d’un cluster virtuel partagent le même quota. Bien que cela fournisse des limites globales pour le cluster virtuel, cela signifie également que l’allocation des ressources est dynamique. Si une charge de travail n’utilise pas l’intégralité de son allocation de ressources, d’autres charges de travail au sein du même cluster virtuel peuvent utiliser ces ressources, même si elles appartiennent à différents déploiements ou services.

Ce partage dynamique peut être à la fois un avantage et un défi. Il permet une utilisation efficace des ressources, mais cela peut également entraîner des performances imprévisibles si les charges de travail ont des demandes de ressources variées. De plus, cette approche rend difficile la garantie d’une isolation stricte des ressources entre les charges de travail au sein du même cluster virtuel.

L’isolation entre les clusters virtuels en mode partagé repose fortement sur les politiques réseau de Kubernetes. Les politiques réseau définissent des règles qui contrôlent le trafic réseau autorisé vers et depuis les pods. K3k configure les politiques réseau pour s’assurer que les pods d’un cluster virtuel ne peuvent pas communiquer avec les pods d’autres clusters virtuels ou avec les pods du cluster hôte lui-même, fournissant une base solide pour l’isolation réseau.

Bien que les politiques réseau offrent des capacités d’isolation robustes, il est important de comprendre leurs caractéristiques :

K3k utilise également l’admission de sécurité des pods Kubernetes (PSA) pour imposer des politiques de sécurité au sein des clusters virtuels en fonction des normes de sécurité des pods (PSS). Les PSS définissent différents niveaux de sécurité pour les pods, restreignant les actions que les pods peuvent effectuer. En configurant PSA pour imposer un niveau PSS spécifique (par exemple, baseline ou restricted) pour un cluster virtuel, K3k s’assure que les pods respectent les meilleures pratiques de sécurité établies et les empêche d’utiliser des fonctionnalités privilégiées ou d’effectuer des opérations potentiellement dangereuses.

Les aspects clés de l’intégration de PSA incluent :

L’architecture en mode partagé est conçue avec la sécurité à l’esprit. K3k emploie plusieurs couches de contrôles de sécurité, y compris les politiques réseau et PSA, pour protéger les clusters virtuels et le cluster hôte. Bien que le modèle de namespace partagé nécessite une configuration et une gestion minutieuses, ces contrôles fournissent une base de sécurité robuste pour exécuter des charges de travail dans un environnement multi-locataire. K3k évalue et améliore en continu ses mécanismes de sécurité pour faire face aux menaces évolutives et garantir le plus haut niveau de protection pour ses utilisateurs.

Les clusters virtuels en mode virtual ont chacun leur propre configuration réseau indépendante gérée par leurs serveurs K3s respectifs. Chaque cluster virtuel exécute son propre plugin CNI, configuré au sein de son serveur K3s, fournissant une isolation réseau complète par rapport aux autres clusters virtuels et au cluster hôte. Bien que les réseaux des clusters virtuels fonctionnent finalement sur l’infrastructure réseau du cluster hôte, la configuration réseau et la gestion du trafic sont entièrement séparées.

Le partage des ressources en mode virtual est géré en appliquant des limites de ressources aux pods qui composent le cluster virtuel (à la fois le pod serveur K3s et les pods agents K3s). Chaque pod se voit attribuer une quantité spécifique d’UC, de mémoire et d’autres ressources. Les charges de travail s’exécutant dans le cluster virtuel utilisent ensuite ces ressources allouées. Cela signifie que le cluster virtuel dans son ensemble dispose d’un pool de ressources défini, déterminé par les limites imposées à ses pods constitutifs.

Cette approche offre un moyen clair et direct de contrôler les ressources disponibles pour chaque cluster virtuel. Cependant, elle nécessite une planification minutieuse des ressources pour garantir que chaque cluster virtuel dispose d’une capacité suffisante pour ses charges de travail.

Le mode virtual offre une forte isolation grâce aux clusters K3s dédiés déployés pour chaque cluster virtuel. Parce que chaque cluster virtuel exécute son propre plan de contrôle et ses nœuds de travail séparés, les charges de travail sont effectivement isolées les unes des autres et du cluster hôte. Cette architecture minimise le risque qu’un cluster virtuel n’impacte d’autres clusters ou le cluster hôte.

La sécurité en mode virtual bénéficie de l’isolation inhérente fournie par les clusters K3s séparés. Cependant, les meilleures pratiques de sécurité Kubernetes standard s’appliquent toujours, et K3k met l’accent sur une approche de sécurité en couches. Bien que les pods serveur K3s fonctionnent souvent avec des privilèges élevés (en raison de la nature de leur fonction, nécessitant un accès aux ressources système), K3k recommande de minimiser ces privilèges autant que possible et de respecter le principe du moindre privilège. Cela peut être réalisé en configurant soigneusement les capacités nécessaires au lieu de s’appuyer sur le mode privileged complet. Des informations supplémentaires sur les meilleures pratiques de sécurité K3s peuvent être trouvées dans la documentation officielle de K3s : https://docs.k3s.io/security (Ce lien fournit des conseils de sécurité généraux, y compris des discussions sur les capacités et d’autres sujets pertinents).

Actuellement, la sécurité en mode virtuel présente un risque d’escalade de privilèges, car les pods serveur fonctionnent avec des privilèges élevés en raison de la nature de leur fonction, nécessitant un accès aux ressources système.