⚡
Brief IA
›

AX de Google : les ports affichés dans l’egress ne sont pas appliqués

🔬 Research·Tom Levy·

AX de Google : les ports affichés dans l’egress ne sont pas appliqués

AX de Google : les ports affichés dans l’egress ne sont pas appliqués
⚡
Key Takeaways
1Les ports affichés dans les règles d’egress et la CLI d’AX ne sont pas transmis à l’application
2Des configurations comme des passerelles non résolues ou des listes d’autorisation vides peuvent laisser l’egress sans politique active
3Plusieurs recommandations sont données : traiter la passerelle comme une liste d’autorisation de noms d’hôte, retirer le champ de port, éviter les jokers et valider l’état via la CLI
💡Why it matters — Des ports visibles peuvent donner une fausse impression de contrôle, alors qu’ils ne sont pas appliqués, exposant à des ouvertures involontaires.
⚡Le brief IA que lisent les pros

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

📄
Full Analysis

Dans AX, des ports peuvent apparaître dans les règles d’egress et dans la CLI, mais ils ne sont pas transmis à l’application. Des cas d’ouverture involontaire sont décrits, ainsi qu’une série de précautions pour limiter les erreurs de configuration.

Des configurations peuvent laisser l’egress sans politique active

Plusieurs situations sont signalées comme pouvant ouvrir la "clôture" sans le vouloir. Des noms de passerelle non résolus figurent parmi ces cas. Le court-circuitage des jokers est également cité. Enfin, des listes d’autorisation vides peuvent conduire à l’absence de politique envoyée.

Précautions recommandées pour sécuriser les passerelles

Il est recommandé de considérer la passerelle comme une liste d’autorisation de noms d’hôte. Le retrait ou la mise en réserve du champ de port dans les manifestes et schémas est préconisé. L’usage des jokers est à éviter. Avant d’appliquer des tâches, une validation des passerelles via la CLI est conseillée, ainsi que la vérification de la réussite de GatewayReady et de l’application de la politique.

Pourquoi le port affiché n’est pas pris en compte par AX

AX prend un port dans chaque règle d’egress, mais rien en aval ne peut appliquer une règle sur ce port. Dans son dépôt, l’orchestrateur définit un port sur six règles d’egress, que la CLI affiche. Le schéma Gateway/HostRule inclut un champ de port, et manifestes comme CLI peuvent montrer des destinations avec un suffixe de port, par exemple "api.openai.com:443". Cependant, le format de transmission utilisé vers la couche d’application ne transporte aucune information de port. La correspondance de destination ne s’opère que par nom d’hôte ou par adresse IP et rejette les URL et noms d’hôte contenant un port. Un script de "vérification de port" retrace la lecture des champs et indique que la réconciliation d’AX et l’affichage de la CLI induisent en erreur : les valeurs de port survivent au schéma et à l’affichage mais n’arrivent jamais jusqu’à l’application.

⚡

Brief IA — L'actualité IA en français

L'essentiel de l'actualité de l'intelligence artificielle, décrypté et expliqué chaque jour.