Connect: Validate Server Certificates when using Envoy

[banks]

Scope:

• No design work needed
• O(days) with familiarity

---

Envoy upstream clusters currently don't validate the server certificate. Adding this to the cluster isn't too hard as part of the cluster's TLS context. For Connect, we always know the URI we expect in the server cert and can just encode that using verify_subject_alt_name list.

The one wrinkle here is that to support External Federation we need a way to register some opaque SAN value when registering a service from an external mesh so we can configure that value instead of the Connect-formatted one. This is similar to the recent work on ExternalSNI (#6324) but subtly different - SNI interacts with gateway routing and discovery chain while SAN doesn't.

We could add this as a field to the service instances themselves - there could technically be a case where you'd want some instances to be external and some not meaning different SAN expected per instance. In that case we can just collect all the distinct SANs returned and allow any of them.

It would be simpler and sufficient for all known use cases now to only allow overriding allowed SANs explicitly in service-defaults in the same way we do with ExternalURI. The problem is that ideally we should return the correct SAN in all service-discovery requests to ensure those contain complete info needed to establish a secure connection without having to also cross-reference the discovery chain stuff. I don't like the idea of only adding this as service meta when it's a core part of our model for key features.

So I think we should add a SAN field somewhere in the service definition/response to encode this. By default that would be empty for regular services, and would contain the normal Connect spiffe ID for connect-enabled (native of proxy) services. External federation would then populate this field explicitly on registration with the external SAN to validate and proxy integrations (e.g. the SDK can just rely on validating against whatever is in the result(s) without needing to duplicate the current Connect Spiffe ID formatting logic.

We should update the SDK/built-in proxy to use that field as well as Envoy (#6362).

[edit] external federation will happen eventiually and the above will likely be relevant then, but it's not here today so we don't really need to solve for it while fixing the basic validation case. We can work that out later as part of that work.

[banks]

Envoy now has match_subject_alt_name which supports using a regex to validate the server.

It probably did when we wrote this, just noting we'd need that to match the right parts of the URI SAN just like we do on the public listener.

Also, we still use separate clusters for each destiantion service even when they are going through the same set of mesh gateways which means we should be able to add the SAN validation to each one easily.