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 to ztunnel. The...

However, one interesting aspect is how these policies associate with workloads.
Istio's AuthorizationPolicy has label selectors.
However, we intentionally do not send those as part of the Workload API, in order to keep the size low.

The obvious solution to this is to put the list of selected workloads into the policy itself.
However, this means anytime a workload changes (often), we need to update the policy.

* If a socket is found, istio-agent will not start its own SDS Server and Envoy will be configured to use that socket as its source of cryptographic material.

ISTIO_METAJSON_LABELS='{"service.istio.io/canonical-name":"foo","service.istio.io/canonical-revision":"latest"}'
ISTIO_META_CLUSTER_ID='Kubernetes'
ISTIO_META_DNS_CAPTURE='true'
ISTIO_META_MESH_ID=''
ISTIO_META_NETWORK=''
ISTIO_META_WORKLOAD_NAME='foo'
ISTIO_NAMESPACE='bar'
ISTIO_SERVICE='foo.bar'
ISTIO_SERVICE_CIDR='*'
ISTIO_SVC_IP='10.10.10.10'
POD_NAMESPACE='bar'
SERVICE_ACCOUNT='vm-serviceaccount'

defaultConfig:
  proxyMetadata:
    CANONICAL_REVISION: latest
    CANONICAL_SERVICE: foo
    ISTIO_META_CLUSTER_ID: Kubernetes
    ISTIO_META_DNS_CAPTURE: "true"
    ISTIO_META_MESH_ID: ""
    ISTIO_META_NETWORK: ""
    ISTIO_META_WORKLOAD_NAME: foo
    ISTIO_METAJSON_LABELS: '{"service.istio.io/canonical-name":"foo","service.istio.io/canonical-revision":"latest"}'
    POD_NAMESPACE: bar
    SERVICE_ACCOUNT: vm-serviceaccount
    TRUST_DOMAIN: ""

    CANONICAL_SERVICE: foo
    CLUSTER_MESH_CONFIG_VALUE: foo
    ISTIO_META_CLUSTER_ID: Kubernetes
    ISTIO_META_DNS_CAPTURE: "true"
    ISTIO_META_MESH_ID: ""
    ISTIO_META_NETWORK: ""
    ISTIO_META_WORKLOAD_NAME: foo
    ISTIO_METAJSON_LABELS: '{"service.istio.io/canonical-name":"foo","service.istio.io/canonical-revision":"latest"}'
    POD_NAMESPACE: bar
    PROXY_CONFIG_ANNOT_VALUE: bar
    SERVICE_ACCOUNT: vm-serviceaccount

    CANONICAL_SERVICE: foo
    CLUSTER_MESH_CONFIG_VALUE: foo
    ISTIO_META_CLUSTER_ID: Kubernetes
    ISTIO_META_DNS_CAPTURE: "true"
    ISTIO_META_MESH_ID: ""
    ISTIO_META_NETWORK: ""
    ISTIO_META_WORKLOAD_NAME: foo
    ISTIO_METAJSON_LABELS: '{"service.istio.io/canonical-name":"foo","service.istio.io/canonical-revision":"latest"}'
    POD_NAMESPACE: bar
    PROXY_CONFIG_ANNOT_VALUE: bar
    SERVICE_ACCOUNT: vm-serviceaccount

ISTIO_METAJSON_LABELS='{"service.istio.io/canonical-name":"foo","service.istio.io/canonical-revision":"latest"}'
ISTIO_META_CLUSTER_ID='Kubernetes'
ISTIO_META_DNS_CAPTURE='true'
ISTIO_META_MESH_ID=''
ISTIO_META_NETWORK=''
ISTIO_META_WORKLOAD_NAME='foo'
ISTIO_NAMESPACE='bar'
ISTIO_SERVICE='foo.bar'
ISTIO_SERVICE_CIDR='*'
ISTIO_SVC_IP='fd00:10:96::1'
POD_NAMESPACE='bar'
PROXY_CONFIG_ANNOT_VALUE='bar'
SERVICE_ACCOUNT='vm-serviceaccount'

ISTIO_METAJSON_LABELS='{"service.istio.io/canonical-name":"foo","service.istio.io/canonical-revision":"latest"}'
ISTIO_META_CLUSTER_ID='Kubernetes'
ISTIO_META_DNS_CAPTURE='true'
ISTIO_META_MESH_ID=''
ISTIO_META_NETWORK=''
ISTIO_META_WORKLOAD_NAME='foo'
ISTIO_NAMESPACE='bar'
ISTIO_SERVICE='foo.bar'
ISTIO_SERVICE_CIDR='*'
ISTIO_SVC_IP='10.10.10.10'
POD_NAMESPACE='bar'
PROXY_CONFIG_ANNOT_VALUE='bar'
SERVICE_ACCOUNT='vm-serviceaccount'

> NOTE:  While MinIO does not implement an upper boundary on buckets, your cluster's hardware has natural limits that depend on the workload and its scaling patterns. We strongly recommend [MinIO SUBNET](https://min.io/pricing) for architecture and sizing guidance for your production use case.

## List of Amazon S3 API's not supported on MinIO