Ingress to ambient mesh

Use Gloo Gateway as the ingress gateway for your ambient mesh.

Looking for instructions on how to use Gloo Gateway as the ingress for a sidecar service mesh? Check out Ingress to Istio sidecar mesh.

About ambient mesh

Solo collaborated with Google to develop ambient mesh, a new “sidecarless” architecture for the Istio service mesh. Ambient mesh uses node-level ztunnels to route and secure Layer 4 traffic between pods with mutual TLS (mTLS). Waypoint proxies enforce Layer 7 traffic policies whenever needed. To onboard apps into the ambient mesh, you simply label the namespace the app belongs to. Because no sidecars need to be injected in to your apps, ambient mesh significantly reduces the complexity of adopting a service mesh.

To learn more about ambient, see the ambient mesh documentation.

About this guide

In this guide, you learn how to use Gloo Gateway as the ingress gateway to route traffic to a single cluster or multicluster ambient service mesh.

The single cluster guide assumes that you run your ambient mesh in a single cluster and want to use Gloo Gateway as the ingress gateway to protect your ambient mesh services.

Gloo Gateway as an ingress gateway to your ambient mesh

The multicluster guide assumes that you have two clusters ($REMOTE_CLUSTER1 and $REMOTE_CLUSTER2) that belong to your ambient mesh, and that Gloo Gateway is also deployed in $REMOTE_CLUSTER1. You use Gloo Gateway to route traffic to the productpage apps that are exposed by a global hostname productpage.bookinfo.mesh.internal.

Gloo Gateway as an ingress gateway to a multicluster ambient mesh

Multicluster ambient requires both a Solo Enterprise for Istio and a Gloo Gateway Enterprise license.

Before you begin

Follow the Get started guide to install Gloo Gateway, set up a gateway resource, and deploy the httpbin sample app.

Get the external address of the gateway and save it in an environment variable.

export INGRESS_GW_ADDRESS=$(kubectl get svc -n gloo-system gloo-proxy-http -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
echo $INGRESS_GW_ADDRESS

kubectl port-forward deployment/gloo-proxy-http -n gloo-system 8080:8080

Single cluster

Set up an ambient in the same cluster where you installed Gloo Gateway and use the gateway proxy as an ingress for the workloads in your ambient mesh.

Step 1: Set up an ambient mesh

Set up an ambient mesh in your cluster to secure service-to-service communication with mutual TLS.

Using Gloo Gateway as a waypoint proxy requires ambient mesh to be installed with Istio version 1.23 or later.

Ambient mesh with the Solo distribution of Istio: Follow the instructions in the Solo Enterprise for Istio documentation to Deploy Istio in ambient mode. These instructions use the Solo distribution of Istio, which is a hardened Istio image provided by Solo. You do not need to create an Istio ingress gateway, as you configure Gloo Gateway as the ingress gateway for your ambient mesh.
Community ambient mesh: You can install the community version of ambient mesh by following the ambient mesh quickstart tutorial. This tutorial uses a script to quickly set up an ambient mesh in your cluster. You do not need to create an Istio ingress gateway, as you configure Gloo Gateway as the ingress gateway for your ambient mesh.

Step 2: Set up Gloo Gateway for ingress

To set up Gloo Gateway as the ingress gateway for your ambient mesh, you simply add all the namespaces that you want to secure to your ambient mesh, including the namespace that your gateway proxy is deployed to.

Add the gloo-system and httpbin namespaces to your ambient mesh. Use the same command to add other namespaces in your cluster. The label instructs istiod to configure a ztunnel socket on all the pods in that namespace so that traffic to these pods is secured via mutual TLS (mTLS).
```
kubectl label ns gloo-system istio.io/dataplane-mode=ambient
kubectl label ns httpbin istio.io/dataplane-mode=ambient
```

Send a request to the httpbin app and verify that you get back a 200 HTTP response code. All traffic from the gateway is automatically intercepted by a ztunnel that is co-located on the same node as the gateway. The ztunnel collects Layer 4 metrics before it forwards the request to the ztunnel that is co-located on the same node as the httpbin app. The connection between ztunnels is secured via mutual TLS.

curl -i http://$INGRESS_GW_ADDRESS:8080/headers -H "host: www.example.com:8080"

Example output:

HTTP/1.1 200 OK
...
{
 "headers": {
"Accept": [
  "*/*"
 ],
 "Host": [
   "www.example.com:8080"
 ],
 "User-Agent": [
   "curl/8.7.1"
 ],
 "X-Envoy-Expected-Rq-Timeout-Ms": [
   "15000"
 ],
 "X-Forwarded-Proto": [
   "http"
 ],
"X-Request-Id": [
   "929c334b-e611-4aba-9bc6-ad6b2450db26"
 ]
  }
}

Port-forward the gloo-proxy-http pod on port 8080.

kubectl port-forward deployment/gloo-proxy-http -n gloo-system 8080:8080

Send a request to the httpbin app and verify that you get back a 200 HTTP response code.

curl -i localhost:8080/headers -H "host: www.example.com"

Example output:

HTTP/1.1 200 OK
...
{
"headers": {
"Accept": [
"*/*"
],
"Host": [
   "www.example.com:8080"
],
"User-Agent": [
   "curl/8.7.1"
],
"X-Envoy-Expected-Rq-Timeout-Ms": [
   "15000"
],
"X-Forwarded-Proto": [
   "http"
],
"X-Request-Id": [
   "929c334b-e611-4aba-9bc6-ad6b2450db26"
]
 }
}

Verify that traffic between the gateway proxy and the httpbin app is secured via mutual TLS. Depending on your setup, you can choose between the following options.

Because traffic in an ambient mesh is intercepted by the ztunnels that are co-located on the same node as the sending and receiving service, you can check the logs of the ztunnels.

Find the NODE that the httpbin app runs on.

kubectl get pods -n httpbin -o wide

Example output:

NAME                       READY   STATUS    RESTARTS   AGE   IP           NODE                                                  NOMINATED NODE   READINESS GATES
httpbin-54cf575757-hdv8t   3/3     Running   0          22h   10.XX.X.XX   gke-gloo-gateway-ambient-default-pool-bb9a8da5-bdf4   <none>           <none>

Find the ztunnel that runs on the same node as the httpbin app.
```
kubectl get pods -n istio-system -o wide | grep ztunnel
```

Check the logs of that ztunnel instance and verify that the source and destination workloads have a SPIFFE ID.

kubectl logs -n istio-system <ztunnel-instance>

Example output:

...
2025-01-08T18:11:18.964684Z	info	access	connection complete	src.addr=10.XX.X.XX:49592 
src.workload="gloo-proxy-http-5577589c6c-jc466" src.namespace="gloo-system"
src.identity="spiffe://gloo-gateway-ambient-mgt/ns/gloo-system/sa/gloo-proxy-http"
dst.addr=10.XX.X.XX:15008 dst.hbone_addr=10.XX.X.XX:8080 dst.service="httpbin.httpbin.svc.cluster.local"
dst.workload="httpbin-54cf575757-hdv8t" dst.namespace="httpbin" 
dst.identity="spiffe://gloo-gateway-ambient-mgt/ns/httpbin/sa/httpbin" direction="inbound" 
bytes_sent=532 bytes_recv=206 duration="5005ms"
...

If you installed Solo Enterprise for Istio, you can use the Gloo UI to verify that traffic between services is secured via mutual TLS.

Port-forward the gloo-mesh-ui service on 8090.

kubectl port-forward -n gloo-mesh --context $MGMT_CONTEXT svc/gloo-mesh-ui 8090:8090

Open your browser and connect to http://localhost:8090.
Go to Observability > Graph.
Verify that you see a lock icon for traffic between the gateway proxy and the httpbin app as shown in the following image.

If you installed Solo Enterprise for Istio, you can open the built-in Prometheus expression browser to verify that traffic between services is secured via mutual TLS.

Port-forward the built-in Prometheus expression browser.

kubectl -n gloo-mesh port-forward deploy/prometheus-server 9091

Open the Prometheus expression browser.

Enter istio_requests_total{destination_workload_namespace="httpbin"} into the query field and review the results. Verify that you see a SPIFFE ID for the source and destination workload and that the connection_security_policy is set to mutual_tls. Example output:

istio_requests_total{app="gloo-telemetry-collector-agent", cluster="gloo-gateway-ambient-mgt", 
collector_pod="gloo-telemetry-collector-79f767f765-bqqhb", component="standalone-collector", 
connection_security_policy="mutual_tls", destination_cluster="gloo-gateway-ambient-mgt", 
destination_principal="spiffe://gloo-gateway-ambient-mgt/ns/httpbin/sa/httpbin", 
destination_service="httpbin.httpbin.svc.cluster.local", destination_workload="httpbin", 
destination_workload_id="httpbin.httpbin.gloo-gateway-ambient-mgt", 
destination_workload_namespace="httpbin", namespace="istio-system", reporter="destination", 
response_code="200", response_flags="-", source_cluster="gloo-gateway-ambient-mgt",
source_principal="spiffe://gloo-gateway-ambient-mgt/ns/gloo-system/sa/gloo-proxy-http", 
source_workload="gloo-proxy-http", source_workload_namespace="gloo-system",
workload_id="gloo-proxy-http.gloo-system.gloo-gateway-ambient-mgt"}

Step 3 (optional): Expose the Bookinfo sample app

Deploy the Bookinfo sample app to your ambient mesh, and verify that Gloo Gateway correctly routes requests to its services.

Add Bookinfo to the ambient mesh

For testing purposes, you can deploy Bookinfo, the Istio sample app, and add it to your ambient mesh. Note that if you already followed the example to deploy Bookinfo in the Solo Enterprise for Istio docs, you can continue to the next section.

Create the bookinfo namespace, and label it with the istio.io/dataplane-mode=ambient label. This label adds all Bookinfo services that you create in the namespace to the ambient mesh.
```
kubectl create ns bookinfo
kubectl label namespace bookinfo istio.io/dataplane-mode=ambient
```

Deploy the Bookinfo app.

# deploy bookinfo application components for all versions
kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/1.23.6/samples/bookinfo/platform/kube/bookinfo.yaml -l 'app'
# deploy an updated product page with extra container utilities such as 'curl' and 'netcat'
kubectl -n bookinfo apply -f https://raw.githubusercontent.com/solo-io/doc-examples/main/istio/sample-apps/productpage-with-curl.yaml
# deploy all bookinfo service accounts
kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/1.23.6/samples/bookinfo/platform/kube/bookinfo.yaml -l 'account'

Verify that the Bookinfo app is deployed successfully.
```
kubectl get pods,svc -n bookinfo
```

Verify that you can access the ratings app from the product page app.

kubectl -n bookinfo debug -i pods/$(kubectl get pod -l app=productpage -A -o jsonpath='{.items[0].metadata.name}') --image=curlimages/curl -- curl -v http://ratings:9080/ratings/1

Example output:

...
< HTTP/1.1 200 OK
< Content-type: application/json
< Date: Tue, 24 Dec 2024 20:58:23 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked
< 
{ [59 bytes data]
100    48    0    48    0     0   2549      0 --:--:-- --:--:-- --:--:--  2666
* Connection #0 to host ratings left intact
{"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}

Route to Bookinfo services

To expose the app to incoming traffic requests, you create an HTTPRoute resource that references the product page microservice.

Create an HTTPRoute resource that defines routing rules for each microservice path.

kubectl apply -n bookinfo -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bookinfo
spec:
  parentRefs:
  - name: http
    namespace: gloo-system
  rules:
  - matches:
    - path:
        type: Exact
        value: /productpage
    - path:
        type: PathPrefix
        value: /static
    - path:
        type: Exact
        value: /login
    - path:
        type: Exact
        value: /logout
    - path:
        type: PathPrefix
        value: /api/v1/products
    backendRefs:
      - name: productpage
        port: 9080
EOF

Verify that Gloo Gateway correctly routes traffic requests to Bookinfo services in your ambient mesh by opening the product page in your web browser.
```
open http://$INGRESS_GW_ADDRESS:8080/productpage 
```

Multicluster

This feature requires both a Solo Enterprise for Istio and a Gloo Gateway license. If you do not have these licenses, contact an account representative. For more information, see the version compatability matrix.

Set up a multicluster ambient mesh and expose apps across multiple clusters with a global hostname. Then, use your gateway proxy to load balance ambient mesh traffic across your clusters.

This guide assumes that you have two clusters, ${REMOTE_CLUSTER1} and ${REMOTE_CLUSTER2}, that you want to install ambient meshes in and link together. Gloo Gateway is installed in ${REMOTE_CLUSTER1} alongside your ambient mesh workloads. To try out the multicluster routing capabilities, you deploy the Bookinfo app in both clusters. Then, you expose the productpage app across clusters with a global hostname, productpage.bookinfo.mesh.internal. Gloo Gateway uses the global hostname to route traffic to the productpage apps in both clusters.

Step 1: Set up a multicluster ambient mesh

Follow the multicluster ambient mesh setup guide in the Solo Enterprise for Istio documentation to install ambient in two clusters, ${REMOTE_CLUSTER1} and ${REMOTE_CLUSTER2}. The steps include setting up a shared root of trust, installing ambient in each cluster, and linking both clusters to create your multicluster ambient mesh. You can choose between the following installation methods:
- Gloo Operator
- Helm
This guide assumes that the gateway control plane is installed in ${REMOTE_CLUSTER1}.
Install Bookinfo in your multicluster setup and expose the productpage app across both clusters with a global hostname.

Step 2: Set up Gloo Gateway for ingress

Get the Helm values for your current Gloo Gateway installation.

helm get values gloo -n gloo-system -o yaml --kube-context ${REMOTE_CONTEXT1} > gloo-gateway.yaml
open gloo-gateway.yaml

Add the following values to the Helm value file to enable the multicluster ambient support.


gloo: 
  gloo:
    deployment:
      customEnv:
        - name: GG_AMBIENT_MULTINETWORK
          value: "true"

Upgrade your Gloo Gateway installation.

helm upgrade -n gloo-system gloo glooe/gloo-ee \
--kube-context ${REMOTE_CONTEXT1} -f gloo-gateway.yaml \
--version=1.18.28

Add the gloo-system namespace to your ambient mesh. This label ensures that traffic from the gateway proxy to your apps are secured via mTLS.
```
kubectl label ns gloo-system istio.io/dataplane-mode=ambient --context ${REMOTE_CONTEXT1}
```

Step 3: Set up multicluster routing

Before setting up routing through the ingress gateway, verify multicluster routing within the mesh.

Make sure that you can route from the ratings app to the global hostname that the productpage apps are exposed on.

kubectl -n bookinfo --context ${REMOTE_CONTEXT1} debug -i pods/$(kubectl get pod -l app=ratings \
--context ${REMOTE_CONTEXT1} -A -o jsonpath='{.items[0].metadata.name}') \
--image=curlimages/curl -- curl -vik http://productpage.bookinfo.mesh.internal:9080/productpage

Scale down the productpage app in ${REMOTE_CLUSTER1}.

kubectl scale deployment productpage-v1 -n bookinfo --context ${REMOTE_CONTEXT1} --replicas=0

Repeat the request to the productpage app. Because the productpage app is scaled down in ${REMOTE_CLUSTER1}, traffic is forced to go to the productpage app in ${REMOTE_CLUSTER2}. Verify that you continue to see a 200 HTTP response code.

kubectl -n bookinfo --context ${REMOTE_CONTEXT1} debug -i pods/$(kubectl get pod -l app=ratings \
--context ${REMOTE_CONTEXT1} -A -o jsonpath='{.items[0].metadata.name}') \
--image=curlimages/curl -- curl -vik http://productpage.bookinfo.mesh.internal:9080/productpage

Scale up the productpage app in ${REMOTE_CLUSTER1}.

kubectl scale deployment productpage-v1 -n bookinfo --context ${REMOTE_CONTEXT1} --replicas=1

Create an HTTPRoute to expose the global hostname for the productpage app along the /productpage prefix path on the http Gateway that you created in the get started tutorial.
Note that if your global service or service namespace has the solo.io/service-takeover label, this label does not impact ingress routing. The label is primarily used to redirect in-mesh east-west traffic that targets the original .svc.cluster.local hostname to the global hostname instead. To route ingress traffic to a global hostname, you must reference the global service in the backendRefs block of your HTTPRoute as shown in this example.
```
kubectl apply --context ${REMOTE_CONTEXT1} -f- <<EOF                                                
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: productpage
  namespace: gloo-system
spec:            
  parentRefs: 
    - name: http          
      namespace: gloo-system                    
  rules:          
    - matches:
      - path:
          type: PathPrefix
          value: /productpage
      backendRefs:
        - name: productpage.bookinfo.mesh.internal 
          port: 9080
          kind: Hostname
          group: networking.istio.io
EOF
```
Hostname format: The hostname format in backendRefs depends on whether your mesh uses segments. Without segments, global services use the .mesh.internal suffix as shown above. If your mesh uses segments, the hostname uses the segment domain suffix instead (for example, productpage.bookinfo.<segment_domain>). For more information, see Service scope and segment domains.
Port mapping: The port value in the backendRefs field must match the port that is defined on the auto-generated ServiceEntry for the global service, which equals the port field on the Kubernetes Service and not the pod’s container port. If your Service uses a named targetPort, such as targetPort: http, ztunnel resolves the named port to the correct container port automatically.
Known issue: In Solo Enterprise for Istio versions before 1.29.2-patch0 (1.29.x) and 1.28.6 (1.28.x), named targetPort values are not correctly resolved, causing traffic to arrive at the wrong port. Upgrade to the fixed version or, as a workaround, use a numeric targetPort in your Kubernetes Service definition, such as targetPort: 10000.

Verify multicluster routing through the ingress gateway.

Send a request through the ingress gateway along the /productpage path. Verify that you get back a 200 HTTP response code.

curl -I http://$INGRESS_GW_ADDRESS:8080/productpage

Example output:

HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 5179
server: envoy
x-envoy-upstream-service-time: 133

Scale down the productpage app in ${REMOTE_CLUSTER1}.

kubectl scale deployment productpage-v1 -n bookinfo --context ${REMOTE_CONTEXT1} --replicas=0

Repeat the request along the /productpage path. Because the product page app is scaled down in ${REMOTE_CLUSTER1}, traffic is forced to go to the productpage app in ${REMOTE_CLUSTER2}. Verify that you continue to see a 200 HTTP response code.
```
curl -I http://$INGRESS_GW_ADDRESS:8080/productpage     
```
Example output:
```
HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 5179
server: envoy
x-envoy-upstream-service-time: 133
```

Scale up the productpage app in ${REMOTE_CLUSTER1}.

kubectl scale deployment productpage-v1 -n bookinfo --context ${REMOTE_CONTEXT1} --replicas=1

Optional: Review ambient traffic in the Gloo UI

Use the Gloo UI graph to visualize the traffic flow through your ambient mesh, and open the built-in Prometheus expression browser to verify that traffic between services is secured via mutual TLS.

Use the Gloo UI graph

Install or upgrade the Gloo UI. Be sure to include your license key for the Solo distribution of Istio in your Gloo UI Helm values, so that you can review ambient mesh traffic in the Gloo UI graph. If you already installed the Gloo UI, you can use the guide to upgrade your installation with your license key.

Port-forward the gloo-mesh-ui service on 8090.

kubectl port-forward -n gloo-system svc/gloo-mesh-ui 8090:8090 --context $REMOTE_CONTEXT1

Open your browser and connect to http://localhost:8090.
```
open http://localhost:8090/
```
Go to Observability > Graph.
Verify that you see traffic between the gateway proxy and the Bookinfo app as shown in the following image.
Figure: Gloo UI Graph
Figure: Gloo UI Graph

View metrics

Port-forward the built-in Prometheus expression browser.

kubectl -n gloo-mesh port-forward deploy/prometheus-server 9091

Open the Prometheus expression browser.

istio_requests_total{app="gloo-telemetry-collector-agent", cluster="gloo-gateway-ambient-mgt", 
collector_pod="gloo-telemetry-collector-79f767f765-bqqhb", component="standalone-collector", 
connection_security_policy="mutual_tls", destination_cluster="gloo-gateway-ambient-mgt", 
destination_principal="spiffe://gloo-gateway-ambient-mgt/ns/httpbin/sa/httpbin", 
destination_service="httpbin.httpbin.svc.cluster.local", destination_workload="httpbin", 
destination_workload_id="httpbin.httpbin.gloo-gateway-ambient-mgt", 
destination_workload_namespace="httpbin", namespace="istio-system", reporter="destination", 
response_code="200", response_flags="-", source_cluster="gloo-gateway-ambient-mgt",
source_principal="spiffe://gloo-gateway-ambient-mgt/ns/gloo-system/sa/gloo-proxy-http", 
source_workload="gloo-proxy-http", source_workload_namespace="gloo-system",
workload_id="gloo-proxy-http.gloo-system.gloo-gateway-ambient-mgt"}

Global service considerations

Review considerations when using kgateway proxies to route ingress traffic to a globally exposed service.

Service scope and segment domains

When you expose a service across clusters with the solo.io/service-scope label, an auto-generated ServiceEntry is created with a global hostname. The format of that hostname is determined by whether your mesh uses segments:

Segments configured	Hostname format
No	`<svc>.<namespace>.mesh.internal`
Yes	`<svc>.<namespace>.<segment_domain>`

Use the generated hostname as the name in the backendRefs block of your HTTPRoute:

backendRefs:
  - name: <svc>.<namespace>.<hostname_suffix>
    port: <port>
    kind: Hostname
    group: networking.istio.io

To verify which hostname was generated for your service, check the ServiceEntry resources in the istio-system namespace:

kubectl get serviceentry -n istio-system

How scope affects reachability from kgateway: The solo.io/service-scope value does not change the hostname format or the HTTPRoute syntax, but it determines which kgateway proxy instances can reach the service:

solo.io/service-scope=global: The service is reachable from any kgateway instance across all peered clusters, regardless of segment.
solo.io/service-scope=segment: The service is only reachable from kgateway instances in the same segment. A kgateway proxy in a different segment cannot resolve the global hostname.

For more information, see the Solo Enterprise for Istio documentation:

Route ingress traffic through a waypoint

By default, the kgateway proxy sends traffic directly to the destination pod, bypassing any waypoint that might be configured for the destination. To route ingress traffic through a waypoint, add the istio.io/ingress-use-waypoint: "true" label to the destination service or its namespace. No configuration is required on the kgateway proxy. The destination’s ztunnel intercepts the traffic and routes it through the waypoint automatically.

Understand N/S vs E/W failover behavior

Failover to a peer cluster behaves differently depending on whether traffic enters through the kgateway ingress proxy (north-south) or originates from within the mesh (east-west).

For east-west traffic, the source workload’s ztunnel socket performs endpoint selection and respects Kubernetes pod readiness. When local pods are in a NotReady state, ztunnel excludes them from the endpoint set and routes to cross-cluster endpoints instead.

For north-south traffic through kgateway, the kgateway proxy resolves the global hostname to a single ServiceEntry VIP and does not have visibility into individual pod readiness behind that VIP. Cross-cluster failover triggers only when no local pod endpoints exist, such as when all local replicas are scaled to zero. Pods that are in a NotReady state do not trigger cross-cluster failover on the north-south path.

To configure outlier detection or DestinationRule-based failover for north-south traffic, see kgateway load balancing and failover.

Use kgateway with PeerAuthentication strict mode

The gateway proxy must be enrolled in the ambient mesh so that its outbound connections to backend services are captured by ztunnel and participate in mesh policy enforcement. A consequence of this enrollment is that ztunnel also captures inbound connections to the gateway pod. With a PeerAuthentication policy set to mtls.mode: STRICT, ztunnel requires mTLS on every connection it handles. Because external clients do not have mesh identities, their inbound connections are rejected with this error message:

connection closed due to policy rejection: explicitly denied by: istio-system/istio_converted_static_strict

The intended behavior for an ingress gateway is for inbound external traffic to bypass ztunnel entirely. The ambient.istio.io/bypass-inbound-capture: "true" annotation configures this explicitly, so that ztunnel captures only outbound connections from the gateway to backend services.

To allow inbound external connections while keeping outbound traffic in the mesh, add the ambient.istio.io/bypass-inbound-capture: "true" annotation to the kgateway pod in an EnterpriseKgatewayParameters resource.

kubectl apply -f - <<EOF
apiVersion: enterprisekgateway.solo.io/v1alpha1
kind: EnterpriseKgatewayParameters
metadata:
  name: <params-name>
  namespace: <gateway-namespace>
spec:
  kube:
    podTemplate:
      extraAnnotations:
        ambient.istio.io/bypass-inbound-capture: "true"
EOF

Your Gateway resource must reference the EnterpriseKgatewayParameters resource so that the annotation applies to the gateway pod. For an example of how to reference an EnterpriseKgatewayParameters resource from a Gateway, see Customize the gateway proxy.

Now that you set up Gloo Gateway as the ingress gateway for your ambient mesh, you can further control and secure ingress traffic with Gloo Gateway policies.

Ingress with AWS ELBs Ingress to Istio sidecar mesh

Ingress to ambient mesh

About ambient mesh

About this guide

Before you begin

Single cluster

Step 1: Set up an ambient mesh

Step 2: Set up Gloo Gateway for ingress

Step 3 (optional): Expose the Bookinfo sample app

Add Bookinfo to the ambient mesh

Route to Bookinfo services

Multicluster

Step 1: Set up a multicluster ambient mesh

Step 2: Set up Gloo Gateway for ingress

Step 3: Set up multicluster routing

Optional: Review ambient traffic in the Gloo UI

Use the Gloo UI graph

View metrics

Global service considerations

Service scope and segment domains

Route ingress traffic through a waypoint

Understand N/S vs E/W failover behavior

Use kgateway with PeerAuthentication strict mode

Next