```mermaid
graph LR
    subgraph Client Node
        Client
        CZ["Ztunnel"]
    end
    subgraph Server Node
        Server
        SZ["Ztunnel"]
    end
    Client--Plain-->CZ
    CZ-."HBONE (target)".->Server
    CZ--"HBONE (actual)"-->SZ
    SZ--Plain-->Server
```

### Pooling

User connections can be multiplexed over shared HBONE connections.

  // Requests for TLS serving certificates typically request: "key encipherment", "digital signature", "server auth".
  //
  // Valid values are:
  //  "signing", "digital signature", "content commitment",
  //  "key encipherment", "key agreement", "data encipherment",
  //  "cert sign", "crl sign", "encipher only", "decipher only", "any",
  //  "server auth", "client auth",
  //  "code signing", "email protection", "s/mime",

  // you made the request against.  If empty, it is defaulted.
  optional SubjectAccessReviewSpec spec = 2;

  // Status is filled in by the server and indicates whether the request is allowed or not
  // +optional
  optional SubjectAccessReviewStatus status = 3;
}

- In ambient mode, the CNI plugin does not configure any networking, but is only responsible for synchronously pushing new pod events back up to an ambient watch server which runs as part of the Istio CNI node agent. The ambient server will find the pod netns and configure networking inside that pod via iptables. The ambient server will additionally watch enabled namespaces, and enroll already-started-but-newly-enrolled pods in a similar fashion.

## Privileges required

      # JWT is intended for the CA.
      token:
        aud: istio-ca

    sts:
      # The service port used by Security Token Service (STS) server to handle token exchange requests.
      # Setting this port to a non-zero value enables STS server.
      servicePort: 0

    # The name of the CA for workload certificates.
    # For example, when caName=GkeWorkloadCertificate, GKE workload certificates

### Config Serving

Config serving is the layer that actually accepts proxy clients, connected over bidirectional gRPC streams, and serve them the required configuration.

We will have two triggers for sending config - requests and pushes.

#### Requests

// are responsible for serializing and deserializing the objects that contain
// their internal state.
// Once a ControllerRevision has been successfully created, it can not be updated.
// The API Server will fail validation of all requests that attempt to mutate
// the Data field. ControllerRevisions may, however, be deleted. Note that, due to its use by both

					},
				},
				&v1alpha3.Gateway{
					ObjectMeta: metav1.ObjectMeta{
						Name:      "fake-gw",
						Namespace: "default",
					},
					Spec: v1alpha32.Gateway{
						Servers: []*v1alpha32.Server{
							{
								Port: &v1alpha32.Port{
									Number:   80,
									Name:     "default",
									Protocol: "HTTP",
								},
								Hosts: []string{
									"productpage.exapple.com",

  // versions the Webhook expects. API server will try to use first version in
  // the list which it supports. If none of the versions specified in this list
  // supported by API server, validation will fail for this object.
  // If a persisted webhook configuration specifies allowed versions and does not
  // include any versions known to the API Server, calls to the webhook will fail
  // and be subject to the failure policy.

  // you made the request against.  If empty, it is defaulted.
  optional SubjectAccessReviewSpec spec = 2;

  // Status is filled in by the server and indicates whether the request is allowed or not
  // +optional
  optional SubjectAccessReviewStatus status = 3;
}