eventually someone will want to customize every one of those fields.
If all fields are exposed in `values.yaml`, we end up with an massive API that is also likely worse than just using the Kubernetes API directly.

To avoid this, the project attempts to minimize additions to the `values.yaml` API where possible.

      if [ "$(uname)" == "Darwin" ]; then
        script -q -r "${tmpFile}" "${*}"
      else
        script --flush --quiet --return "${tmpFile}" --command "${*}"
      fi
    else
      # if we aren't a TTY, run directly as script will always run with a tty, which may output content that
      # we cannot display
      set -o pipefail; "$@" 2>&1 | tee "${tmpFile}"
    fi
    # shellcheck disable=SC2181
    if [[ $? == 0 ]]; then

// /var/run/netns/<name>. However, this pattern is not ubiquitous. Some platforms bind mount to other places. As we run
// in a pod, we cannot just access any arbitrary file they happen to bind mount in, as we don't know ahead of time where
// it might be.
//
// Instead, we rely directly on the procfs.
// This rules out two possible methods:

  # Retrieve sync diff for a single Envoy and Istiod
  istioctl x internal-debug syncz istio-egressgateway-59585c5b9c-ndc59.istio-system

  # SECURITY OPTIONS

  # Retrieve syncz debug information directly from the control plane, using token security
  # (This is the usual way to get the debug information with an out-of-cluster control plane.)
  istioctl x internal-debug syncz --xds-address istio.cloudprovider.example.com:15012

  # Retrieve sync diff for a single Envoy and Istiod
  istioctl proxy-status istio-egressgateway-59585c5b9c-ndc59.istio-system

  # SECURITY OPTIONS

  # Retrieve proxy status information directly from the control plane, using token security
  # (This is the usual way to get the proxy-status with an out-of-cluster control plane.)
  istioctl ps --xds-address istio.cloudprovider.example.com:15012

  if [[ -f "$2" ]]; then
    return
  fi
  # Enter the output directory.
  mkdir -p "$(dirname "$2")"
  pushd "$(dirname "$2")"

  # Download and make the binary executable
  echo "Downloading ztunnel: $1 to $2"
  time ${DOWNLOAD_COMMAND} --header "${AUTH_HEADER:-}" "$1" > "$2"
  chmod +x "$2"

  # Make a copy named just "ztunnel" in the same directory (overwrite if necessary).
  echo "Copying $2 to $(dirname "$2")/${3}"

limited. In particular, ztunnel only supports 2 (custom) xDS resources: [`Workload`](../../pkg/workloadapi/workload.proto) and [`Authorization`](../../pkg/workloadapi/security/authorization.proto). As such, ztunnel does not receive `PeerAuthentication`s directly; when istiod detects a `PeerAuthentication` resource that targets an Ambient captured workload, it computes the effective policy for that workload (taking into account the mesh-wide -> namespace -> workload precedence rules) and sends that policy...

      excludeInboundPorts: ""
      includeInboundPorts: "*"

      # istio egress capture allowlist
      # https://istio.io/docs/tasks/traffic-management/egress.html#calling-external-services-directly
      # example: includeIPRanges: "172.30.0.0/16,172.20.0.0/16"
      # would only capture egress traffic on those two IP Ranges, all other outbound traffic would
      # be allowed by the sidecar
      includeIPRanges: "*"

#### Output to dirs

The output of the manifest is concatenated into a single file. To generate a directory hierarchy with subdirectory
levels representing a child dependency, use the following command:

```bash
istioctl manifest generate -o istio_manifests
```

Use depth first search to traverse the created directory hierarchy when applying your YAML files. This is needed for

#   $3: Non-versioned name to use
function download_envoy_if_necessary () {
  if [[ ! -f "$2" ]] ; then
    # Enter the output directory.
    mkdir -p "$(dirname "$2")"
    pushd "$(dirname "$2")"

    # Download and extract the binary to the output directory.
    echo "Downloading ${SIDECAR}: $1 to $2"
    time ${DOWNLOAD_COMMAND} --header "${AUTH_HEADER:-}" "$1" |\