nt/d/1uM1c3zzoehiijh1ZpZuJ1-SzuVVupenv8r5yuCaFshs/edit#heading=h.dwbqvwmg6ud3))

When a ztunnel receives traffic (authenticated or not) from a workload, it will forward that traffic to the Waypoint proxy **after** applying any `TRANSPORT` layer policies (i.e. `Authorization`s). Thus, if the destination workload has at least the equivalent of a `STRICT` `PeerAuthentication`, unauthenticated traffic will be rejected before it reaches the Waypoint proxy. If the effective policy is `PERMISSIVE`...

message IngressStatus {
  // loadBalancer contains the current status of the load-balancer.
  // +optional
  optional IngressLoadBalancerStatus loadBalancer = 1;
}

// IngressTLS describes the transport layer security associated with an Ingress.
message IngressTLS {
  // hosts is a list of hosts included in the TLS certificate. The values in
  // this list must match the name/s used in the tlsSecret. Defaults to the

Traffic entering a pod over HBONE will be handled by the "inbound" code path, on port 15008.

Incoming requests have multiple "layers": TLS wrapping HTTP CONNECT that is wrapping the user's connection.

To unwrap the first layer, we terminate TLS.
As part of this, we need to pick the correct certificate to serve on behalf of the destination workload.
As discussed in [HBONE](#hbone), this is based on the destination IP.

message IngressStatus {
  // loadBalancer contains the current status of the load-balancer.
  // +optional
  optional IngressLoadBalancerStatus loadBalancer = 1;
}

// IngressTLS describes the transport layer security associated with an ingress.
message IngressTLS {
  // hosts is a list of hosts included in the TLS certificate. The values in
  // this list must match the name/s used in the tlsSecret. Defaults to the

and aggregate telemetry data. Istio's control plane provides an abstraction
layer over the underlying cluster management platform, such as Kubernetes.

Istio is composed of these components:

- **Envoy** - Sidecar proxies per microservice to handle ingress/egress traffic

step.
1. Overlays in the user CR are applied to the rendered manifests. No values are ever defined in configuration profile
CRs at this layer, so no merge is performed in this step.

## CLI

The CLI `mesh` command is implemented in the [cmd/mesh](../operator/cmd/mesh/)
subdirectory as a Cobra command with the following subcommands:

github.com/mdlayher/netlink v1.3.0/go.mod h1:xK/BssKuwcRXHrtN04UBkwQ6dY9VviGGuriDdoPSWys=
github.com/mdlayher/netlink v1.4.0/go.mod h1:dRJi5IABcZpBD2A3D0Mv/AiX8I9uDEu5oGkAVrekmf8=
github.com/mdlayher/netlink v1.4.1/go.mod h1:e4/KuJ+s8UhfUpO9z00/fDZZmhSrs+oxyqAS9cNgn6Q=
github.com/mdlayher/netlink v1.7.2 h1:/UtM3ofJap7Vl4QWCPDGXY8d3GIY2UGSDbK+QWmY8/g=
github.com/mdlayher/netlink v1.7.2/go.mod h1:xraEF7uJbxLhc5fpHL4cPe221LI2bdttWlU+ZGLfQSw=

![CA Flow](docs/ca.svg)

A single SDS request from Envoy goes through a few different layers in istio-agent.

1. First, the request is handled by the SDS server. This is mostly just an intermediate translation layer exposing
   the `SecretManager` to Envoy, without much business logic. For each resource requested by Envoy, the SDS server
   will call `SecretManager.GenerateSecret(resourceName)`

### 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

message IngressStatus {
  // LoadBalancer contains the current status of the load-balancer.
  // +optional
  optional IngressLoadBalancerStatus loadBalancer = 1;
}

// IngressTLS describes the transport layer security associated with an Ingress.
message IngressTLS {
  // Hosts are a list of hosts included in the TLS certificate. The values in
  // this list must match the name/s used in the tlsSecret. Defaults to the