Brief IA : Google AX : le port des règles d’egress ignoré en application

Google AX : le port des règles d’egress ignoré en application

Brief IA
Tom Levy·2 min·0 vues

Dans Google AX, le protocole d'egress transmis à Substrate ne comporte pas de champ de port, ce qui signifie que les contrôles basés sur le port ne s'appliquent pas. Cela peut entraîner des comportements permissifs, notamment lorsque des noms de passerelle sont absents ou non résolus. Il est donc recommandé de vérifier la politique compilée et de traiter Gateway comme une allowlist d'hôtes sans port.

En bref
1Le protocole d’egress d’AX transmis à Substrate ne comporte pas de champ de port
2Des raccourcis génériques et des listes vides peuvent rendre la politique permissive
3Il est conseillé de traiter Gateway comme une allowlist d’hôtes sans port et de vérifier la politique compilée
💡Pourquoi c'est importantLe port défini dans les règles n’étant pas pris en compte, les contrôles basés sur le port ne s’appliquent pas ; il faut adapter la configuration et vérifier la politique effective.
Le brief IA que lisent les pros

La recherche en IA te passionne ?

Les papers et avancées qui comptent, expliqués simplement, chaque soir. 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

📄
L'analyse en français

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.

Suivez Brief IA

L'actu IA du jour, aussi dans votre fil.

Commentaires