Considérations réseaux pour Azure Kubernetes Services (partie 1)

Dans cet article, nous allons nous pencher sur les aspects réseaux d’Azure Kubernetes Services.

En effet, il n’est pas aisé de commencer sereinement à utiliser Kubernetes sur Azure sans en comprendre les particularités d’un point de vue réseau. Nous allons donc tâcher d’éclaircir tous ces aspects dans un article en deux parties.

Dans cette première partie, nous considèrerons les sujets suivants :

• Vue de haut de l’architecture AKS
• Considération réseaux pour le plan de contrôle de Kubernetes dans Azure.

Vue de haut de l’architecture AKS

Dans sa plus simple description, nous pourrions définir l’architecture de Kubernetes en 2 blocs :

• Le plan de contrôle (ou control plane), qui comme son nom l’indique, contrôle tout dans Kubernetes, et avec lequel les Admins Kubernetes interagissent ;
• Le plan de travail (ou worker plane), qui héberge les applications sur ses nodes à travers les commandes envoyées par le plan de contrôle.

Dans la mesure où nous parlons d’Azure, si nous transposons cette architecture dans le Cloud Microsoft, nous obtenons ceci :

Le plan de contrôle, et spécifiquement l’API server, est inclus dans le réseau des instances PaaS. Ce qui signifie qu’il est accessible publiquement, à travers des noms de domaine publics managés par Microsoft (d’un point de vue DNS).

Le plan de travail est lui plus proche de ressources de type IaaS, au sens où l’on voit clairement un Virtual network, des scales sets et autres objects connus des Admins IaaS. En ce qui concerne le Virtual network, il pourra être géré automatiquement par l’instance AKS, ou préparé avant, selon les choix d’architectures.

Pour le moment, cela nous suffira. Plongeons à présent plus profondément dans les spécificités réseau du plan de contrôle.

Considérations réseaux pour le plan de contrôle de Kubernetes dans Azure

Concepts réseaux pour le PaaS

Comme nous l’avons dit en introduction, le plan de contrôle AKS est une instance PaaS. Nous avons, comme pour la plupart des instances PaaS, quelques options de configuration basiques à travers le portail ou les APIs, pour gérer du filtrage réseau.

En général, les instances de solutions PaaS sont protégées à travers des règles de Firewall permettant de gérer une Accept List spécifiant des IP publiques autorisées, et dans certains cas des Virtual networks à travers des Virtual network Rules.

Cela signifie que nous pouvons donc contrôler l’accès à l’instance PaaS pour des clients présentant une IP publique, ou pour des clients dont les machines sont hébergées dans un Virtual network. Ce dernier cas s’appuie sur les Azure Service Endpoints, que nous n’approfondirons pas dans cet article.

Notons qu’il est possible d’autoriser l’accès d’un client hébergé dans un virtual network à travers l’IP publique qu’il présente en sortant sur Internet. Toutefois, si la configuration par défaut du subnet est active, la machine peut sortir avec une IP publique managée par Azure, et non spécifiée. Il faut alors autoriser un pool d’IP publiques définies sur la région au niveau de l’Accept List, ce qui est loin d’être idéal, tant sur le plan de du management que de la sécurité.

D’un point de vue sécurité, l’Accept List est souvent considérée comme insuffisante. L’option service Endpoint apporte d’autres limitations, notamment le fait que l’instance PaaS reste malgré tout connectée au DNS  Azure public. Pour répondre à ce besoin de PaaS privé, Microsoft a mis en œuvre la technologie Private Link, et spécifiquement pour les instances PaaS, les private endpoints.

Les private endpoints permettent de changer la gestion DNS d’une instance PaaS. En lieu et place du DNS Azure public, l’instance est enregistrée dans une zone DNS Azure privée.

D’un point de vue réseau, la connexion au réseau public est désactivée, et une carte réseau (ou NIC pour Network Interface Card) est créée dans un virtual network. La nouvelle NIC prend ainsi une IP privée qui est enregistrée dans la zone DNS privée.

Cette solution élégante introduit un peu plus de complexité dans la gestion du DNS, d’autant plus si l’on parle de Cloud (et donc de réseau) hybride. Pour plus de détails, fort heureusement, il est possible de se référer à la documentation Azure sur les private endpoints et sur la gestion du DNS associé.

Une fois ces concepts établis, passons à présent à la mise en œuvre sur AKS.

API Server Accept List

Pour commencer, et c’est pour cela que nous n’avons pas développé le sujet, il n’est pas possible d’utiliser de virtual network rule avec AKS. Nous n’avons que l’option d’Accept List pour des IP publiques.

Illustrons cela avec un cluster AKS. Commençons par vérifier le FQDN (fully qualified domain name) du cluster, et voyons si nous pouvons résoudre son IP :

Ce cluster est configuré avec une IP accessible publiquement, comme nous le montre la capture d’écran suivante :

Avec kubectl configuré convenablement, nous pouvons interagir avec le cluster :

Si l’on configure les IP acceptées depuis le portail, en omettant notre IP source, nous obtiendrons un time out sur notre commande kubectl.

Notons la commande az cli pour avoir le profil de l’API Server :

Bien évidemment, si l’on ajoute notre IP dans la liste, la connexion est possible.

Voilà qui clôt cette première option de sécurisation réseau, qui, vraisemblablement, ne sera pas suffisante. Passons à présent au concept de cluster AKS privé.

Cluster AKS privé

Pour rappel, nous avons (ré-)introduit le concept de private endpoint dans une partie précédente.

S’il reste une impression de complexité malgré cette première tentative d’explication, disons que ce n’est pas surprenant.

Le principal point dans la gestion des private endpoints est le DNS. Plutôt qu’un DNS public, nous avons un FQDN (fully qualified domain name) dans une zone DNS Azure privée. En toute logique, le routage s’en trouve modifié, et nous permet ainsi de sécuriser l’accès à l’API Kubernetes puisqu’elle n’est plus exposée publiquement.

Pour AKS, nous n’avons pas moins de trois façons de faire différentes pour obtenir un cluster privé :

• Première option, nous apportons notre propre zone DNS privée Azure et nous la spécifions au moment de la création du cluster. Comme la zone DNS doit être disponible avant la création du cluster, il y a un peu plus de planification. En contrepartie, cela permet de garder le contrôle sur les zones DNS privées, et notamment de permettre un accès hybride en configurant du DNS forwarding vers cette zone pour tous les clusters.
• Pour la deuxième option, nous laissons le cluster gérer automatiquement la création de la zone DNS. Pas de planification, donc une création simplifiée. En revanche, le scénario hybride devient beaucoup plus complexe puisque nous avons une zone DNS par cluster.
• Parlons à présent de la troisième option. Il s’agit d’un genre de cluster privé hybride. Dans la mesure où la complexité est portée par cet ajout de gestion de zones DNS, nous allons laisser cette gestion du côté du Cloud provider. L’enregistrement DNS est toujours dans l’espace de nom public du service AKS, mais nous avons bien un private endpoint. Le meilleur des deux mondes, si l’on accepte de pouvoir voir l’adresse privée du cluster sur une zone DNS publique.

Enfin, dernier point, la gestion du private endpoint diffère des autres services pour AKS, dans la mesure ou celui-ci est géré par le plan de contrôle AKS.

Regardons un exemple de cluster privé :

On peut voir depuis la section Network que le cluster est privé, mais que son FQDN est bien public.

Ce que l’on peut confirmer avec la bonne requete az cli.

On ne peut pas interagir directement avec le cluster, sauf si l’on est connecté à un réseau accédant au private endpoint.

Après l’exemple du cluster privé avec FQDN public, regardons à présent le cluster privé avec une zone DNS managée par AKS (notre option 2).

La création est relativement aisée via az cli.

Pour identifier si notre cluster gère sa propre zone DNS, il suffit de regarder dans le groupe de ressource que l’on trouve dans la section properties.

La présence d’une zone DNS implique une gestion par le cluster, puisque ce groupe de ressources est créé par le cluster au moment du provisioning.

On notera au passage que dans ce cas, le cluster a deux valeurs différentes pour le FQDN et le private FQDN.

Ce qui n’est pas le cas du cluster public :

Ou un cluster privé avec FQDN public, pour lequel les deux valeurs sont identiques.

En regardant la zone DNS privée, nous pouvons voir l’enregistrement correspondant à notre cluster.

Pour gérer tout cela avec Terraform, vous pouvez consulter cet ancien article.

Voilà qui clôture notre section sur le cluster privé. Passons à présent à notre dernière option pour l’API server.

Intégration Vnet de l’API server

Comme le nom l’indique, pour cette dernière option, nous intégrons directement l’API server dans un subnet d’un Vnet. Le subnet doit être délégué spécifiquement pour cet usage.

Une chose étrange avec cette option est que le cluster n’est pas nécessairement privé, malgré l’intégration de l’API server dans un subnet, comme indiqué dans la documentation sur le sujet.

De ce fait, on peut se poser la question de l’intérêt de la solution si nous devons maintenir la configuration DNS pour rester privé.

Un élément de réponse peut être identifié sur le schéma. Dans le cas présent, les flux restent à l’intérieur du Vnet, alors que dans un cluster public, ou avec un private endpoint, l’API server est localisé en dehors de celui-ci.

Pour créer un cluster avec API server integration, nous procédons comme suit :

Avec un subnet pour l’API Server qui ressemble à ceci :

L’essentiel à retenir sur les aspects réseaux du plan de contrôle K8S

Dans cet article, nous nous sommes concentrés uniquement sur les aspects réseaux concernant le plan de contrôle Kubernetes.

Deux options sont à notre disposition :

• Le cluster public, avec une protection réseau minimum via des règles de firewall
• Le cluster privé, pour lequel nous privatisons complètement l’API server, ne rendant son accès possible que si l’on peut accéder au vnet contenant le endpoint de l’API server.

Dans ce second cas, le endpoint en question est soit un private endpoint, au sens Azure du terme, soit un endpoint intégré à un subnet, s’appuyant sur l’implémentation d’un subnet dédié.

Enfin, nous avons (re-)vu que l’essentiel de la complexité du private endpoint se joue au niveau de la gestion du DNS, gestion qui peut être notamment simplifiée si l’on opte pour le cluster privé avec public FQDN.

Nous vous donnons rendez-vous bientôt pour la seconde partie de cet article, dans laquelle nous nous concentrerons sur les aspects réseaux du plan de travail.