Pod, nœud ou cluster : ce qu'un sidecar VPN redirige réellement

Un sidecar VPN dans un Pod Kubernetes ressemble à un VPN au niveau de l'hôte avec de meilleures manières, et la ressemblance s'arrête à la frontière de l'espace de noms. Les conteneurs d'un Pod partagent l'espace de noms réseau, y compris l'espace d'adresses et de ports, donc un sidecar qui installe des routes et des politiques change réellement la destination des paquets de l'application. Il ne change rien pour les autres Pods du nœud, et il ne touche pas la pile propre du nœud sauf si vous le configurez ainsi. Bien cerner cette frontière détermine à la fois ce que vous pouvez déployer et ce que vous devez tester. Les sections suivantes la suivent de l'espace de noms vers l'extérieur.

Espace de noms partagé, conséquences partagées

Deux conteneurs d'un Pod communiquent via loopback et voient les mêmes interfaces, et c'est pourquoi le modèle du sidecar fonctionne : l'application n'a pas besoin de savoir qu'un tunnel existe, car la route qu'elle résout a été installée dans l'espace de noms qu'elle utilise. La même propriété signifie que les erreurs du sidecar sont celles de l'application. Une route qui capture trop, ou un changement de DNS qui pointe vers un résolveur à l'intérieur du tunnel, s'applique immédiatement à chaque processus de ce Pod. Dans un espace de noms partagé, il n'y a pas de routage par conteneur, donc un sidecar ne peut pas être limité à un seul processus.

C'est le mécanisme à garder en tête lors de la revue : le rayon d'impact est le Pod, pas le nœud ni le cluster.

Ce que le sidecar n'atteint pas

Les autres Pods conservent leurs propres espaces de noms et leur propre routage, donc une charge de travail qui a besoin de la même sortie a besoin du même sidecar ou, à défaut, d'une conception au niveau du nœud. Le trafic du nœud est lui aussi hors de l'espace de noms du Pod, et les Pods en réseau hôte renoncent délibérément à cette isolation. Si vous exécutez le sidecar en réseau hôte pour atteindre quelque chose de pratique, vous avez élargi la portée d'un Pod à tout le nœud et vous devriez le dire à voix haute.

Le trafic vers les services du cluster est l'autre surprise courante. Une route par défaut large dans le Pod peut capturer des requêtes destinées au serveur d'API ou à un service ClusterIP, qui échouent ensuite d'une manière qui ressemble à un tunnel cassé.

Plan de routes : plages Pod, service, nœud et VPN

Notez les quatre plages et vérifiez leurs chevauchements avant de déployer quoi que ce soit : CIDR du Pod, CIDR du service, adresses du nœud et destinations derrière le VPN. Le chevauchement entre les plages privées du VPN et l'espace propre au cluster n'est pas rare, et une route par défaut est la mauvaise solution. Le plan de routes appartient au même dépôt que le manifeste, car le prochain cluster peut attribuer des plages de Pods et de services complètement différentes.

Le DNS fait partie du plan et non d'une préoccupation séparée. Un sidecar qui réécrit la configuration du résolveur peut casser la découverte de services dans le cluster tout en faisant fonctionner parfaitement les requêtes externes.

Le démarrage et la panne sont des états explicites

Un processus sidecar en cours d'exécution n'est pas une politique de sortie. Décidez quel trafic peut circuler avant que le tunnel soit prêt et ce qui se passe s'il meurt ensuite, puis mettez cette décision en œuvre : une sonde qui conditionne le conteneur applicatif, une politique réseau qui refuse par défaut, ou les deux. Sans l'une des deux, l'application démarre, résout et émet du trafic hors du chemin normal du nœud pendant que le tunnel se connecte encore.

Cet écart est bref dans un cluster sain et permanent dans un cluster cassé, et c'est exactement la propriété que préfère un attaquant ou une fuite de données accidentelle.

Associez l'ordre à un test de panne. Tuez le sidecar et confirmez que l'application perd sa sortie prévue au lieu de retomber silencieusement en arrière.

Capacités, politiques et tests depuis le conteneur applicatif

Accorder les capacités nécessaires pour créer des interfaces et modifier des routes est une décision de privilèges, et un privilège adapté à un Pod isolé ne l'est pas automatiquement sur la pile du nœud. Utilisez les mécanismes de politique réseau et de sécurité pris en charge par le cluster, et ne supposez pas que chaque implémentation de CNI ou de politique traite une interface VPN de la même façon ; les différences apparaissent précisément dans les cas de panne qui vous intéressent.

Testez depuis le vrai conteneur applicatif, avec des requêtes neuves vers une destination privée, un service du cluster et l'internet public. Un test depuis le sidecar prouve que le tunnel fonctionne, pas que l'application atteint ce dont elle a besoin.

Documentez les hypothèses réseau du cluster à côté de la configuration VPN. Déplacer la charge de travail vers un autre cluster devient alors un exercice de vérification du plan de routes plutôt qu'un changement d'image qui cesse silencieusement de fonctionner.