lundi, 23 mai 2022

Sécuriser la mise en réseau Azure Kubernetes avec Calico

L’un des aspects intéressants du passage à une méthode de travail descendante et centrée sur les applications consiste à repenser notre façon de travailler en réseau. Tout comme le modèle d’application a d’abord fait abstraction de l’infrastructure physique avec la virtualisation et utilise maintenant Kubernetes et des outils d’orchestration similaires pour faire abstraction des machines virtuelles sous-jacentes, la mise en réseau s’éloigne des piles de protocoles routés à usage général vers une mise en réseau pilotée par logiciel qui utilise des protocoles communs pour mettre en œuvre des fonctions réseau spécifiques à l’application.

Nous pouvons voir comment la mise en réseau évolue avec l’introduction par Windows Server 2022 de SMB sur QUIC comme alternative aux VPN à usage général pour le partage de fichiers entre les systèmes Azure Stack sur site et le cloud public Azure. De même, dans Kubernetes, nous voyons des technologies telles que le maillage de services fournir un modèle de réseau défini par l’application qui fournit des maillages de réseau avec votre application distribuée dans le cadre de la définition de l’application plutôt que comme un réseau utilisé par une application.

Une nouvelle couche de mise en réseau : la mise en réseau définie par l’application

Cette mise en réseau pilotée par les applications est une extension logique d’une grande partie du modèle de réseau défini par logiciel qui sous-tend le cloud public. Cependant, au lieu d’exiger une compréhension approfondie de la mise en réseau et, plus important encore, du matériel réseau, il s’agit de passer à une approche de niveau supérieur où un réseau est automatiquement déployé en utilisant les intentions de la politique et des règles. L’abandon du virtuel et du physique est essentiel lorsque nous travaillons avec des applications à auto-orchestration dynamique qui évoluent à la demande, avec des instances dans plusieurs régions et zones géographiques faisant toutes partie de la même application.

La mise en réseau pilotée par les applications n’en est qu’à ses balbutiements, mais nous voyons apparaître des outils dans Azure dans le cadre de sa mise en œuvre de Kubernetes. Une option est l’Open Service Mesh, bien sûr, mais il existe un autre ensemble d’outils qui aide à gérer la sécurité réseau de nos applications Kubernetes : Politique réseau. Cela permet de gérer la connectivité entre les différents composants d’une application Kubernetes, en gérant le flux de trafic entre les pods.

Politiques réseau dans Azure Kubernetes Service

AKS (Azure Kubernetes Service) offre une prise en charge de la stratégie réseau via deux voies : son propre outil natif ou le Calico développé par la communauté. Cette deuxième option est peut-être la plus intéressante, car elle vous offre un outil inter-cloud qui peut fonctionner non seulement avec AKS, mais également avec votre propre Kubernetes sur site, Open Shift de Red Hat et de nombreuses autres implémentations Kubernetes.

Calico est géré par la société de sécurité et de gestion Kubernetes Tigera. Il s’agit d’une implémentation open source de la spécification de politique de réseau Kubernetes, qui gère la connectivité entre les charges de travail et appliquer des politiques de sécurité sur ces connexions, en ajoutant ses propres extensions aux fonctions de base de Kubernetes. Il est conçu pour fonctionner avec différents plans de données, d’eBPF sur Linux à Windows Host Networking. Cette approche la rend idéale pour Azure, qui offre une prise en charge de Kubernetes pour les conteneurs Linux et Windows.

Configuration de la politique réseau dans AKS est important. Par défaut, tous les pods peuvent envoyer des données n’importe où. Bien que cela ne soit pas intrinsèquement dangereux, cela ouvre votre cluster à la possibilité d’un compromis. Les pods contenant des services back-end sont ouverts au monde extérieur, permettant à quiconque d’accéder à vos services. La mise en œuvre d’une politique de réseau vous permet de vous assurer que ces services principaux ne sont accessibles que par les systèmes frontaux, ce qui réduit les risques en contrôlant le trafic.

Qu’elles utilisent le service natif ou Calico, les règles réseau AKS sont des documents YAML qui définissent les règles utilisées pour acheminer le trafic entre les pods. Vous pouvez intégrer ces stratégies au manifeste global de votre application, en définissant votre réseau avec la définition de votre application. Cela permet au réseau d’évoluer avec l’application, en ajoutant ou en supprimant des pods au fur et à mesure qu’AKS répond aux changements de charge (ou si vous l’utilisez avec KEDA [Kubernetes-based Event-Driven Autoscaling], lorsque votre application répond aux événements).< /p>

Utiliser Calico dans le service Azure Kubernetes

Le choix d’un outil de politique réseau doit être effectué lors de la création du cluster ; vous ne pouvez pas changer l’outil que vous utilisez une fois qu’il a été déployé. Il existe des différences entre l’implémentation native AKS et sa prise en charge Calico. Les deux implémentent la spécification Kubernetes et s’exécutent sur des clusters Linux AKS, mais seul Calico prend en charge les conteneurs Windows. Il est important de noter que bien que Calico fonctionne dans AKS, il n’y a pas de support Azure officiel pour Calico au-delà des options communautaires existantes.

Commencer avec Calico dans AKS est relativement simple. Tout d’abord, créez un cluster AKS et ajoutez le Plug-in Azure Container Networking à votre cluster. Cela peut héberger soit la stratégie réseau AKS, soit Calico. Ensuite, configurez votre réseau virtuel avec tous les sous-réseaux que vous prévoyez d’utiliser. Une fois que vous avez cela en place, tout ce que vous avez à faire est d’utiliser la ligne de commande Azure pour créer un cluster AKS, en définissant votre politique réseau sur « calico » plutôt que sur « azure ». Cela active la prise en charge de Calico sur les pools de nœuds Linux et Windows. Si vous utilisez Windows, assurez-vous d’enregistrer la prise en charge de Calico à l’aide de l’indicateur de fonctionnalité EnableAKSWindowsCalico d’Azure CLI.

L’équipe Calico recommande d’installer l’outil de gestion calicoctl dans votre cluster. Il existe différentes options d’installation : exécuter des fichiers binaires sous Windows ou Linux ou ajouter un pod Kubernetes à votre cluster. Cette dernière option est probablement la meilleure pour travailler avec AKS, car vous pouvez ensuite mélanger et faire correspondre les pods Windows et Linux dans votre cluster et gérer les deux à partir du même environnement Kubernetes.

Créer et déployer des règles réseau Calico

Vous allez créer des règles réseau Calico à l’aide de YAML< /a>, définissant des politiques pour les pods avec des rôles spécifiques. Ces rôles sont appliqués en tant qu’étiquettes de pod lors de la création du pod, et vos règles auront besoin d’un sélecteur pour attacher votre stratégie aux pods qui correspondent à vos étiquettes d’application et de rôle. Une fois que vous avez créé une stratégie, utilisez kubectl pour l’appliquer à votre cluster.

Les règles sont assez faciles à définir. Vous pouvez définir des règles d’entrée pour des pods spécifiques afin, par exemple, de ne recevoir que le trafic d’un autre ensemble de pods correspondant à un autre modèle de sélecteur. De cette façon, vous pouvez vous assurer que le back-end de votre application, par exemple, ne reçoit que le trafic de votre front-end et que votre service de données ne fonctionne que lorsqu’il est adressé par votre back-end. L’ensemble simple de règles d’entrée qui en résulte garantit l’isolation entre les niveaux d’application dans le cadre de la définition de votre application. D’autres options vous permettent de définir des règles pour les espaces de noms ainsi que les rôles, garantissant la séparation entre les pods de production et de test.

Calico vous offre un contrôle précis sur la politique de réseau de votre application. Vous pouvez gérer des ports, des points de terminaison d’application spécifiques, des protocoles et même des versions IP. Vos politiques peuvent être appliquées à un espace de noms spécifique ou globalement sur votre instance Kubernetes. Des règles sont définies pour l’entrée et la sortie, vous permettant de contrôler le flux de trafic entrant et sortant de vos pods, avec des politiques refusant tout trafic en dehors de ce qui est spécifiquement autorisé. Avec Calico, il y a suffisamment de flexibilité pour créer rapidement des modèles de sécurité réseau complexes avec une poignée de fichiers YAML simples. Créez simplement le YAML dont vous avez besoin et utilisez calicoctl pour appliquer vos règles.

La mise en réseau pilotée par les applications est un concept important qui permet aux équipes de développement d’applications de contrôler la manière dont leur code interagit avec la structure réseau sous-jacente. Comme le stockage et, grâce à des outils comme Kubernetes, le calcul, la capacité de traiter le réseau comme une structure qui peut être simplement contrôlée au niveau de la connexion est importante. Les équipes de mise en réseau n’ont plus à configurer les réseaux d’applications ; tout ce qu’ils ont à faire est d’aider à définir les réseaux virtuels, puis de laisser les politiques d’application à l’application.

Si nous voulons créer des applications flexibles et modernes, nous devons tirer parti d’outils tels que Calico, permettant à notre réseau d’être aussi portable que notre code et aussi flexible et évolutif. Il s’agit peut-être d’un changement dans notre façon de penser les réseaux, mais il s’agit d’un changement essentiel pour prendre en charge les infrastructures d’applications modernes.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici