TLS Backend cert validation types

lsjostro commented 2 weeks ago

Description: I'm trying to configure TLS Backend validation of a service (out of my control and out side k8s). The cert on that external service is not using SAN DNS. Only Common name. Is there a better way other then creating a patch like this to remove validation san_type: DNS?

# foo-svc cert doesn't use SubjectAltName DNS so we need to patch away SAN DNS validation.
# CA cert validation is working, just not using SubjectAltName DNS which I'm patching away for now
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyPatchPolicy
metadata:
  name: foo-svc-delete-san-patch
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: GatewayClass
    name: eg
  type: JSONPatch
  jsonPatches:
    - type: "type.googleapis.com/envoy.config.cluster.v3.Cluster"
      name: "httproute/external-legacy-services/foo-svc/rule/0"
      operation:
        op: remove
        path: "/transport_socket_matches/0/transport_socket/typed_config/common_tls_context/combined_validation_context/default_validation_context/match_typed_subject_alt_names/0"

arkodg commented 2 weeks ago

glad you were able to find the workaround @lsjostro from a spec perspective we made the SAN check mandatory to implement this section of the GEP https://gateway-api.sigs.k8s.io/geps/gep-1897/

The Hostname field is required and is to be used to configure the SNI the Gateway should use to connect to the backend. Implementations must validate that at least one name in the certificate served by the backend matches this field. We originally proposed using a list of allowed Subject Alternative Names, but determined that this was [not needed in the first round](https://github.com/kubernetes-sigs/gateway-api/pull/2113#issuecomment-1696127092), but may be added in the future.

With https://github.com/envoyproxy/gateway/issues/4381, we should be able to implement the newly added SAN field, hopefully for v1.3, from the spec https://gateway-api.sigs.k8s.io/geps/gep-3155/#sans-on-backendtlspolicy its not clear how we can disable this

once GEP-3155 is implemented, should we add this check as an opt in instead ? @guydc

guydc commented 2 weeks ago

Some background:

As per RFC 2818 envoy doesn't support CN validation
The language in Gateway API is open to interpretation: Implementations must validate that at least one name in the certificate served by the backend matches this field. It doesn't tell us if we should apply SAN or CN validation. However, the discussion and future evolution of the API suggest that Gateway-API meant SAN validation. Either way, Envoy is not capable of CN validation...
With the updated BTLSP spec, I don't see how we can disable subject validation. An empty list reverts to the current default behavior.

So, a short-term solution here could be to allow users to completely disable subject verification with a BackendTrafficPolicy flag. Users should understand that CN validation would not be used in this case. This is very bad for their security posture.

If we want to allow CN validation, we first need envoy to support that, and possibly get some clarifications for Gateway-API.

lsjostro commented 2 weeks ago

totally agree @guydc a simple flag in BTLSP like skipValidation would be enough. Which really would catch the users attention to opt out of "security" feature? I don't see any major users really wanting CN validation support? (I might be wrong?)

Basically: recreate the certs if possible otherwise you have to opt out and skip validation.

envoyproxy / gateway

TLS Backend cert validation types #4595