Mount semantics carry most of the value here. A signer writes its anchors into one cluster-scoped object [1], and the kubelet projects a named anchor set into the container filesystem [3]. Software that already loads a PEM bundle from a path needs a path change and nothing else, which is a much cheaper adoption story than a sidecar that rewrites files on a timer.
The reason to bother is the grant, not the elegance. Distributing kube-apiserver anchors today means a ConfigMap injected into every namespace [7], and the KEP is blunt about the cost: the responsible controller needs permission to create ConfigMaps in all namespaces [10]. That is a permanent cluster-wide write capability, held in order to maintain one file. Because the auto-created bundle for the `kubernetes.io/kube-apiserver-serving` signer is cluster-scoped and arrives via the kubelet [6], the delivery path to a pod stops involving a namespaced object at all [16].
The part platform teams routinely flatten is that anchors are contextual. The KEP says it plainly: depending on the identity a peer presents, you may want a different anchor set [5]. It also notes that a trust anchor need not be a root, and can be an intermediate [4]. One concatenated `ca.crt` mounted everywhere erases both distinctions. The stated goal is narrower and better, that workloads get the anchors backing a particular `certificates/v1` signer [12].
There is a caveat, though, and it sits deeper in the document than the summary suggests. The KEP names static anchor sets embedded in webhook and aggregated API server configuration as a rotation problem [8], but the KEP text I have does not say that webhook configuration gains any way to reference a bundle. That would sit in Design Details, which the contents list but the excerpt does not include [17]. Admission webhooks should not be assumed to be covered by this until that section says otherwise.
Maturity is unresolved in the same way. The signoff checklist marks items as required before a KEP targets a milestone, including approvers marking it implementable and a completed production readiness review [14], and GA additionally requires that conformance tests hit every GA endpoint and run flake free for a minimum two-week window [13]. Those are gates on test infrastructure, not on the API shape.
The KEP weighs three approaches and finds a downside in each, and one of them is a CRD it compliments before ruling out on jurisdiction: CRDs work well, but are inappropriate for use by core APIs [15][11]. That is a design position rather than a criticism of anyone's controller, and it applies to anything hoping to graduate in-tree.
For this to be a cheap migration in your cluster, a few things have to hold. Your consumers must read anchors from a file rather than from inline configuration. Your signer controller must be able to write a ClusterTrustBundle instead of fanning out copies. And your clusters must run a version where both the object and the projected volume source are available, which the material here does not pin down.
