Description:
I'd like to allow a TLS handshake based on SNI and client certificate fields. For example, to allow only handshakes from a client with SAN URI spiffe://example.com/client to server.example.com service.

In the context of Envoy I need to configure CertificateValidationContext in a corresponding listener's filter chain.

To achieve this goal I propose to add spkiHashes, certificateHashes and subjectAltNames fields to ClientValidationContext of ClientTrafficPolicy. For example:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
  namespace: default
  name: mtls-authentication
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: eg
      sectionName: server
  tls:
    clientValidation:
      caCertificateRefs:
        - kind: Secret
          name: root-ca
      spkiHashes:
        - NvqYIYSbgK2vCJpQhObf77vv+bQWtc5ek5RIOwPiC9A=
      certificateHashes:
        - df6ff72fe9116521268f6f2dd4966f51df479883fe7037b39f75916ac3049d1a
      subjectAltNames:
        dnsNames:
          - { type: Exact, value: client.example.com }
        emailAddresses:
          - { type: Suffix, value: @example.com }
        ipAddresses:
          - { type: Prefix, value: 192.168. }
        uris:
          - { value: spiffe://example.com/client }
        otherNames:
          - { oid: 1.3.6.1.4.1.311.20.2.3, value: client }

An alternative would be to introduce a new type of Principal to AuthorizationRule of SecurityPolicy.
But we can only support Allow action (there are only allowlists in Envoy's CertificateValidationContext) on a Gateway target (because it affects all routes) and return an error otherwise. Additionally SecurityPolicy doesn't support sectionName, so for now it's not possible to attach a policy to a specific listener and propagate rules to the right filter chain. PR #5916 fixes it.

I would also add that there are four places where we can validate SANs in Envoy: CertificateValidationContext, network RBAC filter, HTTP RBAC filter and per route RBAC filter. It may be a good idea to support configuring:

• CertificateValidationContext with ClientTrafficPolicy (allows to deny a connection at handshake stage)
• network RBAC filter with SecurityPolicy attached to a Gateway (allows to define blocklists in addition to allowlists)
• per route RBAC filter with SecurityPolicy attached to a route (granular control after TLS termination and an app protocol parsing)

So ClientTrafficPolicy and SecurityPolicy could complement each other. And I think ClientTrafficPolicy is a good place for adding SPKI hashes, certificate hashes and SANs to validate inbound TLS connection at handshake stage.

Relevant Links:

• an implementation based on ClientTrafficPolicy Support client cert validation (spki, hash, san) #5868