Verify the two unexercised paths in transparent inbound: ambient (HBONE) capture and inbound mTLS

[huang195]

Summary

Transparent inbound interception (#330) is merged and its main path is verified end-to-end. Two code paths shipped unexercised — they are implemented and structurally verified, but no test or live run has driven traffic through them. Tracking them here rather than leaving them implicit in a closed issue.

Neither is a known defect. Both are "we have not observed this work," which is a different claim from "this works."

1. Ambient (HBONE) inbound — the higher-risk one

Ambient inbound never traverses PREROUTING: ztunnel terminates HBONE and re-originates a LOCAL connection, so it appears in nat OUTPUT. It is captured by a mark-based DNAT at the head of AB_REDIRECT, ahead of that chain's ztunnel-mark RETURN.

Verified: the rule is installed with the full mark 0x539 / ! --uid-owner / --dst-type LOCAL match, ordered before the DNAT and before the RETURN that would otherwise leak; all nine inbound exemptions are present on that hook too. test-enforce-redirect.sh asserts the ordering explicitly, and the rules were inspected live in a pod netns.

Not verified: that ztunnel's re-originated connection actually matches that tuple at runtime. That is reasoned from redirect mode's precedent (init-iptables.sh, "Rule 2"), not observed. The Kind cluster used for e2e runs only istiod — no ztunnel DaemonSet, no istio-cni — so there is no ambient data plane despite namespaces carrying istio.io/dataplane-mode=ambient. Counters confirm which path was exercised: AB_INBOUND REDIRECT took 4 packets, the ambient DNAT 0.

Why it matters: a PREROUTING-only implementation looks correct while waving every mesh-delivered request through unvalidated. That is precisely the failure this rule exists to prevent, so it deserves an observation rather than an argument.

• Run the transparent-inbound e2e in an ambient-enrolled namespace on a cluster with ztunnel deployed
• Confirm from rule counters that the ambient DNAT — not AB_INBOUND — carried the traffic
• Confirm the exemptions hold on that path (:9091 reachable, so probes do not gate)

2. Inbound mTLS through the transparent listener

The transparent listener reuses the reverse proxy's mTLS posture via WrapListener, so tlssniff handles permissive/strict identically for both inbound shapes. Startup logs confirm the wrap is active (Transparent inbound server listening ... mtls=true).

Not verified: no TLS client has been driven against :8083. Unit coverage exists for the wrap (TestWrapListener_NoMTLSIsPassthrough) and for tlssniff itself, but the combination of SO_ORIGINAL_DST recovery and a TLS handshake on the same connection is untested end-to-end — and that combination is the novel part, since the recovery happens on the raw conn before tlssniff peeks.

• e2e with a TLS client against a transparent-inbound agent — done as strict throughout
  (permissive is already covered by the main module's plaintext 401, which is what makes
  the strict rejection below meaningful as an A/B)
• Same with strict, asserting plaintext is rejected — http_code=000, vs 401 permissive
• Beyond the original ask: a valid SVID completes the handshake and still gets 401
  from jwt-validation (test(e2e): cover inbound mTLS through the transparent listener rossoctl#2404)

Not in scope

Intra-pod loopback is deliberately not captured — containers share a netns and are one entity to every network enforcement layer, so that traffic is inside the trust boundary. See #330.

Related

• Feat: Transparent inbound interception for the Go proxy (proxy-sidecar) — SO_ORIGINAL_DST, no Envoy #330 — the feature (closed)
• feat: Transparent inbound interception for proxy-sidecar (SO_ORIGINAL_DST) #776, feat: Add inboundInterception=transparent (drops port stealing) operator#511, test: Add transparent inbound interception E2E suite rossoctl#2393 — the implementation

[huang195]

mTLS half: done ✅

Verified end-to-end and encoded as e2e tests in rossoctl/rossoctl#2404
(rossoctl/tests/e2e/transparent_inbound/test_transparent_inbound_mtls.py).

Run on kind against operator + authbridge + proxy-init images built from merged
main, so the shipped code was under test — not a local branch build.

Case	Result	Evidence
strict + plaintext	connection closed, http_code=000	vs 401 under permissive → tlssniff provably engaged on the transparent listener
strict + TLS, no client cert	tlsv13 alert certificate required	sidecar log: http: TLS handshake error ... client didn't provide a certificate
strict + TLS, valid SVID	http_code=401	handshake completed, then pipeline: plugin rejected request plugin=jwt-validation status=401

Sidecar attribution: mTLS enabled mode=strict +
Transparent inbound server listening addr=[::]:8083 mtls=true.
SVID used: spiffe://localtest.me/ns/team1/sa/ti-mtls.

The 401 in the third row is the point — the full chain runs in one request
(REDIRECT → SO_ORIGINAL_DST → tlssniff → tls.Server client-cert
verification → jwt-validation), and it stops at 401 rather than 200 because
authentication of the transport is not authorization of the request. Row 2 is
its control, so the pass cannot be explained by lax verification.

The specific worry this closes: SO_ORIGINAL_DST recovery happens on the raw
connection, before tlssniff peeks the first byte. If those interfered, the
startup logs would still have read mtls=true and looked fine. They don't
interfere.

Suite: 13/13 passing, 0 skipped.

Ambient (HBONE) half: still open ⬜

Unchanged and still blocked on infrastructure. This cluster runs only istiod —
no ztunnel DaemonSet, no istio-cni, PILOT_ENABLE_AMBIENT unset — despite
namespaces carrying istio.io/dataplane-mode=ambient. Packet counters confirm
nothing ambient ever ran: AB_INBOUND REDIRECT carried all traffic, the ambient
DNAT in AB_REDIRECT counted 0.

So the DNAT rule remains verified as installed and correctly ordered (ahead of
the ztunnel-mark RETURN, which is load-bearing — see #330), but its
mark/dst-type matching is still only reasoned from redirect-mode precedent, never
traversed. Needs a cluster with a real ambient data plane.

Worth noting separately: that gap may itself be a deployment bug. The
namespace labels say ambient, the data plane is absent. If the platform is meant
to run ambient, that is its own issue; if it isn't, the labels are misleading.

Assisted-By: Claude Code