What is the expected behavior for implementations that do not support BackendTLSPolicy?

[whitneygriffith]

Following up on Rob's comment in slack to inform the conformance tests for BackendTLSPolicy #3138

What are your thoughts on what should happen when an implementation does not support BackendTLSPolicy yet a request is sent to a service that has a BackendTLSPolicy attached to it? What should conformant implementations do if they choose to not implement BackendTLSPolicy?

I agree with Rob that there's no way to ignore BackendTLSPolicy in this world, you need to at least watch it, and then you can either implement it or reject services it's attached to.

Some food for thought are:

• Status Reporting: Should a status be reported to indicate services are attached to an unsupported BackendTLSPolicy.
• Request Rejection: The Gateway could reject the request outright, returning an error indicating that the route type is unsupported. Should silent failure be allowed?
• Default Handling: The Gateway could fall back to a default behavior, such as routing the request to the service using the default TLS policy/certificates.

cc: @robscott @candita @youngnick @mikemorris

[candita]

Maybe a Policy could have a status reflecting that it is unimplemented? https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/policy_types.go#L130-L141 shows that we don't currently have a Policy status condition that reflects "Unimplemented", or even "Unknown". Hopefully the "Accepted" status is not the default, and perhaps a Policy should begin in the "Unimplemented" or "Unknown" state.

cc: @arkodg @skriss @sunjayBhatia @kate-osborn as contacts for implementations that support BackendTLSPolicy.

I'm against the Default Handling option, and I think if we have the Status reporting we wouldn't need to do Request Rejection.

[robscott]

In addition to my suggestion below for rejecting requests, I think standardizing on an "Unimplemented" status would be good to provide a clearer signal to users.

[mikemorris]

Hopefully the "Accepted" status is not the default, and perhaps a Policy should begin in the "Unimplemented" or "Unknown" state.

I believe the current expected behavior for unimplemented/unknown resources would be that the controller isn't watching them at all, so no status condition would ever be set - the applied resource would never be acknowledged as accepted by the controller. There is a Pending RouteConditionReason for Accepted status Unknown, but the circumstances in which it would be appropriate are not particularly well-defined. If we want to move towards requiring some level of awareness for BackendTLSPolicy, the spec requirements and kubebuilder defaults similar to what exists for GatewayClass may be close to what we want.

Agreed that an Unsupported PolicyConditionReason (suggesting instead of Unimplemented for parity with language in GatewayClassConditionReason Unsupported and RouteConditionReason UnsuppportedValue) would be a good addition to reflect known but unsupported policies.

[mikemorris]

I'm against the Default Handling option, and I think if we have the Status reporting we wouldn't need to do Request Rejection.

Agree that "default handling" isn't predictably useful behavior. If a backend can accept TLS connections without requiring a particular client certificate for mutual TLS, we probably want some way to express that explicitly - see https://github.com/kubernetes-sigs/gateway-api/pull/3180/files#r1697382336 and #3226 for further discussion of that scenario. If the backend requires a specific client certificate, this fallback behavior would just result in consistent errors rejecting the TLS negotiation.

I think request rejection is likely the cleanest approach (although not pragmatic to mandate yet) to make the misconfiguration obvious and minimize externalities such as backend requests that would never be expected to succeed.

[mikemorris]

Separately from a status condition on the BackendTLSPolicy itself, we should probably add an additional reason such as UnsupportedPolicy for the ResolvedRefs condition on any Route configured to direct traffic to a backend with an unsupportable configuration.

[howardjohn]

One challenge is any solution that requires an implementation to watch it can only really apply to a v1 resource

[robscott]

Thanks for raising this @whitneygriffith! I think we should follow the guidance here and reject requests to a Service if a BackendTLSPolicy is attached but the Gateway can't support it:

gateway-api/apis/v1/httproute_types.go

Lines 257 to 261 in 6446fac

	// When a HTTPBackendRef is invalid, 500 status codes MUST be returned for
	// requests that would have otherwise been routed to an invalid backend. If
	// multiple backends are specified, and some are invalid, the proportion of
	// requests that would otherwise have been routed to an invalid backend
	// MUST receive a 500 status code.

As @howardjohn mentions above, we can only require this behavior when the policy graduates to v1, but ideally we can add the test before and make it opt-in to start (via a supported feature).