Add a transport socket match in cluster. (#8100)

API for #8016

Customers adopting service mesh likes mTLS ability. However, rolling it out without breaking existing traffic is hard. This is because mTLS is configured on per cluster basis. In reality, a service consists of multiple endpoints, mixed with having Envoy sidecar and without-sidecar endpoints. Client envoy can't send mTLS traffic until all server migrated to having Envoy sidecar.

This API tries to solve the issue by allowing mTLS/transport socket to configured at finer granularity, e.g. endpoint level. The endpoint has metadata label information, which will be used to decide which transport socket configuration to use from a map specified in the cluster.

So the outcome is that, xDS management server is able to configure client envoy talks to endpoints with sidecar in mTLS and plain text to endpoints without sidecar, for a single cluster.

Description:
Risk Level: N/A (API change only)
Release Notes: Cluster API change to use different transport socket based on endpoint label.

Signed-off-by: Jianfei Hu <jianfeih@google.com>

Mirrored from https://github.com/envoyproxy/envoy @ 1f7f90f7d1bdfaaab4e20198a09a52b678eab5d1

envoy/api/v2/cds.proto

@@ -47,7 +47,7 @@ service ClusterDiscoveryService {
 }
 
 // Configuration for a single upstream cluster.
-// [#comment:next free field: 43]
+// [#comment:next free field: 44]
 message Cluster {
   // Refer to :ref:`service discovery type <arch_overview_service_discovery_types>`
   // for an explanation on each type.
@@ -126,6 +126,71 @@ message Cluster {
     LOAD_BALANCING_POLICY_CONFIG = 7;
   }
 
+  // TransportSocketMatch specifies what transport socket config will be used
+  // when the match conditions are satisfied.
+  message TransportSocketMatch {
+    // The name of the match, used in stats generation.
+    string name = 1 [(validate.rules).string.min_len = 1];
+
+    // Optional endpoint metadata match criteria.
+    // The connection to the endpoint with metadata matching what is set in this field
+    // will use the transport socket configuration specified here.
+    // The endpoint's metadata entry in *envoy.transport_socket* is used to match
+    // against the values specified in this field.
+    google.protobuf.Struct match = 2;
+
+    // The configuration of the transport socket.
+    core.TransportSocket transport_socket = 3;
+  }
+
+  // Configuration to use different transport sockets for different endpoints.
+  // The entry of *envoy.transport_socket* in the
+  // :ref:`LbEndpoint.Metadata <envoy_api_field_endpoint.LbEndpoint.metadata>`
+  // is used to match against the transport sockets as they appear in the list. The first
+  // :ref:`match <envoy_api_msg_Cluster.TransportSocketMatch>` is used.
+  // For example, with the following match
+  //
+  // .. code-block:: yaml
+  //
+  //  transport_socket_matches:
+  //  - name: "enableMTLS"
+  //    match:
+  //      acceptMTLS: true
+  //    transport_socket:
+  //      name: tls
+  //      config: { ... } # tls socket configuration
+  //  - name: "defaultToPlaintext"
+  //    match: {}
+  //    transport_socket:
+  //      name: "rawbuffer"
+  //
+  // Connections to the endpoints whose metadata value under *envoy.transport_socket*
+  // having "acceptMTLS"/"true" key/value pair use the "enableMTLS" socket configuration.
+  //
+  // If a :ref:`socket match <envoy_api_msg_Cluster.TransportSocketMatch>` with empty match
+  // criteria is provided, that always match any endpoint. For example, the "defaultToPlaintext"
+  // socket match in case above.
+  //
+  // If an endpoint metadata's value under *envoy.transport_socket* does not match any
+  // *TransportSocketMatch*, socket configuration fallbacks to use the *tls_context* or
+  // *transport_socket* specified in this cluster.
+  //
+  // This field allows gradual and flexible transport socket configuration changes.
+  //
+  // The metadata of endpoints in EDS can indicate transport socket capabilities. For example,
+  // an endpoint's metadata can have two key value pairs as "acceptMTLS": "true",
+  // "acceptPlaintext": "true". While some other endpoints, only accepting plaintext traffic
+  // has "acceptPlaintext": "true" metadata information.
+  //
+  // Then the xDS server can configure the CDS to a client, Envoy A, to send mutual TLS
+  // traffic for endpoints with "acceptMTLS": "true", by adding a corresponding
+  // *TransportSocketMatch* in this field. Other client Envoys receive CDS without
+  // *transport_socket_match* set, and still send plain text traffic to the same cluster.
+  //
+  // TODO(incfly): add a detailed architecture doc on intended usage.
+  // [#not-implemented-hide:]
+  repeated TransportSocketMatch transport_socket_matches = 43;
+
   // When V4_ONLY is selected, the DNS resolver will only perform a lookup for
   // addresses in the IPv4 family. If V6_ONLY is selected, the DNS resolver will
   // only perform a lookup for addresses in the IPv6 family. If AUTO is