Replies: 2 comments 4 replies
-
|
One funny thing here, is I had thought I tested something similar successfully earlier, but with TCPRoute instead of TLSRoute. If I did, it would've been on an earlier version of istio. Should this scenario be using TCPRoute or TLSRoute? The backend in the ambient mesh is talking plain text (other than encryption from the mesh itself) |
Beta Was this translation helpful? Give feedback.
-
|
There's also an example in the istio repo in tls-terminate.yaml, which when simplified boils down to: apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: istio
spec:
controllerName: istio.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: gateway
namespace: istio-system
spec:
addresses:
- value: istio-ingressgateway
type: Hostname
gatewayClassName: istio
listeners:
- name: tls-terminate
hostname: "example.com"
port: 443
protocol: TLS
allowedRoutes:
namespaces:
from: All
tls:
mode: Terminate
certificateRefs:
- name: my-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
name: tls-terminate-route
namespace: default
spec:
parentRefs:
- name: gateway
namespace: istio-system
sectionName: tls-terminate
hostnames:
- "example.com"
rules:
- backendRefs:
- name: backend-terminate
port: 8080The only thing I'm noting here is it's showing port 443/8080 so I guess it's HTTP. |
Beta Was this translation helpful? Give feedback.
-
|
Small update, for the redis-cli test the ingress gateway's logs were showing "filter_chain_not_found", which led me to apply the suggestion from #42587, https://istio.io/latest/docs/ops/common-problems/network-issues/#configuring-sni-routing-when-not-sending-sni. After disabling hostname on the ListenerSet redis-cli is now working. This is working for both TCPRoute and TLSRoute. For the mariadb/mysql - it seems as though the STARTTLS procedure might be playing a role. I haven't been able to get a similar setup working for it. I'm guessing the only option is to use TLS passthrough for that? |
Beta Was this translation helpful? Give feedback.
-
|
To answer your three questions directly: 1. Does TLSRoute termination work for non-HTTP in 1.30? — Yes, but with caveats. TLSRoute with 2. Ambient mode? — This is likely where your issue is. In ambient mode, the ingress gateway proxy is an Envoy that handles inbound traffic, but the traffic flow after TLS termination for non-HTTP protocols goes through the ztunnel → waypoint chain differently than HTTP. The 3. Protocol-specific nuances? — After TLS termination, it's just raw TCP bytes to the backend. Redis, MySQL, or anything else — the gateway doesn't care about the application protocol. The issue isn't protocol-specific, it's about how the terminated connection gets proxied. Regarding your follow-up question about TLSRoute vs TCPRoute: TLSRoute with What's likely happening: after TLS termination on the TLSRoute listener, the envoy gateway generates a TCP proxy filter chain to forward traffic to the backend. But in ambient mode, the traffic from the gateway to the backend goes through ztunnel, which adds another layer of mTLS (HBONE). For HTTP this works seamlessly because the waypoint understands HTTP. For raw TCP after TLS termination, the ztunnel/waypoint path might not be properly forwarding the bytes. Things to try:
istioctl proxy-config listener <gateway-pod> --port 6379 -o json
istioctl proxy-config cluster <gateway-pod> -o json | jq '.[] | select(.name | contains("dragonfly"))'
apiVersion: v1
kind: Namespace
metadata:
name: dragonfly
labels:
istio.io/dataplane-mode: none # temporarily disable ambient
kubectl logs <gateway-pod> -c istio-proxy | grep -i "6379\|dragonfly\|reset"
The fact that openssl handshake succeeds but |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mg1986jp , thanks for the detailed reply. I did post an update above but eventually did manage to get redis-cli to connect using tls over the ingress gateway by removing the explicit hostname on the ListenerSet after reading: #42587, https://istio.io/latest/docs/ops/common-problems/network-issues/#configuring-sni-routing-when-not-sending-sni. The same thing isn't working for an almost identical setup for MariaDB. I was wondering if it was something very specific to how TLS is established for MariaDB using STARTTLS, after stumbling upon several similar posts for postgres: #33345, #47895 |
Beta Was this translation helpful? Give feedback.
-
|
@jammy-d Yeah that's exactly the STARTTLS problem. MariaDB (and Postgres) start the connection in plaintext — the client and server negotiate capabilities first, then the client sends an SSL request to upgrade to TLS mid-stream. The gateway's TLS listener with #33345 is the feature request for STARTTLS support in Istio — it's still open and hasn't landed. Envoy itself has had STARTTLS support since envoyproxy/envoy#13112, but Istio hasn't exposed it through its API yet. For now your options are probably TLS passthrough ( |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm following the release notes in https://istio.io/latest/news/releases/1.30.x/announcing-1.30/, specifically it mentions "This release adds support for TLSRoute termination and mixed mode".
I interpreted this to mean, TLS termination should be supported using TLSRoute for non-HTTP traffic. Is it correct to expect this should work with ambient mode, in a similar way to TLS termination is supported used HTTPRoute for HTTP traffic?
My questions are:
For reference, I have this Gateway:
A baseline ListenerSet and HTTPRoute, with simple TLS enforced via a private CA cert:
With this configuration I am able to reach my backend svc from outside the cluster via a simple curl command like:
and openssl with the servername flag shows the cert I'm expecting:
But if I try to expose a ListenerSet and TLSRoute for another protocol (tried redis, mysql) using the same gateway, different port, with something like:
OpenSSL again shows the right cert when I run:
but if I try to connect via the app CLI from outside the cluster, e.g. :
it results in something like:
Something similar happens with a mariadb/mysql setup too.
I recently migrated to using ListenerSet, but before the listeners were directly on the Gateway spec and I was facing the same issue.
To add to this, I performed a similar test in the reverse direcion which involves, running redis-cli from a pod within the cluster, where the traffic is going from the pod to a waypoint proxy which is acting as an egress gateway for the cluster, and performing TLS origination, and this seems to work successfully:
And I have a ServiceEntry and DestinationRule:
Here are my istiod Helm values:
Beta Was this translation helpful? Give feedback.
All reactions