Google AX: Egress Rules Ignored in Implementation

In Google AX, egress policies can include a port with the host, but this port is not taken into account when applying the rules. The protocol sent to Substrate does not include a port field, which can lead to permissive behaviors. Recommendations specify how to configure and verify network egress.

Permissive Behaviors and Necessary Checks

Situations where the egress policy becomes permissive are observed when gateway names are absent or unresolved. The use of generic shortcuts can lead to total permissions, while empty allowlists do not send any egress policy. It is recommended to validate the GatewayReady state, avoid wildcards and empty lists, and ensure that the cluster egress matches expectations by consulting the compiled policy. It is also advisable to consider Gateway as an allowlist based solely on the host name and to remove the port field from manifests and documentation.

The Port Disappears Between the Manifest and Substrate

The Gateway schema allows for declaring host and port pairs in manifests, but the compiled protocol sent to the Substrate Agent does not contain a port field. Code tracing and an inspection script show that the port is read and displayed by the CLI, but it is not retained in the application rule, where only host names or IP addresses are considered. This situation is illustrated by six egress rules defined with a port in the repository, all of which result in a transmission format without a port.

Substrate Never Evaluates the Port

Substrate internally extracts a port value from the destination authority, but the rule evaluation logic does not use it. Host name matching explicitly rejects strings containing a port, such as "api.openai.com:443", preventing this type of bypass. Thus, even though AX accepts a port in each egress rule, no downstream component enforces a constraint on the port.