Améliorer la sécurité de l’accès réseau à Kubernetes

2025-04-14

Cet article compare les modes de mise en réseau pour Azure Kubernetes Service (AKS) et Amazon Elastic Kubernetes Service (EKS). Il explique comment améliorer la sécurité des connexions au serveur d’API managé d’un cluster AKS. Il inclut également des options pour restreindre l’accès au réseau public.

Remarque

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

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

Vous pouvez utiliser Amazon Virtual Private Cloud (VPC) pour lancer des ressources Amazon Web Services (AWS) dans un réseau virtuel disposant de sous-réseaux publics et privés. Les sous-réseaux sont des plages d’adresses IP au sein du VPC. Un sous-réseau public héberge des ressources qui se connectent à Internet. Un sous-réseau privé héberge des ressources qui ne se connectent pas à 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 au point de terminaison vous permet de configurer si le point de terminaison du serveur d’API est accessible à partir de l’Internet public ou via le VPC. Amazon EKS offre plusieurs façons de contrôler l’accès au point de terminaison du 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.

Le paramètre de point de terminaison du cluster détermine comment les nœuds Amazon EKS se connectent au plan de contrôle Kubernetes managé. Vous pouvez modifier les paramètres de point de terminaison 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

Le mode par défaut pour les nouveaux clusters Amazon EKS expose le plan de contrôle via un point de terminaison public. Quand seul le point de terminaison public du cluster est activé, les demandes d’API Kubernetes provenant du VPC quittent le VPC, mais ne quittent pas le réseau d’Amazon. Ces requêtes comprennent la communication entre le nœud Worker et le plan de contrôle. Les nœuds se connectent au plan de contrôle via une adresse IP publique et un itinéraire vers une passerelle Internet. Elles peuvent également utiliser une route vers une passerelle NAT (Network Address Translation), où elles peuvent utiliser l’adresse IP publique de la passerelle NAT.

Points de terminaison publics et privés

Lorsque vous activez les points de terminaison publics et privés, les demandes d’API Kubernetes à partir du VPC communiquent avec le plan de contrôle via les interfaces réseau élastiques gérées par Amazon EKS (ENIs) dans le VPC. Le serveur d’API de cluster est accessible à partir d’Internet.

Point de terminaison privé uniquement

Lorsque vous activez uniquement le point de terminaison privé, tout le trafic vers le serveur d’API de cluster, tel que kubectl ou helm commandes, 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é. Pour implémenter ce mode d’accès, utilisez le réseau privé virtuel AWS (VPN) ou AWS DirectConnect au 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 désactivez 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 manières suivantes :

Réseau connecté : Connectez votre réseau au VPC à l’aide d’une passerelle de transit AWS, puis utilisez un ordinateur dans le réseau connecté. Vous pouvez également utiliser d’autres options de connectivité. Vérifiez 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 dans le VPC de votre cluster. Connectez-vous à cette instance via Secure Shell (SSH) pour exécuter kubectl des commandes. Assurez-vous que le groupe de sécurité du plan de contrôle de votre Amazon EKS contient des règles autorisant le trafic entrant 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, utilisez les informations d’identification AWS qui correspondent à la configuration du contrôle d’accès en fonction du rôle (RBAC) de votre cluster. Vous pouvez également ajouter le principal AWS Identity and Access Management (IAM) que votre bastion utilise à la configuration RBAC avant de supprimer l'accès public au point de terminaison. Pour plus d’informations, consultez Accorder aux utilisateurs et rôles IAM l’accès aux API Kubernetes et Accès refusé ou non autorisé (kubectl).
IDE AWS Cloud9 : AWS Cloud9 est un environnement de développement intégré (IDE) basé sur le cloud que vous pouvez utiliser pour écrire, exécuter et déboguer votre code uniquement 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éer un environnement dans AWS Cloud9. Vérifiez 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, utilisez les informations d’identification AWS qui correspondent à la configuration RBAC de votre cluster. Vous pouvez également ajouter le principal IAM utilisé par votre IDE à la configuration RBAC avant de supprimer l'accès public au point de terminaison. Pour plus d’informations, consultez Accorder aux utilisateurs et rôles IAM l’accès aux API Kubernetes et Accès refusé ou non autorisé (kubectl).

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

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

Pour sécuriser l’accès réseau à l’API Kubernetes dans AKS, vous pouvez utiliser un cluster AKS privé ou des plages d’adresses IP autorisées.

Cluster AKS privé

Un cluster AKS privé permet de s’assurer que le trafic réseau entre le serveur d’API et les nœuds de l’agent reste au sein du réseau virtuel. Dans un cluster AKS privé, le plan de contrôle ou le serveur d’API a des adresses IP internes. Un cluster privé permet de s’assurer que le trafic réseau entre votre serveur d’API et vos pools de nœuds reste 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. Les machines virtuelles du même réseau virtuel peuvent 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 géré par Azure. Le cluster AKS et ses pools de nœuds se trouvent dans l’abonnement du client.

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

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

Pour approvisionner un cluster AKS privé, le fournisseur de ressources AKS crée un nom de domaine complet privé (FQDN) pour le groupe de ressources de nœud dans une zone DNS (Domain Name System) privée. Si vous le souhaitez, AKS peut également créer un nom de domaine complet public qui a 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. Pour créer un cluster privé, vous pouvez utiliser Terraform avec Azure, Bicep, les modèles Azure Resource Manager, Azure CLI, le module Azure PowerShell ou l’API REST Azure.

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 nom de domaine complet public, les machines virtuelles qui accèdent au serveur doivent se trouver dans le même réseau virtuel qui héberge le cluster ou dans un réseau connecté via le peering de réseaux virtuels ou le VPN de site à site. Par exemple, ces machines virtuelles incluent un agent auto-hébergé Azure DevOps ou un exécuteur auto-hébergé GitHub Actions.

Pour un cluster AKS privé, désactivez le nom de domaine complet 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 homologue disposant d'une liaison de réseau virtuel avec 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 AKS privé.

Options de déploiement de cluster privé

Le fournisseur de ressources AKS expose les paramètres suivants pour personnaliser les déploiements de cluster AKS privés :

La authorizedIpRanges chaîne spécifie les plages d’adresses IP autorisées au format CIDR.
La disableRunCommand valeur booléenne spécifie s’il faut désactiver la run commande du cluster.
La enablePrivateCluster valeur booléenne spécifie s’il faut créer le cluster en tant que privé.
La enablePrivateClusterPublicFQDN valeur booléenne spécifie s’il faut créer un autre nom de domaine complet public pour le cluster privé.
La 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 présente les options de configuration DNS pour déployer un cluster AKS privé :

Options de zone DNS privée	`enablePrivateClusterPublicFQDN: true`	`enablePrivateClusterPublicFQDN: false`
Système	Les nœuds de l’agent, ainsi que toutes les autres machines virtuelles du réseau virtuel du cluster AKS ou de tout réseau virtuel connecté à la zone DNS privée, utilisent l'enregistrement de la zone DNS privée `A` pour résoudre l'adresse IP privée du point de terminaison privé. D’autres machines virtuelles utilisent le nom de domaine complet public du serveur d’API.	Les nœuds de l’agent, ainsi que toutes les autres machines virtuelles du réseau virtuel du cluster AKS ou de tout réseau virtuel connecté à la zone DNS privée, utilisent l'enregistrement de la zone DNS privée `A` 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, y compris les nœuds d’agent, utilisent le nom de domaine complet public du serveur d’API via un `A` enregistrement dans une zone DNS publique géré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 de l’agent, ainsi que toutes les autres machines virtuelles du réseau virtuel du cluster AKS ou de tout réseau virtuel connecté à la zone DNS privée, utilisent l'enregistrement de la zone DNS privée `A` pour résoudre l'adresse IP privée du point de terminaison privé. D’autres machines virtuelles utilisent le nom de domaine complet public du serveur d’API.	Les nœuds de l’agent, ainsi que toutes les autres machines virtuelles du réseau virtuel du cluster AKS ou de tout réseau virtuel connecté à la zone DNS privée, utilisent l'enregistrement de la zone DNS privée `A` 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. Vous pouvez utiliser l’une des options suivantes pour établir la connectivité réseau au cluster privé :

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

Utilisez Azure CLI pour exécuter la commande az aks invoke pour accéder aux clusters privés sans configurer de passerelle VPN ou ExpressRoute. Utilisez cette commande pour appeler à distance d’autres commandes, telles que kubectl et helm, sur votre cluster privé via l’API Azure, sans vous connecter directement au cluster. Pour utiliser command invoke, configurez les autorisations nécessaires pour les actions Microsoft.ContainerService/managedClusters/runcommand/action et Microsoft.ContainerService/managedclusters/commandResults/read.

Dans le portail Azure, vous pouvez utiliser la Run command fonctionnalité pour exécuter des commandes sur votre cluster privé. Cette fonctionnalité utilise la command invoke fonctionnalité pour exécuter des commandes sur votre cluster. Le pod que la fonctionnalité Run command crée fournit des outils kubectl et helm pour gérer votre cluster. Le Run command fournit également un environnement Bash au sein du pod qui comprend des outils tels que jq, xargs, grep et awk.

Vous pouvez utiliser Azure Bastion dans le même réseau virtuel ou dans un réseau virtuel appairé pour vous connecter à une machine virtuelle de gestion Jumpbox. Azure Bastion est une plateforme entièrement managée en tant que service (PaaS) que vous pouvez utiliser pour vous connecter à une machine virtuelle via votre navigateur et le portail Azure. Azure Bastion fournit une connectivité de machine virtuelle RDP (Remote Desktop Protocol) hautement sécurisée et transparente via 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 AKS configuré avec API Server VNet Integration projette le point de terminaison du serveur d’API directement dans un sous-réseau délégué. Le sous-réseau se trouve 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 liaison privée ou tunnel. Le serveur API est disponible derrière un équilibreur de charge VIP interne qui se trouve dans le sous-réseau délégué. Les nœuds sont configurés pour utiliser l'adresse IP virtuelle de l'équilibreur de charge interne. Utilisez l’intégration au réseau virtuel du serveur d’API pour vous assurer 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 du cluster peuvent communiquer entre eux par le biais des adresses IP VIP du serveur API et des pods, qui sont projetées dans le sous-réseau délégué.

Vous pouvez utiliser l’intégration au réseau virtuel du serveur d’API avec des clusters publics et des clusters privés. Vous pouvez ajouter ou supprimer l’accès public après l’approvisionnement du cluster. Contrairement aux clusters qui n’ont pas d’intégration de réseau virtuel, les nœuds d’agent communiquent toujours directement avec l’adresse IP privée de l’adresse IP de l’équilibreur de charge interne du serveur d’API sans utiliser DNS. Le trafic allant du nœud au serveur API est sur un réseau privé. Et la connectivité de serveur à nœud d’API ne nécessite pas de tunnel. Les clients hors cluster peuvent communiquer avec le serveur d’API normalement si l’accès au réseau public est activé. Si l’accès au réseau public est désactivé, suivez la même méthodologie d’installation DNS privée que les clusters privés standard. Pour plus d’informations, consultez Créer un cluster AKS avec API Server VNet Integration.

Plages d’adresses IP autorisées

Vous pouvez également utiliser des plages d’adresses IP autorisées pour améliorer la sécurité du cluster et réduire les attaques sur le serveur d’API. Les plages d’adresses IP autorisées limitent 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é.

La commande Azure CLI suivante az aks update 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

Tenez compte des points clés suivants pour la connectivité AKS :

Un cluster privé AKS offre une sécurité et une isolation améliorées par rapport aux plages d’adresses IP autorisées. Toutefois, vous ne pouvez pas convertir un cluster AKS public existant en cluster privé. Au lieu de cela, vous pouvez activer les plages d’adresses IP autorisées pour n’importe quel cluster AKS existant.
Vous ne pouvez pas appliquer de plages d’adresses IP autorisé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. Vous devriez plutôt utiliser des agents auto-hébergés.
Pour qu’Azure Container Registry fonctionne avec un cluster AKS privé, vous devez configurer une liaison privé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 d’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

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

Paolo Salvatori | Ingénieur des services principaux
Martin Gjoshevski | Ingénieur service senior
Laura Nicolas | Architecte de solution cloud senior

Autres contributeurs :

Chad Kittel | Ingénieur logiciel principal - Modèles et pratiques Azure
Ed Price | Responsable de programme senior
Theano Petersen | Rédacteur technique

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