Istio 1.16.1 makes Kubernetes CA mounting explicit
The December patch fixes root CA access when service account token automount is disabled. It also deprecates the Kubernetes certificate-provider mode on Kubernetes versions below 1.20.
Disabling automatic service account token mounts should not accidentally remove the root certificate a proxy needs. Those are different inputs, even when older deployment arrangements place them together. Istio 1.16.1 repairs a case where the Kubernetes certificate-provider mode relied on that association.
The December 12 patch announcement names the affected combination. A proxy could fail to access the root CA when automountServiceAccountToken was false and PILOT_CERT_PROVIDER was set to kubernetes. The same release deprecates that provider setting for Kubernetes versions below 1.20.
I regard explicit trust-material delivery as part of making workload identity operable. A proxy needs to know which root it trusts, and its pod needs a defined way to receive that root. Permission to obtain a service account credential is a separate deployment choice.
The fixed template mounts the root certificate directly
The injection template in the 1.16.1 tag shows the corrected arrangement. When the configured provider is kubernetes, the proxy receives a volume named kube-ca-cert. That volume comes from the kube-root-ca.crt ConfigMap.
The template mounts it at /var/run/secrets/istio/kubernetes. This provides a concrete path for the certificate material independent of the pod's automatic service account token mount. The dependency is represented through a named volume and ConfigMap.
That is a useful distinction between trust and credentials. A root certificate supplies information used to validate a certificate chain. By comparison, the service account token is an authentication credential. A pod may need one while deliberately avoiding automatic delivery of the other.
The fix does not mean the proxy no longer needs trust material. It supplies that material through an explicit mount. Removing the accidental relationship makes the desired operating environment easier to read from the generated pod.
The same template has a separate branch for the istiod provider. It mounts the istio-ca-root-cert ConfigMap through the istiod-ca-cert volume. The provider choice therefore affects which certificate source and mount the injected proxy receives.
Deprecation has a narrower scope than removal
The release notice deprecates PILOT_CERT_PROVIDER=kubernetes on Kubernetes versions below 1.20. It does not announce removal of the setting from every supported installation. The version condition belongs in the description.
This distinction matters because a reader could otherwise infer that the patch requires all deployments to abandon the Kubernetes provider. The source states a compatibility boundary involving older Kubernetes versions. The new explicit mount is a separate correction for the documented automount combination.
The 1.16 release announcement already lists official support for Kubernetes 1.22 through 1.25. The patch's older-version deprecation does not expand that support range. It describes the treatment of a particular configuration outside the normal release support window.
That context prevents two misleading conclusions. The notice is not a claim of full support for every Kubernetes version at or above 1.20. It also does not establish that Kubernetes versions below 1.20 remain appropriate targets merely because the setting is deprecated instead of immediately removed.
Configuration generation is part of certificate correctness
A certificate system depends on more than the issuer. The proxy must receive the correct roots at the expected path, with a pod specification that actually mounts the source. A sound identity model cannot compensate for missing trust material.
The template makes that delivery path inspectable. The provider selects a branch, the branch defines a volume, and the container receives the corresponding mount. These are ordinary Kubernetes configuration relationships with a direct effect on whether the proxy can use the selected trust source.
My preference is to keep this path explicit rather than depend on a side effect of another credential mount. The patch illustrates how a small injection change can preserve a deliberate pod-security choice while restoring the proxy's required input.
The release note supplies the observed failure condition without requiring an invented outage story. The tagged template supplies the mechanism. Together they explain why the fix belongs in the injector's generated configuration instead of in application code.
Other patch changes remain separate
Istio 1.16.1 also fixes an OpenTelemetry tracer that was not working and a difference in ValidatingWebhookConfiguration between Helm and istioctl installations. These corrections affect observability and installation consistency, respectively. They are not evidence of a broader redesign of certificate issuance.
The patch updates the Kiali add-on to 1.59.1 and includes Go 1.19.4 security fixes, according to its announcement. Those are additional artifact changes. The named observability add-on update is specifically Kiali.
The certificate result is precise. With the Kubernetes provider selected, the injected proxy gets the root CA through an explicit ConfigMap volume even when automatic service account token mounting is disabled. The accompanying deprecation names an older Kubernetes compatibility boundary without declaring the provider universally removed.