EPP TLS support provides very minimal protection

[LiorLieberman]

What happened:
We currently default to self signed certificate.

Current implementations of the API are skipping CA validation by the client (the gateway) to the EPP. This does not meaningful security layer as there is no validation.

For example:

• gateway-api-inference-extension/config/manifests/gateway/patch_policy.yaml

  Lines 38 to 50 in b7d35b6

  	# This ensures that envoy accepts untrusted certificates. We tried to explicitly
  	# set TrustChainVerification to ACCEPT_UNSTRUSTED, but that actually didn't work
  	# and what worked is setting the common_tls_context to empty.
  	- type: "type.googleapis.com/envoy.config.cluster.v3.Cluster"
  	name: "envoyextensionpolicy/default/ext-proc-policy/extproc/0"
  	operation:
  	op: add
  	path: "/transport_socket"
  	value:
  	name: "envoy.transport_sockets.tls"
  	typed_config:
  	"@type": "type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext"
  	common_tls_context: {}

• https://github.com/kgateway-dev/kgateway/blob/main/internal/kgateway/extensions2/plugins/inferenceextension/endpointpicker/plugin.go#L414-L429

In istio, we have to add DestiationRule with insecureSkipVerify which does the same.

What you expected to happen:
There should be TLS validation, perhaps using backendTLSPolicy?

/kind feature

[LiorLieberman]

/kind feature

[danehans]

+1 on leveraging BackendTLSPolicy for this use case, especially since we want to stabilize the existing APIs. However,the BackendTLSPolicy GEP will need to be updated to no longer be Service-specific.

[LiorLieberman]

The epp has a service, we can look in making it work this way