open-consul/proto
R.B. Boyer bc10055edc
peering: replicate expected SNI, SPIFFE, and service protocol to peers (#13218)
The importing peer will need to know what SNI and SPIFFE name
corresponds to each exported service. Additionally it will need to know
at a high level the protocol in use (L4/L7) to generate the appropriate
connection pool and local metrics.

For replicated connect synthetic entities we edit the `Connect{}` part
of a `NodeService` to have a new section:

    {
      "PeerMeta": {
        "SNI": [
          "web.default.default.owt.external.183150d5-1033-3672-c426-c29205a576b8.consul"
        ],
        "SpiffeID": [
          "spiffe://183150d5-1033-3672-c426-c29205a576b8.consul/ns/default/dc/dc1/svc/web"
        ],
        "Protocol": "tcp"
      }
    }

This data is then replicated and saved as-is at the importing side. Both
SNI and SpiffeID are slices for now until I can be sure we don't need
them for how mesh gateways will ultimately work.
2022-05-25 12:37:44 -05:00
..
pbacl Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbautoconf Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbcommon Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbconfig Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbconnect Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbpeering Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbservice peering: replicate expected SNI, SPIFFE, and service protocol to peers (#13218) 2022-05-25 12:37:44 -05:00
pbstatus Specify go_package explicitly 2022-05-24 10:22:53 -07:00
pbsubscribe Specify go_package explicitly 2022-05-24 10:22:53 -07:00
prototest peering: replicate expected SNI, SPIFFE, and service protocol to peers (#13218) 2022-05-25 12:37:44 -05:00
buf.gen.yaml Migrate from `protoc` to `buf` (#12841) 2022-05-23 10:37:52 -04:00
buf.yaml Migrate from `protoc` to `buf` (#12841) 2022-05-23 10:37:52 -04:00