AlinsRan commented on PR #2882:
URL:
https://github.com/apache/apisix-ingress-controller/pull/2882#issuecomment-5712006775
## Conformance run: green
Pushed two more commits and ran the suite end to end locally, against an ADC
image built from api7/adc#618 and `apache/apisix:master-debian-dev` (which
carries apache/apisix#13912; released 3.17.0 does not). `PROVIDER_TYPE=apisix`,
experimental channel.
| Profile | Core | Extended |
|---|---|---|
| GATEWAY-HTTP | 32 passed, 0 failed, 5 skipped | 12 passed, 0 failed, 1
skipped |
| GATEWAY-GRPC | 15 passed, 0 failed, 0 skipped | 1 passed, 0 failed, 0
skipped |
| GATEWAY-TLS | **19 passed, 0 failed, 1 skipped** | 3 passed, 0 failed, 1
skipped |
Suite exits 0 and no profile reports `result: failure`, so the CI gate
passes. GATEWAY-TLS core goes from 16 passed / 4 skipped on master to 19 passed
/ 1 skipped, and every skip on GATEWAY-HTTP was already there. The 443
remapping caused no regression, which was the part of the original description
that had only been reasoned about rather than observed.
### What the run found
`TLSRouteSimpleSameNamespace`, `TLSRouteInvalidBackendRefNonexistent` and
`TLSRouteInvalidBackendRefUnknownKind` passed on the first attempt —
passthrough traffic works. `TLSRouteHostnameIntersection` did not, and produced
two findings.
**1. A real defect, now fixed (`fix: intersect TLSRoute hostnames with the
listener hostname`).**
A TLSRoute's hostnames were used verbatim as the SNI. Gateway API defines
the effective hostnames as the intersection with the listener hostname.
`tlsroute-more-specific-wc-hostname-x-1` carries `*.example.com` and attaches
to a listener whose hostname is `abc.example.com`, so it was programmed as
`sni: *.example.com` instead of `abc.example.com` — and since every Gateway
shares one physical stream listen, it then answered `other.example.com`, which
belonged to a sibling Gateway's route pointing at a different backend. That is
what the test caught:
```
expected pod name to start with tls-backend-2, got
tls-backend-75fb9c498c-4kf2x
```
HTTPRoute has narrowed its hostnames this way all along (`filterHostnames` +
`getMinimumHostnameIntersection`); both now share `intersectRouteHostnames` and
the TLSRoute reconciler applies it exactly as the HTTPRoute one does. Dumped
from the data plane after the fix:
```
tlsroute-more-specific-wc-hostname-x-1 sni=abc.example.com
tls_passthrough=true
tlsroute-less-specific-wc-hostname-x-2 sni=*.example.com
tls_passthrough=true
tlsroute-less-specific-wc-hostname-x-4 sni=*.com
tls_passthrough=true
tlsroute-exact-hostname-x-{2,3,4} sni=abc.example.com
tls_passthrough=true
```
Every intersection is now the smallest one, and no catch-all leaked.
**2. One assertion that cannot hold here, so the test is skipped as a known
gap.**
`TLS request not matching hostnames intersection should not reach backend`
expects a connection with SNI `non.matching.com` to the address of
`gw-tlsroute-exact-hostname-x-1` to be rejected.
`gw-tlsroute-empty-hostname-x-4`'s listener carries no hostname, so its route
keeps `*.com` verbatim — correctly, and that Gateway's own subtest depends on
it — and `*.com` matches `non.matching.com`. All four Gateways resolve to one
data plane address and one stream listen, and which Gateway a connection was
addressed to is not on the wire, so nothing is left to discriminate on.
It now sits next to `HTTPRouteMultipleGateways` in
`skippedTestsForKnownGaps`, which is the same limitation, with that reasoning
recorded. Every other assertion in the test passes, including the hostname
intersections themselves.
### Still blocked
CI here stays red until api7/adc#618 is merged and a new
`ghcr.io/api7/adc:dev` is published — see the previous comment.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
