Support kgateway as a waypoint to Istio ambient

[linsun]

K8sGateway Version

latest

Is your feature request related to a problem? Please describe.

Can I run kgateway as a waypoint to Istio ambient? Istio ambient is designed with pluggable waypoints, would it be possible to have kgateway as a waypoint for Istio ambient?

If we do decide to support this, a few things to make decisions:

• I'd expect k8s GW API (HTTPRoute, Gateway etc) would be supported.

• Would kgateway support Istio's APIs or some of Istio's APIs? Examples to think through:

1. -- VS
2. -- DR
3. -- AuthorizationPolicy, PeerAuthPolicy
4. -- WasmPlugin?

• Can I also use the waypoint as an egress waypoint?

cc @asayah @Sodman @yuval-k @stevenctl @ilrudie

[ilrudie]

in Istio waypoints iirc:

• VS is still experimental or alpha and not recommended, we can probably skip it
• DR is partially supported but I don't recall off the top of my head which bits are supported

PeerAuthn is interesting. It might be irrelevant for waypoint as long as we're a sandwich. ztunnel would implement mTLS appropriately on our behalf.

AuthzPol I think is a firm must have for a waypoint.
DR needs research (or someone who just knows)

[yuval-k]

not sure about WasmPlugin, i don't believe we have seen it bring value to production users.

[yuval-k]

some context on DR being partially supported - It was done mainly to keep the scope of the DR support small for the initial implementation. Support more of it is possible.

[asayah]

It was done mainly to keep the scope of the DR support small for the initial implementation

Not in scope for this work

In Istio, DRs are a bloated concept. Working on transitioning to a Kubernetes Gateway API policy style would involve splitting a DR into multiple policies, offering a more streamlined and better-integrated approach to kgateway

[linsun]

A few other UX issues related to this that has been discussed privately:

For gloo waypoint, we want to make the proxy deployment and SA a bit more consistent, similar to istio waypoints; we want to get rid of the gloo-proxy- prefix.

Starting a thread on some UX related to gloo waypoint and getting some input. 1) I find the gloo-proxy-gloo-waypoint (currently used as the default pod name & service account name) and gloo-waypoint (used as the default waypoint name and gateway class name) a bit confusing. For example, I have to make sure in my authz policy when waypoint is added to update the allow-waypoint-to-dest L4 policy to the correct principal (if my yaml worked for istio-waypoint) by updating principal value from ["cluster.local/ns/default/sa/waypoint"] to ["cluster.local/ns/default/sa/gloo-proxy-gloo-waypoint"] 2) While debugging connectivity issue after adding gloo-waypoint, i added hosts to my Authz policy, which is hosts: [gloo-proxy-gloo-waypoint"]and undeclare/re-declare use-waypoint and realized it is gloo-waypoint not gloo-proxy-gloo-waypoint. I'd prefer them to be consistent like istio's which is waypoint from SA to the waypoint name.

[linsun]

Assign to @stevenctl for now as he expressed interest to work on this, thank you so much!