Possible alternative solution to "Provision a certificate and key for an application without sidecars"

[nairb774]

Context: https://preliminary.istio.io/latest/blog/2020/proxy-cert/

With the work in istio/istio#23583 and istio/istio#25363, long term this blog post is likely to age poorly. On the other hand, I think there is a more elegant solution that became possible with the 1.6 release, and likely is going to be more maintainable for users over the long run. The one major downside, currently, is that it makes use of an undocumented setting.

First, the way in which this could be better implemented. Rather than including a manually configured proxy sidecar to mint certificates, we can make use of the proxy.istio.io/config and sidecar.istio.io/userVolumeMount annotations to tweak how the normally injected sidecar behaves. This assumes that the istio-sidecar-injector config map is mostly unmodified, but I've been able to successfully use the following pod annotations to provide certificates to our Datadog agent (in a similar way to how the prometheus stuff is done):

annotations:
  proxy.istio.io/config: |
    proxyMetadata:
      OUTPUT_CERTS: /etc/istio-certs
  sidecar.istio.io/userVolumeMount: |
    {"istio-certs": {"mountPath": "/etc/istio-certs"}}
  traffic.sidecar.istio.io/excludeOutboundIPRanges: "0.0.0.0/0"

Note: This does require an emptyDir volume to be provided, but that should be fairly self explanatory.

As I mentioned before, this takes advantage of the undocumented proxyMetadata field in the ProxyConfig to set the OUTPUT_CERTS environment variable like the existing blog post does. If the proxyMetadata field were documented, then the annotations like above would be a much more sustainable approach to provisioning certificates than the previous manual container configuration. The other option would be to have some sort of outputCerts option which, depending on how much magic is desired, could be a path to export the certs to, a volume name to mount and export the certs to, or just a boolean indicating that a volume should be provisioned with a predetermined name and the certs written there.

No matter the direction, some sort of improved documentation in this space could go a long way for enabling this uncommon, but powerful escape hatch to be easier to maintain.