FAIS-LE BIEN DÈS LE DÉPART (Partie 2/3)

1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Un écosystème vaste – Exposition

Kubernetes propose une multitude de solutions pour exposer ses services.

On retrouve trois grandes catégories :

Service Proxy (Ingress Controller & Load Balancer) : Permet d’exposer des workloads vers l’extérieur. Exemples : NGINX, Envoy, Traefik
API Gateway : Gestion avancée des API et du trafic. Exemples : Kong, Tyk, Azure APIM
Service Mesh : Facilite la communication entre microservices dans un environnement multi-cluster. Exemples : Istio, Consul, Linkerd

💡 À retenir :

Commencez simple avec un Ingress Controller.
Passez à un API Gateway si vous gérez des API.
Adoptez un Service Mesh uniquement si vous avez des besoins multi-clusters avancés.

Sans ces solutions, les applications ne seraient pas accessibles, et la segmentation réseau serait quasi impossible.

Landscape de la CNCF

Intégrer le tout dans une architecture Azure

L’intégration d’AKS dans Azure nécessite de respecter les contraintes réseau et de sécurité existantes. Il est crucial de bien planifier l’architecture dès le départ.

Un cluster par environnement : Dev, Préprod, Prod, pour garantir l’isolation.
Privatisation du cluster : Utilisation d’un Private AKS si les ressources internes ne doivent pas être exposées publiquement.
Gestion de l’évasion Internet : L’accès sortant doit être centralisé via un Azure Firewall ou une NVA, ce qui doit être décidé avant la création du cluster.
Intégration réseau : Peerings, segmentation des sous-réseaux et filtrage du trafic sont essentiels pour éviter latences et problèmes de connectivité.

3. UNE EXPOSITION PUBLIQUE À MAITRISER

Le control plane AKS est un composant critique : c’est lui qui orchestre le bon fonctionnement de tout le cluster
Par défaut, il est accessible publiquement, ce qui représente un risque de sécurité important

🧩 De quoi est composé le Control Plane ?

API Server : Il agit comme le point d’entrée principal pour toutes les communications avec Kubernetes.
Scheduler : Il attribue les charges de travail aux nœuds en fonction de leurs ressources et des contraintes définies.
Controller Manager : Il exécute les boucles de contrôle pour maintenir l’état désiré du cluster.

Le control plane :

Est public par défaut
Accessible à tous par défaut
C’est à nous d’imposer la sécurité
Est accessible depuis Internet (par défaut)
Dispose de privilèges élevés sur les worker nodes

Les worker nodes :

Consomment des adresses IP privées sur notre VNET
Sont pilotés par le control plane depuis l’extérieur
Ont besoin d’accéder à Internet
Utilisent un Azure Load Balancer pour l’évasion Internet (par défaut)
Utilisent un Azure Load Balancer pour gérer l’exposition des workloads

🛡️Maîtriser l’exposition publique du Control Plane

Objectif : réduire l’exposition de l’API Server

Plusieurs solutions existent pour réduire cette exposition

Le Control Plane est public

Le Control Plane AKS est exposé par défaut via :

Son nom DNS public : *.azmk8s.io
Des adresses IP publiques attribuées automatiquement

Possibilités de filtrage :

1. Allowed IPs (IP authorized ranges)

On peut configurer une accept list d’adresses IP autorisées à interagir avec le serveur API AKS.

Cela signifie que :

Tu peux contrôler l’accès à l’instance PaaS via l’IP publique du client.
Ou autoriser l’accès depuis des machines hébergées dans un VNET, à condition qu’elles sortent sur Internet avec une IP publique spécifique.

💡 Mais attention : si le subnet utilise la configuration par défaut, les machines peuvent sortir sur Internet avec une IP publique dynamique attribuée par Azure, ce qui rend l’accès difficile à contrôler précisément

➡️ Résultat : tu devras autoriser un pool d’IP publiques régionales dans l’accept list, ce qui est complexe à maintenir et peu fiable du point de vue sécurité.

2. Service Endpoints

Service Endpoints permettent à une ressource dans un VNET de consommer une ressource PaaS en passant par le backbone Azure, sans passer par Internet.

Mais dans le cas d’AKS :

L’instance PaaS reste toujours attachée au DNS public Azure
L’exposition à Internet n’est pas totalement supprimée
Et cela ne répond pas aux exigences d’architecture privée stricte

➡️ Solution jugée insuffisante en contexte sécurisé

✅ Solution recommandée : Private AKS avec PrivateLink

Le domaine PaaS reste public (azmk8s.io), mais :

Le sous-domaine de ton cluster est privé
L’accès se fait uniquement depuis le VNET du cluster ou des peerings
L’API Server est non accessible publiquement

💡 Attention : cette configuration a des impacts :

Pour utiliser kubectl, ton poste doit être dans le réseau (ou passer par un bastion/vpn)
Les chaînes CI/CD doivent avoir accès au VNET

Control Plane VNET integration (preview)

Azure propose une nouvelle option permettant d’intégrer directement le control plane dans le VNET du cluster.

• Projeter l’API server dans le VNET

Implique un Subnet dédié
Tous les flux sont maintenant privés
Actuellement en preview

4. GESTION DES FLUX EGRESS

LoadBalancer OutboundType

Le choix du mode de sortie des flux réseau est un point clé pour garantir une bonne connectivité des workloads tout en maîtrisant leur exposition.

• Repose sur un Load Balancer public

Implique une adresse IP publique
Gestion de l’évasion Internet (Outbound Rule)
Accès à l’API Server pour les worker nodes
Gestion de l’exposition publique (service)
Limité par l’allocation de ports aux node pools

User-Defined route OutboundType

L’optimisation du routage des flux sortants permet de rediriger le trafic vers des équipements réseau spécifiques pour une meilleure sécurité.

• Routage du flux vers Azure Firewall / NVA

Routage du flux sortant vers un équipement central
Toujours un Load Balancer public mais pas en frontal

⚠️ Destinations inconnues à l’avance : Lors de la création du cluster AKS, certaines adresses IP et FQDN ne sont pas encore générés, rendant difficile la configuration initiale des règles firewall.

Le routage asymétrique peut être un point de complexité important dans les architectures réseau avancées.

• Gestion du routage asymétrique

ByPass Azure/Firewall / NVA pour accéder à l’IP Publique du Load Balancer
Mise en place d’une règle de DNAT pour exposer le Load Balancer

NAT Gateway / HTTP Proxy OutboundTypes

L’utilisation d’une NAT Gateway ou d’un proxy HTTP permet une meilleure maîtrise des flux sortants et une gestion optimisée des adresses IP publiques.

• NAT Gateway Outbound type

Deux formes : Managed NAT Gateway / User-Assigned NAT Gateway
Bypass limitation NAT Port exhaustion
Remplace le Load Balancer public
Mais toujours IP publique
Tout en supportant l’auto-scale (Public IP Prefixes)

• User HTTP Proxy Outbound type

Configuration uniforme entre tous les node-pools
Pas de support de l’authentification
Pas disponible pour les node pools Windows

Filtrage des flux sortants

Un filtrage efficace des flux egress est nécessaire pour renforcer la sécurité et éviter les fuites de données.

Destination Endpoint	Protocol	Port	Use
ServiceTag – `AzureCloud.<Region>:1194`	UDP	1194	Tunnel sécurisé entre les nœuds et le control plane
ServiceTag – `AzureCloud.<Region>:9000`	TCP	9000	Tunnel de communication (Azure AKS managed infra)
*`:123`**	UDP	123	Synchronisation NTP sur les nœuds Linux

La mise en place de règles de filtrage précises permet de réduire les risques d’exposition des workloads

Destination Endpoint	Protocol	Port	Use
Custom DNS IP	UDP	53	Accès aux serveurs DNS personnalisés par les nodes du cluster.
API Server Public IP	TCP	443	Connexion aux services Kubernetes (pour certains pods ou outils)

📎 Référence : Contrôle des flux sortants dans AKS (Microsoft)

5. GESTION DES FLUX INGRESS

In-House Kubernetes Gateway API

L’exposition des services au sein d’AKS nécessite une Gateway API permettant un contrôle fin des accès et du routage du trafic vers les workloads Kubernetes.

• Chaque cluster s’expose

Via une Gateway
Choisissez votre fournisseur en fonction des besoins et de l’intégration souhaitée
Solution Cloud-Native permettant une gestion unifiée du trafic
Implique de la maintenance et de la supervision
Séparation claire des responsabilités entre le réseau et les applications

Azure Application Gateway for Containers

Microsoft propose une solution managée pour Kubernetes qui s’intègre parfaitement avec AKS en fournissant un contrôle avancé du trafic réseau.

• Implémentation Azure de la Kubernetes Gateway API

Service Azure mais aligné sur une approche « Cloud-Native »
Deux scénarios de déploiement : Bring Your Own (BYO) ou Managed
Entièrement piloté depuis AKS, facilitant l’automatisation et l’orchestration
Nécessite un subnet dédié pour un déploiement optimal et sécurisé

Intégration dans une architecture réseau Azure

Une stratégie réseau efficace inclut :

🟢Exposition maîtrisée : Private Cluster, PrivateLink
🟢Sortie centralisée : Azure Firewall via UDR
🟢Privatisation des flux entre composants
🟢Architecture DNS centralisée
Et bien sûr : segmentation réseau, qu’on verra en Partie 3 😉

PROCHAIN ARTICLE

👉 Dans la prochaine partie, on continue à creuser l’univers réseau d’AKS avec un sujet tout aussi stratégique : le dimensionnement et la segmentation réseau.

On abordera des points clés comme :

Comment calculer proprement les besoins en adresses IP
Éviter les pièges de sous-réseaux trop petits ou mal planifiés
Segmenter intelligemment son réseau pour sécuriser les workloads
Et mettre en place des Network Policies efficaces et maintenables 🔐

Spoiler alert ⚠️ : une mauvaise estimation des IPs ou un mauvais choix de CNI peut bloquer tes déploiements.

On va voir comment éviter ça, avec des exemples concrets et des bonnes pratiques à appliquer dès le départ.