Google AX : le port des règles d’egress ignoré en application
Le brief IA que les pros lisent chaque soir
Les 7 actus IA du jour, décryptées en 5 min. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisis ton rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
Dans Google AX, les politiques d’egress peuvent inclure un port avec l’hôte, mais ce port n’est pas pris en compte lors de l’application des règles. Le protocole transmis à Substrate ne comporte pas de champ de port, ce qui peut entraîner des comportements permissifs. Des recommandations précisent comment configurer et vérifier les sorties réseau.
Des comportements permissifs et des vérifications nécessaires
Des situations où la politique d’egress devient permissive sont observées lorsque des noms de passerelle sont absents ou non résolus. L’utilisation de raccourcis génériques peut aboutir à des autorisations totales, tandis que des listes d’autorisation vides n’envoient aucune politique d’egress. Il est recommandé de valider l’état GatewayReady, d’éviter les jokers et les listes vides, et de vérifier que la sortie du cluster correspond bien aux attentes en consultant la politique compilée. Il est également conseillé de considérer Gateway comme une liste d’autorisation fondée uniquement sur le nom d’hôte et de retirer le champ de port des manifestes et de la documentation.
Le port disparaît entre le manifeste et Substrate
Le schéma Gateway permet de déclarer des couples hôte et port dans les manifestes, mais le protocole compilé transmis à Agent Substrate ne contient pas de champ de port. Un traçage du code et un script d’inspection montrent que le port est lu et affiché par la CLI, mais il n’est pas conservé dans la règle d’application, où seuls les noms d’hôte ou adresses IP sont pris en compte. Cette situation est illustrée par six règles d’egress définies avec un port dans le dépôt, qui aboutissent toutes à un format de transmission sans port.
Substrate n’évalue jamais le port
Substrate extrait en interne une valeur de port à partir de l’autorité de destination, mais la logique d’évaluation des règles ne l’utilise pas. La correspondance des noms d’hôte rejette explicitement les chaînes contenant un port, comme "api.openai.com:443", ce qui empêche ce type de contournement. Ainsi, même si AX accepte un port dans chaque règle d’egress, aucun composant en aval n’applique de contrainte sur le port.
Brief IA — L'actualité IA en français
L'essentiel de l'actualité de l'intelligence artificielle, décrypté et expliqué chaque jour.