# hadolint ignore=DL3005,DL3008
RUN apt-get update && \
  apt-get install --no-install-recommends -y \
  ca-certificates \
  curl \
  iptables \
  iproute2 \
  iputils-ping \
  knot-dnsutils \
  netcat-openbsd \
  tcpdump \
  conntrack \
  bsdmainutils \
  net-tools \
  lsof \
  sudo \
  && update-ca-certificates \
  && apt-get upgrade -y \
  && apt-get clean \

When fetching certificates, ztunnel will authenticate to the CA with its own identity, but request the identity of another workload.
Critically, the CA must enforce that the ztunnel has permission to request that identity.
Requests for identities not running on the node are rejected.
This is critical to ensure that a compromised node does not compromise the entire mesh.

- Better security: separate Istio components reside in different namespaces, allowing different teams or
roles to manage different parts of Istio. For example, a security team would maintain the
root CA and policy, a telemetry team may only have access to Prometheus,
and a different team may maintain the control plane components (which are highly security sensitive).

  //
  // The data must consist only of PEM certificate blocks that parse as valid
  // X.509 certificates.  Each certificate must include a basic constraints
  // extension with the CA bit set.  The API server will reject objects that
  // contain duplicate certificates, or that use PEM block headers.
  //
  // Users of ClusterTrustBundles, including Kubelet, are free to reorder and

secret/default     Cert Chain     ACTIVE     false          6fbee254c22900615cb1f74e3d2f1713     2023-05-16T01:32:52Z     2023-05-15T01:30:52Z
secret/ROOTCA      CA             ACTIVE     true           193a543fe2b0d9cd4847675394dfc54      2033-05-02T03:41:33Z     2023-05-05T03:41:33Z

NAME                                                       STATUS      LOCALITY     CLUSTER

  //
  // Custom signerNames can also be specified. The signer defines:
  //  1. Trust distribution: how trust (CA bundles) are distributed.
  //  2. Permitted subjects: and behavior when a disallowed subject is requested.

  //
  // If the webhook is running within the cluster, then you should use `service`.
  //
  // +optional
  optional ServiceReference service = 1;

  // `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate.
  // If unspecified, system trust roots on the apiserver are used.
  // +optional
  optional bytes caBundle = 2;

  //
  // If the webhook is running within the cluster, then you should use `service`.
  //
  // +optional
  optional ServiceReference service = 1;

  // `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate.
  // If unspecified, system trust roots on the apiserver are used.
  // +optional
  optional bytes caBundle = 2;

#### Webhooks

Istio contains both Validation and Mutating webhook configurations. These need a `caBundle` specified in order to provision the TLS trust. Because Istiod's CA certificate is somewhat dynamic, this is patched at runtime (rather than part of the install). The webhook controllers handle this patching.