Architecture-center: Sécuriser le flux réseau - Comment cela fonctionnera-t-il

Merci pour le signalement - ce problème est en cours d'examen. Il s'agit d'un ID de bogue DevOps interne de Microsoft AB#271079

Merci d'avoir contacté @melzayet. Les deux flux de trafic ont des origines distinctes. Le flux supérieur (vert) est le trafic HTTP destiné aux charges de travail de votre cluster (l'application Web/l'API, etc.) s'exécutant sur les nœuds du cluster. la réponse HTTP pour ces demandes sortira vers le WAF et le client.

Le flux inférieur (orange) est le trafic provenant du sous-réseau contenant les nœuds. Il s'agirait du trafic sortant vers des registres de conteneurs externes, le serveur d'API Kubernetes, etc. Fondamentalement, tout trafic provenant de clusters que nous souhaitons protéger avec nos règles de pare-feu de sortie d'entreprise.

Étant donné que le trafic provient de l'extérieur du réseau régi par UDR et que nous utilisons l'équilibreur de charge _interne_ dans un sous-réseau distinct, il prend le même chemin de retour. La règle UDR s'applique au trafic provenant de son champ d'application.

De plus, pour être clair, cette solution présentée résout le verrouillage de sortie (tel que défini comme le trafic provenant du cluster) uniquement, elle ne canalise pas à la fois l'entrée et la sortie à travers le pare-feu.

Je suppose que la partie DNAT dont vous parlez provient de cette section de la documentation AKS (en particulier celle-ci ). Dans ce cas, ils forcent également tout le trafic entrant à traverser également le pare-feu. Dans leur cas, ils utilisent un équilibreur de charge _public_ pour l'entrée, notre solution n'utilise PAS d'équilibreur de charge public pour l'entrée. Nous prenons contact avec AAG, qui est ensuite acheminé via un équilibreur de charge _interne_ dans un sous-réseau d'entrée dédié, qui ne sera alors pas soumis au problème de routage asymétrique. Si vous exposiez vos services directement via l'adresse IP de l'équilibreur de charge publique, vous rencontreriez certainement le problème de routage asymétrique.

Faites-moi savoir si je peux aider à clarifier davantage - je sais que cela semble un peu "contre-intuitif". N'hésitez pas à déployer en utilisant l'implémentation de référence, à la fin de ce parcours, vous aurez un site Web où le trafic HTTP de charge de travail est géré via la route d'entrée (Client -> WAF -> LB interne -> nodepool -> WAF -> Client) et le trafic provenant du cluster (pool de nœuds -> FW -> ressource externe -> FW -> pool de nœuds) est géré via la route de sortie.

@ckittel Merci d'avoir partagé des idées à ce sujet ! Je vous confie ce problème.

@ckittel merci beaucoup pour la réponse détaillée et informative. Je pense que ma confusion vient du problème d'asymétrie mais vous avez très bien clarifié. Merci encore d'avoir pris le temps