cozystack-route-hostname-policy-tls is the admission control that stops a tenant publishing a TLSRoute for a hostname outside its own apex. Nothing exercises it against a live apiserver. Its HTTPRoute twin has both a denied probe and an admitted one; the TLSRoute rule has neither.
Mechanism
hack/e2e-chainsaw/gateway/chainsaw-test.yaml contains no TLSRoute at all — grep -c "TLSRoute\|tlsroute" over the committed file returns 0. The route-hostname-policy step at :460 creates route-hostname-hijack-probe (:472, expected denied) and route-hostname-allow-probe (:504, expected admitted), and every kind: in that step is HTTPRoute.
The TLSRoute rule is covered by helm-unittest and by the version-coverage guard in hack/, but both read rendered YAML. Rendering proves the policy object is emitted with the right matchConstraints and CEL; it cannot prove the apiserver refuses a request, because no apiserver is involved. So the one half of this control with runtime evidence is the half that was already the easier of the two to get right.
The asymmetry is invisible to a reader of that suite: nothing there is wrong, and a grep for what the file contains finds a policy step with probes in it. It shows up only by grepping for the kind that is absent.
Impact
No live defect — the rule is correct as rendered, and there is no evidence it fails at admission. What is missing is the ability to notice if it ever stops working. A CEL expression that silently matches nothing, a matchConstraints that names a version the cluster no longer serves, or a binding that fails to attach would all leave the rendered YAML looking exactly as it does today, and the suite would stay green.
That failure mode is not hypothetical for this rule specifically: the policy selects tlsroutes by explicit API version list, and the versions a bundle serves change across upgrades.
Fix shape
Mirror the two existing HTTPRoute probes inside the same route-hostname-policy step: one TLSRoute with an out-of-apex hostname, expected to be denied, and one within the tenant apex, expected to be admitted. The listener plumbing for TLS passthrough already exists in that suite, so this needs no new fixture beyond the two route objects and their cleanup.
Worth doing in the same pass: assert on the denial message, not merely on the failure, so a rejection for an unrelated reason cannot pass as the policy working.
cozystack-route-hostname-policy-tlsis the admission control that stops a tenant publishing a TLSRoute for a hostname outside its own apex. Nothing exercises it against a live apiserver. Its HTTPRoute twin has both a denied probe and an admitted one; the TLSRoute rule has neither.Mechanism
hack/e2e-chainsaw/gateway/chainsaw-test.yamlcontains no TLSRoute at all —grep -c "TLSRoute\|tlsroute"over the committed file returns0. Theroute-hostname-policystep at:460createsroute-hostname-hijack-probe(:472, expected denied) androute-hostname-allow-probe(:504, expected admitted), and everykind:in that step is HTTPRoute.The TLSRoute rule is covered by helm-unittest and by the version-coverage guard in
hack/, but both read rendered YAML. Rendering proves the policy object is emitted with the rightmatchConstraintsand CEL; it cannot prove the apiserver refuses a request, because no apiserver is involved. So the one half of this control with runtime evidence is the half that was already the easier of the two to get right.The asymmetry is invisible to a reader of that suite: nothing there is wrong, and a grep for what the file contains finds a policy step with probes in it. It shows up only by grepping for the kind that is absent.
Impact
No live defect — the rule is correct as rendered, and there is no evidence it fails at admission. What is missing is the ability to notice if it ever stops working. A CEL expression that silently matches nothing, a
matchConstraintsthat names a version the cluster no longer serves, or a binding that fails to attach would all leave the rendered YAML looking exactly as it does today, and the suite would stay green.That failure mode is not hypothetical for this rule specifically: the policy selects
tlsroutesby explicit API version list, and the versions a bundle serves change across upgrades.Fix shape
Mirror the two existing HTTPRoute probes inside the same
route-hostname-policystep: one TLSRoute with an out-of-apex hostname, expected to be denied, and one within the tenant apex, expected to be admitted. The listener plumbing for TLS passthrough already exists in that suite, so this needs no new fixture beyond the two route objects and their cleanup.Worth doing in the same pass: assert on the denial message, not merely on the failure, so a rejection for an unrelated reason cannot pass as the policy working.