Google AX: Ports Displayed in Egress Are Not Applied

In AX, ports may appear in egress rules and in the CLI, but they are not transmitted to the application. Cases of unintentional openings are described, along with a series of precautions to limit configuration errors.

Configurations Can Leave Egress Without an Active Policy

Several situations are reported that could inadvertently open the "fence." Unresolved gateway names are among these cases. The bypassing of wildcards is also mentioned. Finally, empty allow lists can lead to the absence of a policy being sent.

Recommended Precautions to Secure Gateways

It is recommended to treat the gateway as a whitelist of hostnames. Removing or reserving the port field in manifests and schemas is advised. The use of wildcards should be avoided. Before applying tasks, validating gateways via the CLI is recommended, as well as checking the success of GatewayReady and the application of the policy.

Why the Displayed Port Is Not Considered by AX

AX takes a port in each egress rule, but nothing downstream can apply a rule on that port. In its repository, the orchestrator defines a port on six egress rules, which the CLI displays. The Gateway/HostRule schema includes a port field, and manifests as well as the CLI can show destinations with a port suffix, for example, "api.openai.com:443." However, the transmission format used to the application layer does not carry any port information. Destination matching occurs only by hostname or IP address and rejects URLs and hostnames containing a port. A "port check" script traces the reading of fields and indicates that the reconciliation of AX and the CLI display is misleading: port values survive the schema and display but never reach the application.