Conformance Tests: TLSRoute Passthrough

[candita]

This issue is intended to track conformance test development for TLSRoute Passthrough. Comment below if you're interested in working on covering any of these areas.

Core Capabilities:

• Valid TLSRoute with 1 backendRef/rule
• Valid TLSRoute with 1 backendRef/Rule and matching SNI hostname
• Valid TLSRoute with 1 backendRef/Rule and matching SNI hostname with wildcard prefix
• Valid TLSRoute with 1 backendRef/Rule and matching SNI hostname for both Listener and TLSRoute with intersecting hostname
  - [ ] Invalid TLSRoute - no backendRef/rule doesn't become Ready
  - [ ] Invalid TLSRoute - invalid backendRef/rule doesn't become Ready (some or all from sublist?)
  - [ ] Missing Rule
  - [ ] Missing Port
  - [ ] Kind, if not nil, is also not Service
  - [ ] Multi ParentRef sections names not set
  - [ ] Multi ParentRef sections names not unique
  - [ ] SNI hostname invalid - IP address
  • TLSRoute must not be Accepted for any invalid hostnames; ‘Accepted’ condition False in RouteParentStatus
    - [ ] SNI hostname invalid - not RFC1123, not wildcard prefix
  • Matching SNI hostname for both Listener and TLSRoute without intersecting hostname
  • TLSRoute hostname that doesn’t match the Listener hostname is ignored
    - [ ] More than 16 hostnames
    - [ ] More than 16 rules
    - [ ] More than 16 backendRef
    -[ ] Invalid TLSRoute with 1 backendRef/Rule that doesn’t exist performs no default forwarding
• Invalid TLSRoute with invalid BackendObjectReference performs no default forwarding (some or all from sublist?)
  - [ ] Name not set
  - [ ] Kind not set
  • Namespace (of backend) not set
  • Namespace (of backend) missing ReferenceGrant
    - [ ] Port missing when Kind is Service
• Invalid TLSRoute with filters that provide response must REJECT connection or return 500 status (some or all from sublist?)
  • Rejections must observe weight, e.g. if 50% might have been delivered, then 50% should be rejected instead
• For a Listener setting mode: "terminate", attempting to set TLSRoute in AllowedRoutes.kinds would yield a ListenerConditionType Accepted with status: false and ListenerConditionReason InvalidRouteKinds
  • this could probably be validated by webhook too
• For a Listener setting mode: "terminate", TLSRoute should not be present in ListenerStatus.SupportedKinds
• Attempting to attach a TLSRoute to a Listener setting mode: "terminate" should yield RouteConditionType Accepted with status: false and RouteConditionReason NotAllowedByListeners on the TLSRoute

[robscott]

Thanks @candita! I think it would be worth differentiating between tests of our API validation and tests of the actual underlying implementation. At least so far, I've been working with the assumption that conformance tests are only intended to cover implementation details, not our CRD or webhook validation. #1514 has a bit more context on that discussion though.

[youngnick]

I agree that for now, if one of these cases is covered by CRD validation, webhook validation, or both, we can check it off, and then come back to testing it as part of sorting out #1514.

[candita]

Does this adjusted list make more sense @robscott @youngnick ?

[youngnick]

Yep, that looks great, thanks @candita!

[mikemorris]

Suggested additions to the list of conformance tests since we've discussed disallowing mode: "terminate" with TLSRoute:

• for a Listener setting mode: "terminate", attempting to set TLSRoute in AllowedRoutes.kinds would yield a ListenerConditionType Accepted with status: false and ListenerConditionReason InvalidRouteKinds
  • this could probably be validated by webhook too
• for a Listener setting mode: "terminate", TLSRoute should not be present in ListenerStatus.SupportedKinds
• attempting to attach a TLSRoute to a Listener setting mode: "terminate" should yield RouteConditionType Accepted with status: false and RouteConditionReason NotAllowedByListeners on the TLSRoute

[youngnick]

Those additions look great, thanks @mikemorris.