Skip to main content
By default, Astro Private Cloud (APC) provides access to Astro services through the built-in NGINX ingress controller. You can instead attach the platform to an Istio Gateway that you already run. APC then suppresses every platform Ingress and renders a VirtualService in place of each one.
Astro Private Cloud 2.2This feature was introduced in Astro Private Cloud 2.2. To access this feature, upgrade your Astro Private Cloud installation to 2.2 or later.
The Astronomer Helm chart neither installs Istio nor creates the Gateway. You install and manage both yourself, and APC attaches its VirtualService resources to the Gateway you name.

​
Prerequisites

  • Istio installed on both your control plane cluster and your data plane cluster. See the Istio installation documentation.
  • Access to the values.yaml file on both your control plane cluster and your data plane cluster.
  • Permission to apply platform Helm configuration changes. See Apply a config change.

​
Route traffic through a Gateway

1

Create or identify your Gateway

APC attaches its VirtualService resources to a Gateway resource that you manage. To list the existing Gateways, run:
You need the Gateway’s namespace and name in the form <namespace>/<name>, such as istio-system/default-gateway. If no suitable Gateway exists, create one that serves your APC base domain on port 443 with your TLS certificate. See the Istio Gateway reference for the resource specification.
2

Update your platform values

Add the following configuration to the values.yaml file on both your control plane cluster and your data plane cluster:
Setting global.nginx.enabled: false disables the NGINX subchart because the Gateway handles inbound traffic instead.
3

Apply the configuration change

Apply your updated values.yaml file to each cluster. See Apply a config change for the full procedure, including how to retrieve your current configuration first.
4

Verify that APC created the VirtualService resources

On each cluster, run:
Confirm that the platform hosts appear and that each VirtualService references the Gateway you configured. Then confirm that you can reach the APC UI at your base domain.

​
Name an existing Gateway

global.istio.gateway.name takes the <namespace>/<name> of a Gateway that you created. It has no default. You set it in Update your platform values.
The Gateway you name must already exist. The Kubernetes API server accepts a VirtualService that points at a missing Gateway, and that VirtualService silently routes no traffic. You get no error, and the platform hosts don’t resolve. Rendering fails if global.istio.gateway.enabled is true and name is empty.

​
Enable the auth sidecar

The auth sidecar is required when you route traffic through a Gateway. The Gateway handles traffic outside the platform, so the auth sidecar is the only component that authenticates the platform hosts. Set global.authSidecar.enabled: true as shown earlier. For the other sidecar options, see Auth sidecar (OpenShift).
Rendering fails if global.istio.gateway.enabled is true and global.authSidecar.enabled is false. The chart fails the render deliberately to avoid publishing the platform hosts without authentication.
The APC MCP server isn’t supported with an Istio Gateway in this release, because the server’s authentication gate exists only on the built-in NGINX ingress controller. On a control plane or unified plane, rendering fails if astronomer.mcpServer.enabled and global.authSidecar.enabled are both true. See Stated limitations.

​
Configuration reference