Network and ports

Status: the network rules are written and tested as rendered configuration. They have not yet been applied to or observed in a real cluster. Ports are the chart defaults and can be changed in the chart values. Confirm them with your Heliast contact before you write firewall rules.

The request path

A client request reaches the Envoy front door over HTTPS. Requests under /oauth2/ go to oauth2-proxy, which is the only component that talks to your identity provider. Requests under /v1 and / go to the router, which exposes an OpenAI-compatible interface.

Before the router forwards a request to the model server it calls the enforcement hook, and after the response it reports back to the hook. The hook checks identity, model admission and policy, and writes the audit record before it answers. Both hook calls carry a shared token, and the hook accepts no caller without it.

The hook's endpoints are reachable inside the cluster only. They are not routed through the front door.

Ports

All ports are inside the cluster except the first two.

Notes:

• Retrieval ingestion runs as a batch job and has no listener.
• A Postgres metrics port appears in the chart values but nothing listens on it. Do not open it.
• Rate-limit and session stores (Redis) are not part of this release.
• The monitoring stack runs inside the cluster. No component sends monitoring data to a hosted service.

Who talks to whom

In the chart, network policies narrow the paths further.

• The router accepts connections from the enforcement hook pod only, on its HTTP port.
• The enforcement hook accepts connections from the router pod only, on its port.
• The router may reach cluster DNS, the hook, the model server, your identity provider and any endpoint you have explicitly allowed (next sections).
• A separate policy allows the front door to receive traffic from the client address ranges you name when you apply the baseline. If you name none, that policy is not created.

Default-deny egress

The Terraform network baseline applies a deny-all policy to the Heliast namespace, for inbound and outbound traffic. The only outbound path open by default is:

• cluster DNS, to the Kubernetes system namespace on port 53, which stays inside the cluster; and
• your identity provider, as one explicit address range and port.

With no model provider configured, the allow-list is exactly one entry, your identity provider. Nothing else can leave the cluster. The module refuses an allow-any rule such as 0.0.0.0/0, a non-HTTPS entry or a duplicate name. There is no port for a management link: any management channel is outbound-only and started by you.

Adding an endpoint

Every endpoint outside the default is an explicit allow.

A hosted model provider. Each provider is described in a provider configuration file kept in your Git repository beside your policy. The file names the provider, a reference to its credential (never the key itself), the models it serves, and one egress entry with an HTTPS address range and port. The allow-list then has your identity provider plus exactly one entry per enabled provider. The entries are generated from the provider files, not written by hand. A provider marked disabled adds nothing, and removing a provider removes its entry. Requests to a provider still pass through the hook for identity, admission and policy, and are written to the audit ledger. Provider credentials stay on the server side and never reach users.

A model you serve yourself. A model on an endpoint inside your estate is added to the router's chart values with a name, a class (assessed or registered, never admitted), a URL and an address range and port. The same endpoint must also be added to the baseline module's client model input. That input renders a separate TCP-only policy that applies to the router pod alone and refuses any range broader than a /8 for IPv4. Nothing yet checks that the chart and the baseline name the same endpoints, so a mismatch shows up only as a connection that fails at run time. Keep the two in step by hand.

What your network team opens

1. Inbound to the front door on TCP 8443 (and 8080 if you want the redirect) from your client networks.
2. Outbound from the cluster to your identity provider on its HTTPS port.
3. Outbound to each hosted model provider you choose to enable, for that provider's address range and port only.
4. Outbound to each self-served model endpoint outside the cluster network, if any.
5. Access from the cluster to the Git repository that holds your policy, and to the source of your model weights, when the deployment pipeline runs. The pipeline stages that fetch them run from the operator's host. Confirm with your Heliast contact which host needs this access.
6. Nothing else. Heliast has no required connection back to Heliast.

Limits

• No network policy has been observed enforcing in a real cluster. The tests check the rendered configuration.
• The router has not been run against the committed chart in a real estate, so the routing path is tested against a stand-in.
• Rate limiting belongs to the router. A request rejected by a rate limit is rejected before the hook and writes no ledger row.