Kubernetes 1.37 makes two certificate-related projected-volume sources stable and enabled by default: podCertificate and clusterTrustBundle. The change gives platform teams a supported way to project workload certificate material and cluster trust anchors into Pods through the existing projected-volume mechanism.
That does not amount to a universal replacement for service-account JWT authentication. Certificate issuance still depends on a signer, and applications must understand how to consume and refresh the files. However, the stable APIs provide a clearer foundation for certificate-based workload identity and trust distribution in Kubernetes environments.
What changed in Kubernetes 1.37
According to the Kubernetes 1.37 release overview, the release includes features graduating to Stable, Beta, and Alpha states. The official projected volumes documentation identifies both relevant sources as stable and enabled by default in 1.37.
clusterTrustBundlewas first available in Kubernetes 1.29 and is stable in 1.37.podCertificatewas first available in Kubernetes 1.34 and is stable in 1.37.
Both sources are configured inside a projected volume in a Pod specification and then mounted into a container. The application reads the resulting files from the mounted filesystem. Normal use of these stable features does not require enabling an alpha or beta feature gate, although Kubernetes feature gates remain configurable per component through the --feature-gates command-line option.
How ClusterTrustBundle projection works
A ClusterTrustBundle is a cluster-scoped certificates.k8s.io/v1 resource containing X.509 trust anchors. Its trustBundle field must contain valid PEM-wrapped, DER-formatted X.509 certificates with the CA bit set. Duplicate certificates and PEM block headers are rejected.
A projected volume can select a single bundle by name or select multiple bundles by signer name. A label selector can further narrow the selection. Kubelet deduplicates, normalizes, and reorders the certificates before writing them to the configured file path. It also updates the projected file when selected bundles or their contents change.
By default, a Pod does not start if a required bundle is missing or no bundle matches the specified signer and label selector. Setting optional: true allows the Pod to start with an empty file at the requested path. That setting should be used only when the application can operate safely without the trust data.
One operational detail is important for rotation: applications should not consume an updating projected source through a subPath mount. The Kubernetes documentation states that consumers using subPath do not receive updates for projected sources.
How Pod certificates are requested
The podCertificate source is backed by the certificates.k8s.io/v1 PodCertificateRequest API. Kubelets use this resource when implementing PodCertificate projected volumes.
The request includes a selected signerName, Pod and service-account identity fields, a maximum certificate lifetime, and a kubelet-generated, signed PKCS#10 certificate request. The request specification is immutable after creation. Optional signer annotations must use domain-prefixed names.
The API validates the requested lifetime. A maximum lifetime must be at least one hour and can be no more than 91 days. If it is omitted, the API server sets it to 24 hours. Kubernetes signers will not issue certificates longer than 24 hours, according to the API reference.
Supported subject key types include RSA3072, RSA4096, ECDSA P-256, P-384, P-521, and ED25519. The API server verifies the CSR signature during admission. A signer that does not support the selected key type must deny the request with an UnsupportedKeyType reason.
A signer reports the issued certificate chain through certificateChain and provides refresh timing through beginRefreshAt. Requests can also be marked Issued, Denied, or Failed. The API reference documents kubernetes.io/kube-apiserver-client-pod as a well-known signer for client certificates understood by the API server, but also states that this signer is currently unimplemented.
Why the change matters for platform teams
These APIs let Kubernetes deliver certificate credentials and trust anchors directly to workloads without requiring teams to bake trust roots into container images or manually synchronize files. Short certificate lifetimes and refresh metadata can support credential rotation, provided the signer and application implement the expected behavior.
For applications that authenticate with certificates, the projected certificate file can provide workload-specific identity material. For clients that validate certificates, a selected ClusterTrustBundle can provide the trust anchors associated with a signer or other administrator-defined selection. The feature therefore supports certificate-based application designs, but it does not define the complete application protocol or replace every existing authentication mechanism.
Administrators should also account for the default startup behavior. A naming, signer-selection, or availability mistake in a required trust bundle can prevent a Pod from starting. Conversely, making the source optional can allow startup with an empty trust file, which may not be appropriate for applications that require certificate validation.
Security and access considerations
PodCertificateRequest provides proof that the kubelet-generated PKCS#10 request was signed by the corresponding subject key, and the API server checks that signature during admission. That establishes important request-integrity behavior, but the security properties of the resulting credential still depend on the signer and the application’s use of the certificate.
ClusterTrustBundle data is not confidential by default. The API reference says that any authenticated user can read ClusterTrustBundle objects and that all service accounts have read access by default. Teams should therefore treat published bundles as broadly readable trust-distribution data and carefully review which trust anchors they publish.
Creating or modifying a signer-associated ClusterTrustBundle requires the documented certificates.k8s.io signers attest permission, with admission control enforcing signer permissions. The supplied Kubernetes documentation does not provide a complete security model for third-party signer controllers, so signer-specific controls and certificate semantics must be reviewed separately.
What you should do
- Confirm the cluster version. The stable, enabled-by-default status described here applies to Kubernetes 1.37. Earlier versions introduced the features, but they do not provide the same documented stability status.
- Configure a projected volume. Add the relevant
podCertificateorclusterTrustBundlesource to the Pod and mount the volume at the path consumed by the application. - Select and verify the signer. Pod certificate use requires an explicit signer, and that signer must support the requested key type, lifetime, annotations, and certificate semantics.
- Plan for file updates. Make sure the application can respond to certificate rotation and trust-bundle changes. Avoid
subPathwhen update delivery is required. - Protect trust-bundle administration. Use the required signer attest permission for signer-associated bundles and validate that each published bundle contains the intended CA roots.
- Decide whether missing trust data is acceptable. Leave trust-bundle sources required by default unless the application is explicitly designed to start with an empty trust file.
Availability and remaining limits
Kubernetes 1.37 provides the stable projected-volume APIs and kubelet behavior, not a complete certificate authority or third-party signer deployment. The exact implementation, lifecycle, and operational requirements of external signer controllers remain signer-specific.
Likewise, the available documentation does not establish that Pod Certificates are a universal replacement for service-account bearer-token authentication. Whether a certificate can replace a JWT depends on the signer and the application protocol. Rollback, downgrade, and cross-version interoperability guidance is also not established by the supplied documentation.
For teams operating Kubernetes 1.37, the practical next step is to test the projected files, signer behavior, refresh handling, and access model with the specific applications that will consume them. The stable status removes the preview label, but it does not remove those integration responsibilities.
