In particular access to the security-critical production components (root CA, policy, control)
should be locked down and restricted.  The new installer allows multiple instances of
policy/control/telemetry - so testing/staging of new settings and versions can be performed
by a different role than the prod version.

The intended users of this repo are users running Istio in production who want to select, tune

  //  "data encipherment",
  //  "cert sign",
  //  "crl sign",
  //  "encipher only",
  //  "decipher only",
  //  "any",
  //  "server auth",
  //  "client auth",
  //  "code signing",
  //  "email protection",
  //  "s/mime",
  //  "ipsec end system",
  //  "ipsec tunnel",
  //  "ipsec user",
  //  "timestamping",
  //  "ocsp signing",
  //  "microsoft sgc",
  //  "netscape sgc"
  // +listType=atomic

// (root certificates).
//
// ClusterTrustBundle objects are considered to be readable by any authenticated
// user in the cluster, because they can be mounted by pods using the
// `clusterTrustBundle` projection.  All service accounts have read access to
// ClusterTrustBundles by default.  Users who only have namespace-level access
// to a cluster can read ClusterTrustBundles by impersonating a serviceaccount
// that they have access to.

[generated and rotated by Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection).

For discovery, the JWT token will be read directly from a file and sent as is. For CA, this logic is a bit more complex,