Reputation: 1
I have an ingress gateway using the kubernetes Gateway API as implemented by Istio. I need to disable SNI, because the initial TLS connection is a downstream load balancer which does not pass through SNI. The load balancer also will not pass through the TLS connection either.
I don't see any option for disabling SNI when using the Gateway API - so I have tried using envoy filters to automatically set the SNI from the HTTP host headers. It looks like I'm not able to get the envoy filters to patch the gateway traffic.
I have this gateway:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: foo-dev
namespace: istio-ingress
labels:
istio.io/gateway-name: foo-dev
annotations:
networking.istio.io/service-type: ClusterIP
spec:
gatewayClassName: istio
listeners:
- name: default
port: 80
protocol: HTTP
hostname: "*.example.com"
allowedRoutes:
kinds:
- kind: HTTPRoute
namespaces:
from: Selector
selector:
matchLabels:
kubernetes.io/metadata.name: foo
- name: tls
port: 443
protocol: HTTPS
hostname: "*.example.com"
tls:
certificateRefs:
- name: foo-dev-tls
allowedRoutes:
kinds:
- kind: HTTPRoute
namespaces:
from: Selector
selector:
matchLabels:
kubernetes.io/metadata.name: foo
I have this HTTPRoute
:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: foo
namespace: foo
spec:
parentRefs:
- name: foo-dev
namespace: istio-ingress
hostnames: ["dev-foo.example.com"]
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: foo
port: 443
And I have defined this filter (which doesn't work):
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: gateway-auto-sni-san-validation
namespace: istio-ingress
spec:
targetRefs:
- name: foo-dev
kind: Gateway
group: gateway.networking.k8s.io
configPatches:
- applyTo: NETWORK_FILTER
match:
context: GATEWAY
patch:
operation: MERGE
value:
# attempt 1
upstream_http_protocol_options:
auto_sni: true
auto_san_validation: true
## attempt 2
# typed_config:
# "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.UpstreamHttpProtocolOptions"
# common_http_protocol_options:
# auto_sni: true
# auto_san_validation: true
## attempt 3
# typed_extension_protocol_options:
# envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
# "@type": "type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions"
# upstream_http_protocol_options:
# auto_sni: true
# auto_san_validation: true
I expect that, when connecting to the gateway from inside the cluster, all I will need is the Host
header to reach my workload.
However, this doesn't work:
$ curl -ivvk https://foo-dev-istio/api/health -H 'Host: dev-foo.example.com'
* Trying 172.20.88.10:443...
* Connected to foo-dev-istio (172.20.88.10) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to foo-dev-istio:443
* Closing connection 0
* TLSv1.0 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, decode error (562):
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to foo-dev-istio:443
Instead, I have to use supply SNI in order to get the traffic through:
$ curl -ivvk --resolve dev-foo.example.com:443:172.20.88.10 https://dev-foo.example.com/api/health -H 'Host: dev-foo.example.com'
* Added dev-foo.example.com:443:172.20.88.10 to DNS cache
* Hostname dev-foo.example.com was found in DNS cache
* Trying 172.20.88.10:443...
* Connected to dev-foo.example.com (172.20.88.10) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: O=Example, Inc.; CN=example.com
* start date: Aug 9 14:14:50 2024 GMT
* expire date: Aug 8 14:14:50 2029 GMT
* issuer: O=Example, Inc.; CN=example.com
* SSL certificate verify result: self-signed certificate (18), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x556b874fee90)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /api/health HTTP/2
> Host: dev-foo.example.com
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 2147483647)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200
HTTP/2 200
< x-powered-by: Express
x-powered-by: Express
< vary: Origin
vary: Origin
< access-control-allow-credentials: true
access-control-allow-credentials: true
< content-type: application/json; charset=utf-8
content-type: application/json; charset=utf-8
< content-length: 95
content-length: 95
< date: Fri, 09 Aug 2024 16:13:59 GMT
date: Fri, 09 Aug 2024 16:13:59 GMT
< x-envoy-upstream-service-time: 8
x-envoy-upstream-service-time: 8
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host dev-foo.example.com left intact
{"status":"ok","info":{"cache":{"status":"up"}},"error":{},"details":{"cache":{"status":"up"}}}
Upvotes: 0
Views: 164