- In sidecar mode, the CNI plugin can configure sidecar networking for pods when they are scheduled by the container runtime, using iptables. The CNI handling the netns setup replaces the current Istio approach using a `NET_ADMIN` privileged `initContainers` container, `istio-init`, injected in the pods along with `istio-proxy` sidecars. This removes the need for a privileged, `NET_ADMIN` container in the Istio users'...

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.

meshConfig:
  defaultConfig:
    proxyMetadata:
      # Enable Istio agent to handle DNS requests for known hosts
      # Unknown hosts will automatically be resolved using upstream dns servers in resolv.conf

meshConfig:
  defaultConfig:
    proxyMetadata:
      # Enable Istio agent to handle DNS requests for known hosts
      # Unknown hosts will automatically be resolved using upstream dns servers in resolv.conf

  // handlers are available on every node, and handlers of the same name are
  // equivalent on every node.
  // For example, a handler called "runc" might specify that the runc OCI
  // runtime (using native Linux containers) will be used to run the containers
  // in a pod.
  // The handler must be lowercase, conform to the DNS Label (RFC 1123) requirements,
  // and is immutable.
  optional string handler = 2;

    # By default, a template `sidecar` is always provided, which contains the template of default sidecar.
    # To inject other additional templates, define it using the `templates` option, and add it to
    # the default templates list.
    # For example:
    #
    # templates:
    #   hello: |
    #     metadata:
    #       labels:
    #         hello: world

  // items, if empty, will result in an empty slice

  repeated string items = 1;
}

// SelfSubjectReview contains the user information that the kube-apiserver has about the user making this request.
// When using impersonation, users will receive the user info of the user being impersonated.  If impersonation or
// request header authentication is used, any extra keys will have their case ignored and returned as lowercase.

  # 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 syncz debug information via Kubernetes config, using token security

overwrite existing revision tags.`
	revisionHelpStr = "Control plane revision to reference from a given revision tag"
	tagCreatedStr   = `Revision tag %q created, referencing control plane revision %q. To enable injection using this
revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=%s'
`
	webhookNameHelpStr          = "Name to use for a revision tag's mutating webhook configuration."

  popd
}

# ztunnel binary vars (TODO handle debug builds, arm, darwin etc.)
ISTIO_ZTUNNEL_BASE_URL="${ISTIO_ZTUNNEL_BASE_URL:-https://storage.googleapis.com/istio-build/ztunnel}"

# If we are not using the default, assume its private and we need to authenticate
if [[ "${ISTIO_ZTUNNEL_BASE_URL}" != "https://storage.googleapis.com/istio-build/ztunnel" ]]; then
  AUTH_HEADER="Authorization: Bearer $(gcloud auth print-access-token)"