Édition

Partage via

Sécuriser l’accès réseau à Kubernetes

Azure Bastion
Azure DNS
Azure Kubernetes Service (AKS)
Azure Private Link
Réseau virtuel Azure

Cet article compare les modes d’utilisation d’un réseau AKS (Azure Kubernetes Service) et Amazon EKS (Amazon Elastic Kubernetes Service). L’article explique comment améliorer la sécurité des connexions au serveur d’API managé d’un cluster AKS ainsi que les différentes options permettant de restreindre l’accès au réseau public.

Remarque

Cet article fait partie d'une série d'articles qui aide les professionnels qui connaissent Amazon EKS à comprendre Azure Kubernetes Service (AKS).

Modes d’utilisation d’un réseau Amazon EKS

Avec Amazon VPC (Amazon Virtual Private Cloud), vous pouvez lancer des ressources AWS (Amazon Web Services) sur un réseau virtuel composé de sous-réseaux publics et privés, ou de plages d’adresses IP dans le réseau VPC. Un sous-réseau public héberge des ressources qui doivent être connectées à Internet, et un sous-réseau privé héberge des ressources qui ne sont pas connectées à l’Internet public. Amazon EKS peut provisionner des groupes de nœuds managés dans des sous-réseaux publics et privés.

Le contrôle d’accès des points de terminaison vous permet de déterminer si le point de terminaison d’un serveur d’API est accessible à partir du réseau Internet public ou via le réseau VPC. EKS offre plusieurs façons de contrôler l’accès au point de terminaison de cluster. Vous pouvez activer le point de terminaison public par défaut, un point de terminaison privé ou les deux points de terminaison simultanément. Quand vous activez le point de terminaison public, vous pouvez ajouter des restrictions CIDR (Classless Inter-Domain Routing) pour limiter le nombre d’adresses IP de clients pouvant se connecter au point de terminaison public.

La façon dont les nœuds Amazon EKS se connectent au plan de contrôle Kubernetes managé est déterminée par le paramètre de point de terminaison configuré pour le cluster. Vous pouvez changer les paramètres de point de terminaison à tout moment via la console Amazon EKS ou l’API. Pour plus d’informations, consultez Contrôle d’accès des points de terminaison de cluster Amazon EKS.

Point de terminaison public uniquement

L’exposition du plan de contrôle via un point de terminaison public est le mode par défaut pour les nouveaux clusters Amazon EKS. Quand seul le point de terminaison public du cluster est activé, les requêtes d’API Kubernetes provenant d’Amazon VPC (par exemple la communication entre le nœud Worker et le plan de contrôle) quittent le réseau VPC mais pas le réseau d’Amazon. Pour que les nœuds se connectent au plan de contrôle, ils doivent utiliser une adresse IP publique et une route vers une passerelle Internet, ou une route vers une passerelle NAT (traduction d’adresses réseau) où ils peuvent utiliser l’adresse IP publique de la passerelle NAT.

Points de terminaison publics et privés

Quand les points de terminaison publics et privés sont activés, les requêtes d’API Kubernetes provenant du réseau VPC communiquent avec le plan de contrôle via les interfaces ENI (interfaces réseau élastiques) managées par Amazon EKS dans le VPC. Le serveur d’API du cluster est accessible depuis Internet.

Point de terminaison privé uniquement

Lorsque seul le point de terminaison privé est activé, tout le trafic vers le serveur d’API de cluster, tel que les commandes kubectl ou helm, doit provenir du VPC du cluster ou d’un réseau connecté . L’accès public au serveur d’API à partir d’Internet est désactivé. Vous pouvez implémenter ce mode d’accès en utilisant AWS VPN (AWS Virtual Private Network) ou AWS DirectConnect pour la connexion au réseau VPC. Pour restreindre l’accès au point de terminaison sans AWS VPN ou DirectConnect, vous pouvez ajouter des restrictions CIDR au point de terminaison public afin de limiter les connexions sans effectuer de configurations réseau supplémentaires.

Si vous avez désactivé l’accès public pour le point de terminaison du serveur d’API Kubernetes de votre cluster, vous pouvez accéder au point de terminaison du serveur d’API Kubernetes de l’une des façons suivantes :

  • réseau connecté : connectez votre réseau au VPC avec une passerelle de transit AWS ou d’autres options de connectivité , puis utilisez un ordinateur dans le réseau connecté. Vous devez vous assurer que votre groupe de sécurité du plan de contrôle Amazon EKS contient des règles pour autoriser le trafic d’entrée sur le port 443 à partir de votre réseau connecté.
  • 'hôte Bastion Amazon EC2: vous pouvez lancer une instance Amazon EC2 dans un sous-réseau public du VPC de votre cluster, puis vous connecter via SSH à cette instance pour exécuter des commandes kubectl. Pour plus d’informations, consultez hôtes bastion Linux sur AWS. Vous devez vous assurer que votre groupe de sécurité du plan de contrôle Amazon EKS contient des règles pour autoriser le trafic d’entrée sur le port 443 à partir de votre hôte bastion. Pour plus d’informations, consultez Afficher les exigences de groupe de sécurité Amazon EKS pour les clusters. Lorsque vous configurez kubectl pour votre hôte bastion, veillez à utiliser les informations d’identification AWS qui sont déjà mappées à la configuration RBAC de votre cluster, ou ajoutez le principal IAM que votre bastion utilisera pour la configuration RBAC avant de supprimer l’accès public du point de terminaison. Pour plus d’informations, consultez Accorder aux utilisateurs et rôles IAM l’accès aux API Kubernetes et non autorisé ou refusé (kubectl).
  • IDE AWS Cloud9: AWS Cloud9 est un environnement de développement intégré (IDE) basé sur le cloud qui vous permet d’écrire, d’exécuter et de déboguer votre code avec un navigateur. Vous pouvez créer un IDE AWS Cloud9 dans le VPC de votre cluster et utiliser l’IDE pour communiquer avec votre cluster. Pour plus d’informations, consultez Création d’un environnement dans AWS Cloud9. Vous devez vous assurer que votre groupe de sécurité du plan de contrôle Amazon EKS contient des règles pour autoriser le trafic d’entrée sur le port 443 à partir de votre groupe de sécurité IDE. Pour plus d’informations, consultez Afficher les exigences de groupe de sécurité Amazon EKS pour les clusters. Lorsque vous configurez kubectl pour votre IDE AWS Cloud9, veillez à utiliser les informations d’identification AWS qui sont déjà mappées à la configuration RBAC de votre cluster, ou ajoutez le principal IAM que votre IDE utilisera à la configuration RBAC avant de supprimer l’accès public du point de terminaison. Pour plus d’informations, consultez Accorder aux utilisateurs et rôles IAM l’accès aux API Kubernetes et non autorisé ou refusé (kubectl).

Pour plus d’informations sur les options de connectivité, consultez Accès à un serveur d’API privé uniquement.

Accès réseau AKS au serveur d’API

Il existe deux options pour sécuriser l’accès réseau à l’API Kubernetes dans AKS : un cluster AKS privé ou des plages d’adresses IP autorisées.

Cluster AKS privé

Un cluster AKS privé garantit que le trafic réseau entre le serveur d’API et les nœuds de l’agent reste dans le réseau virtuel. Dans un cluster AKS privé, le plan de contrôle ou le serveur d’API a des adresses IP internes définies dans le document RFC1918 - Allocation d’adresses pour l’Internet privé document. En utilisant un cluster privé, vous pouvez garantir le trafic réseau entre votre serveur d’API et vos pools de nœuds uniquement sur le réseau privé.

Dans un cluster AKS privé, le serveur d’API a une adresse IP interne accessible uniquement via un point de terminaison privé Azure situé dans le même réseau virtuel. Toute machine virtuelle du même réseau virtuel peut communiquer en privé avec le plan de contrôle via ce point de terminaison privé. Le plan de contrôle ou le serveur d’API est hébergé dans l’abonnement managé par Azure, tandis que le cluster AKS et ses pools de nœuds se trouvent dans l’abonnement du client.

Lorsque vous approvisionnez un cluster AKS privé, AKS crée par défaut un nom de domaine complet privé avec une zone DNS privée et un nom de domaine complet public supplémentaire avec un enregistrement de A correspondant dans le DNS public Azure. Les nœuds de l’agent continuent d’utiliser l’enregistrement A dans la zone DNS privée pour résoudre l’adresse IP privée du point de terminaison privé pour la communication avec le serveur d’API.

Le diagramme suivant illustre une configuration de cluster AKS privée.

Diagramme montrant un cluster AKS privé.

Téléchargez un fichier Visio de cette architecture.

Pour provisionner un cluster AKS privé, le fournisseur de ressources AKS crée un FQDN (nom de domaine complet) privé pour le groupe de ressources de nœud dans une zone DNS privée. Si vous le souhaitez, AKS peut également créer un FQDN public avec un enregistrement d’adresse (A) correspondant dans la zone DNS publique Azure. Les nœuds d’agent utilisent l’enregistrement A dans la zone DNS privée pour résoudre l’adresse IP du point de terminaison privé et permettre la communication avec le serveur d’API.

Le fournisseur de ressources AKS peut créer la zone DNS privée dans le groupe de ressources de nœud. Vous pouvez également créer la zone DNS privée et faire passer son ID de ressource au système de provisionnement. Vous pouvez créer un cluster privé quand vous utilisez Terraform avec Azure, Bicep, les modèles ARM, Azure CLI, le module Azure PowerShell ou l’API REST Azure pour créer le cluster.

Vous pouvez activer un FQDN public pour le serveur d’API durant le provisionnement ou à l’aide de la commande az aks update avec le paramètre --enable-public-fqdn sur les clusters existants. Si vous activez le FQDN public, toute machine virtuelle qui accède au serveur, par exemple un agent autohébergé Azure DevOps ou un exécuter autohébergé GitHub Actions, doit se trouver dans le réseau virtuel qui héberge le cluster, ou dans un réseau connecté via un peering de réseaux virtuels ou un VPN site à site.

Pour un cluster AKS privé, vous devez désactiver le FQDN public du serveur d’API. Pour communiquer avec le plan de contrôle privé, une machine virtuelle doit se trouver dans le même réseau virtuel ou dans un réseau virtuel appairé avec une liaison de réseau virtuel vers la zone DNS privée. L’enregistrement A dans la zone DNS privée résout le FQDN du serveur d’API en adresse IP de point de terminaison privé qui communique avec le plan de contrôle sous-jacent. Pour plus d’informations, consultez Créer un cluster Azure Kubernetes Service privé.

Options de déploiement de cluster privé

Le fournisseur de ressources AKS expose les paramètres suivants pour personnaliser le déploiement de clusters AKS privés :

  • authorizedIpRanges (chaîne) spécifie les plages d’adresses IP autorisées au format CIDR.
  • disableRunCommand (Booléen) spécifie s’il est nécessaire de désactiver ou non la commande run pour le cluster.
  • enablePrivateCluster (Booléen) spécifie s’il est nécessaire de créer ou non le cluster en tant que cluster privé.
  • enablePrivateClusterPublicFQDN (Booléen) spécifie s’il est nécessaire de créer ou non un autre FQDN public pour le cluster privé.
  • privateDnsZone (chaîne) spécifie une zone DNS privée dans le groupe de ressources de nœud. Si vous ne spécifiez aucune valeur, le fournisseur de ressources crée la zone. Vous pouvez spécifier les valeurs suivantes :
    • System est la valeur par défaut.
    • None représente par défaut le DNS public. Ainsi, AKS ne crée pas de zone DNS privée.
    • <Your own private DNS zone resource ID> utilise une zone DNS privée que vous créez au format privatelink.<region>.azmk8s.io ou <subzone>.privatelink.<region>.azmk8s.io.

Le tableau suivant montre les options de configuration DNS pour le déploiement d’un cluster AKS privé :

Options de zone DNS privée enablePrivateClusterPublicFQDN: true enablePrivateClusterPublicFQDN: false
Système Les nœuds d’agent ainsi que toutes les autres machines virtuelles du réseau virtuel de cluster AKS ou de tout réseau virtuel connecté à la zone DNS privée, utilisent l’enregistrement A de la zone DNS privée pour résoudre l’adresse IP privée du point de terminaison privé.

Toute autre machine virtuelle utilise le FQDN public du serveur d’API.		 Les nœuds d’agent ainsi que toutes les autres machines virtuelles du réseau virtuel de cluster AKS ou de tout réseau virtuel connecté à la zone DNS privée, utilisent l’enregistrement A de la zone DNS privée pour résoudre l’adresse IP privée du point de terminaison privé.

Aucun FQDN de serveur d’API public n’est disponible.
Aucun Toutes les machines virtuelles ainsi que les nœuds d’agent utilisent le FQDN public du serveur d’API disponible via un enregistrement A dans une zone DNS publique managée par Azure. Configuration incorrecte. Le cluster AKS privé a besoin d’au moins une zone DNS publique ou privée pour la résolution de noms du serveur d’API.
Votre propre ID de ressource de zone DNS privée Les nœuds d’agent ainsi que toutes les autres machines virtuelles du réseau virtuel de cluster AKS ou de tout réseau virtuel connecté à la zone DNS privée, utilisent l’enregistrement A de la zone DNS privée pour résoudre l’adresse IP privée du point de terminaison privé.

Toutes les autres machines virtuelles utilisent le FQDN public du serveur d’API.		 Les nœuds d’agent ainsi que toutes les autres machines virtuelles du réseau virtuel de cluster AKS ou de tout réseau virtuel connecté à la zone DNS privée, utilisent l’enregistrement A de la zone DNS privée pour résoudre l’adresse IP privée du point de terminaison privé.

Aucun FQDN de serveur d’API public n’est disponible.

Connectivité et gestion des clusters privés

Dans un cluster AKS privé, le point de terminaison du serveur d’API n’a aucune adresse IP publique. Il existe plusieurs options pour établir la connectivité réseau au cluster privé :

  1. Créez une machine virtuelle dans le même réseau virtuel que le cluster AKS à l’aide de la commande az vm create avec l’indicateur de --vnet-name.
  2. Utilisez une machine virtuelle dans un réseau virtuel distinct et configurez appairage de réseaux virtuels avec le réseau virtuel du cluster AKS.
  3. Configurez une Azure ExpressRoute ou un VPN pour vous connecter au réseau virtuel de cluster.
  4. Créez une connexion point de terminaison privé Azure à l’intérieur d’un autre réseau virtuel.
  5. Utilisez une instance Cloud Shell déployée dans un sous-réseau connecté au serveur d’API pour le cluster.

À l’aide d’Azure CLI, vous pouvez utiliser la commande az aks appeler commande pour accéder aux clusters privés sans avoir besoin de configurer un VPN ou express Route. Cette commande vous permet d’appeler à distance des commandes, telles que kubectl et helm, sur votre cluster privé via l’API Azure, sans avoir à se connecter directement au cluster. Pour utiliser command invoke, vous devez disposer des autorisations nécessaires configurées pour les actions Microsoft.ContainerService/managedClusters/runcommand/action et Microsoft.ContainerService/managedclusters/commandResults/read.

Dans le portail Azure, vous pouvez utiliser la fonctionnalité Run command pour exécuter des commandes sur votre cluster privé. Cette fonctionnalité utilise réellement la fonctionnalité de command invoke pour exécuter des commandes sur votre cluster. Le pod créé par la fonctionnalité Run command fournit des outils kubectl et helm pour la gestion de votre cluster. En outre, il prend en charge Bash avec des outils tels que jq, xargs, grepet awk disponibles.

Vous pouvez utiliser Azure Bastion dans le même réseau virtuel ou un réseau virtuel appairé pour vous connecter à une machine virtuelle de gestion de jump box. Azure Bastion est une solution PaaS (platform as a service) complètement managée qui vous permet de vous connecter à une machine virtuelle à l’aide de votre navigateur et du portail Azure. Azure Bastion fournit une connectivité sécurisée et transparente aux machines virtuelles en utilisant le protocole RDP (Remote Desktop Protocol) ou SSH (Secure Shell) via le protocole TLS (Transport Layer Security) directement à partir du portail Azure. Quand les machines virtuelles se connectent via Azure Bastion, elles n’ont pas besoin d’une adresse IP publique, d’un agent ou d’un logiciel client particulier.

Intégration au réseau virtuel du serveur d’API

Un cluster Azure Kubernetes Service (AKS) configuré avec intégration au réseau virtuel du serveur d’API projete le point de terminaison du serveur d’API directement dans un sous-réseau délégué dans le réseau virtuel où AKS est déployé. L’intégration au réseau virtuel du serveur d’API permet la communication réseau entre le serveur d’API et les nœuds de cluster sans nécessiter de liaison privée ou de tunnel. Le serveur d’API est disponible derrière une adresse IP virtuelle d’équilibreur de charge interne dans le sous-réseau délégué, que les nœuds sont configurés pour l’utiliser. En utilisant l’intégration au réseau virtuel du serveur d’API, vous pouvez garantir que le trafic réseau entre votre serveur d’API et vos pools de nœuds reste sur le réseau privé uniquement.

Le plan de contrôle ou le serveur d’API se trouve dans un abonnement Azure géré par AKS. Votre cluster ou pool de nœuds se trouve dans votre abonnement Azure. Le serveur et les machines virtuelles qui composent les nœuds de cluster peuvent communiquer entre eux par le biais de l’adresse IP virtuelle et des pods du serveur d’API qui sont projetées dans le sous-réseau délégué.

L’intégration au réseau virtuel du serveur d’API est prise en charge pour les clusters publics ou privés. Vous pouvez ajouter ou supprimer l’accès public après l’approvisionnement du cluster. Contrairement aux clusters non intégrés au réseau virtuel, les nœuds d’agent communiquent toujours directement avec l’adresse IP privée de l’équilibreur de charge interne du serveur d’API (ILB) sans utiliser DNS. Tout le trafic du nœud vers le serveur d’API est conservé sur la mise en réseau privée et aucun tunnel n’est nécessaire pour que le serveur d’API soit connecté au nœud. Les clients hors cluster qui ont besoin de communiquer avec le serveur d’API peuvent le faire normalement si l’accès au réseau public est activé. Si l’accès au réseau public est désactivé, vous devez suivre la même méthodologie de configuration DNS privée que les clusters privés standard . Pour plus d’informations, consultez Créer un cluster Azure Kubernetes Service avec API Server VNet Integration.

Plages d’adresses IP autorisées

La deuxième option pour améliorer la sécurité du cluster et réduire les attaques contre le serveur d’API consiste à utiliser des plages d’adresses IP autorisées. Les adresses IP autorisées restreignent l’accès au plan de contrôle d’un cluster AKS public à une liste connue d’adresses IP et de CIDR. Quand vous utilisez cette option, le serveur d’API est toujours exposé publiquement, mais son accès est limité. Pour plus d’informations, consultez Sécuriser l’accès au serveur d’API à l’aide de plages d’adresses IP autorisées dans Azure Kubernetes Service (AKS).

La commande Azure CLI az aks update suivante autorise les plages d’adresses IP :

 az aks update \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --api-server-authorized-ip-ranges  73.140.245.0/24

Considérations relatives à la connectivité AKS

Lorsque vous envisagez la connectivité AKS, il existe plusieurs considérations importantes à prendre en compte. Voici quelques points clés à prendre en compte :

  • Un cluster privé AKS offre une sécurité et une isolation améliorées par rapport aux adresses IP autorisées. Toutefois, il n’est pas possible de convertir un cluster AKS public existant en cluster privé. Au lieu de cela, les adresses IP autorisées peuvent être activées pour n’importe quel cluster AKS existant.
  • Les plages d’adresses IP autorisées ne peuvent pas être appliquées à un point de terminaison de serveur d’API privé. Ils s’appliquent uniquement au serveur d’API public.
  • Les clusters privés ne prennent pas en charge les agents hébergés par Azure DevOps. Il est recommandé d’utiliser des agents auto-hébergés à la place.
  • Pour qu’Azure Container Registry fonctionne avec un cluster AKS privé, une liaison privée doit être configurée pour le registre de conteneurs dans le réseau virtuel du cluster. Vous pouvez également établir un peering entre le réseau virtuel Container Registry et le réseau virtuel du cluster privé.
  • Les limitations du service Azure Private Link s’appliquent aux clusters privés.
  • Si le point de terminaison privé dans le sous-réseau du client d’un cluster privé est supprimé ou modifié, le cluster cesse de fonctionner.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Les références suivantes fournissent des liens vers de la documentation et des exemples d’automatisation pour déployer des clusters AKS avec une API sécurisée :