kubectl fonctionne via le VPN, mais la mise à l’échelle AKS s’arrête : pourquoi

Vous ajoutez l’adresse publique du VPN du bureau à la liste d’autorisation du serveur d’API AKS, et kubectl fonctionne. Une semaine plus tard, la montée en charge d’un pool de nœuds échoue, une tâche CI ne parvient plus au cluster, et le portail affiche une erreur qui ne mentionne rien des plages IP. Personne n’a modifié la liste d’autorisation. Le contrôle que vous avez activé est un filtre d’IP publique devant le serveur d’API, et il ne sait pas qui appelle, seulement de quelle adresse vient l’appel. Le VPN est une adresse parmi plusieurs dont le cluster a besoin, et c’est rarement celle qui casse en premier.

La liste d’autorisation correspond à une adresse, pas à une personne

--api-server-authorized-ip-ranges prend des blocs CIDR, pas des utilisateurs ni des groupes. Lorsqu’une requête de développeur quitte le serveur VPN pour Azure, l’adresse source au serveur d’API est la sortie publique du serveur VPN. Chaque personne sur ce VPN partage donc une seule entrée, et quiconque est hors du VPN est refusé avant même l’authentification.

Cela signifie aussi que l’entrée admet plus de personnes que vous ne le souhaitez peut-être. Un prestataire disposant d’un accès VPN, un ordinateur portable personnel sur le même concentrateur et un compte compromis arrivent tous de la même adresse. L’autorisation du cluster reste inchangée, donc le contrôle d’accès basé sur les rôles décide toujours de ce que l’appelant peut faire, mais la liste d’autorisation n’est pas un contrôle d’identité et ne devrait jamais être décrite comme tel.

Ce qui casse en premier n’est généralement pas kubectl

La liste d’autorisation s’applique au point de terminaison public du serveur d’API, donc tout ce qui se trouve hors de vos adresses listées cesse de fonctionner immédiatement. Les victimes évidentes sont le second bureau sans route VPN, un runner CI dans un pipeline hébergé et un ordinateur portable qui a oublié de se connecter. Ils sont faciles à reconnaître parce qu’un humain attend.

Le cas moins évident est l’automatisation pilotée par Azure ou vos propres outils. Certaines opérations lancées par la plateforme atteignent le serveur d’API depuis des adresses qui ne sont pas votre VPN, et quand l’une d’elles commence à échouer juste après le durcissement de la liste, le moment est l’indice. Ne supposez pas que la liste est complète parce que l’accès interactif fonctionne ; vérifiez ce que la fonctionnalité exige pour votre région et vos abonnements avant de conclure que le cluster est cassé.

La signature de l’échec aide. Si la requête n’atteint jamais l’authentification, c’est le filtre. Si elle s’authentifie puis reçoit une erreur de permission, le filtre a fait son travail et le problème est le contrôle d’accès basé sur les rôles, que la liste d’autorisation ne touche jamais.

Construisez la liste entière en une seule commande

Le paramètre de mise à jour remplace la liste entière au lieu d’ajouter une entrée, donc une commande qui ne porte que l’adresse VPN supprime silencieusement tout le reste. Lisez d’abord la valeur actuelle, conservez-la et envoyez l’union :

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

Utilisez une IP publique réservée pour le serveur VPN avant de vous appuyer dessus. Une adresse dynamique change à la reconnexion, et chaque changement enferme discrètement l’équipe hors du cluster jusqu’à ce que quelqu’un mette à jour la liste depuis un réseau encore autorisé. Si vous avez deux points de sortie VPN pour la redondance, listez les deux, car le filtre n’a aucune notion de chemin préféré.

Ordonnez le changement pour que la première tentative autorisée soit aussi le test. Annoncez la nouvelle liste, appliquez-la et connectez-vous immédiatement depuis le VPN ; dans l’ordre inverse, une fenêtre subsiste où personne ne peut atteindre le serveur d’API pour corriger une faute de frappe dans un bloc CIDR.

Ce que la liste d’autorisation n’a jamais couvert

Elle ne rend pas le serveur d’API privé. Un cluster privé utilise un point de terminaison privé et un DNS privé, et la liste des plages autorisées n’est pas le contrôle qui le remplace. Elle ne change pas non plus ce qu’un appelant admis peut faire, donc un kubeconfig d’administrateur divulgué fonctionne encore depuis toute adresse autorisée. Traitez l’identifiant comme la frontière de sécurité et la liste comme une commodité réseau.

Elle n’a rien à voir avec les charges de travail. Les pods et les services continuent de fonctionner avec la liste activée, et atteindre une application via le VPN est un problème distinct: un service qui ne dispose que d’une IP de cluster a encore besoin d’un équilibreur de charge interne, d’un ingress ou d’un port-forward avant qu’un ordinateur portable puisse l’ouvrir. Mélanger ces deux conceptions produit un ticket de changement qui prétend restreindre les développeurs et ne restreint en réalité rien des applications.

Vérifiez des deux côtés, puis exécutez une vraie opération

Testez avec un client neuf sur le VPN et avec un client à l’extérieur. La tentative extérieure doit être refusée au serveur d’API, pas à la résolution de noms ; si le nom ne se résout pas, vous testez le DNS et vous n’avez rien appris sur le filtre. Exécutez ensuite une opération qui n’est pas un appel kubectl interactif, comme la mise à l’échelle d’un pool de nœuds ou une vérification de mise à niveau, et confirmez qu’elle aboutit au lieu de le supposer.

Conservez la valeur précédente de la liste à côté du changement, et relisez la valeur effective après la mise à jour au lieu de faire confiance à la commande tapée. La documentation sur les plages IP autorisées d’AKS répertorie les paramètres pris en charge et les exigences de plateforme qui doivent figurer dans la même liste, ce que la plupart des descriptions de ticket omettent.