Kubernetes 1.37 promotes Pod Certificates and Cluster Trust Bundles to Stable, improving workload identity security with certificate-based
After the official release of Kubernetes 1.37, the most closely watched security update was the promotion of Pod Certificates and Cluster Trust Bundles to Stable. This means workload identity authentication is no longer limited to Service Account JWTs; it can also use X.509 certificates obtained through Kubernetes, allowing Pods to authenticate in a way that better fits enterprise zero-trust architectures.
Compared with the commonly used Bearer Token model in the past, this update focuses on certificate-based identity and automatic rotation mechanisms. Pod Certificates can have their private keys and certificate lifecycle managed by Kubelet, and can be used for TLS and mTLS verification, reducing the risk of long-term abuse after certificate leakage.
In the same release, Manifest-based Admission Control also moved to Beta. This mechanism can load Admission Webhooks and CEL policies from local static files, making security policies take effect as soon as the API server starts, without relying on etcd and without being directly modifiable through the Kubernetes API.
Kubernetes' workload identity design has traditionally centered on Service Account JWTs. The biggest problem with this Bearer Token model is that once stolen, an attacker may directly impersonate the workload identity, and the barrier to misuse is relatively low. From a defensive perspective, this risk does not come from the algorithm itself, but from the token's portability, duplicability, and replayability.
Pod Certificates instead use X.509 certificates and asymmetric cryptography for identity verification, which is clearly a different security model. Private keys can be managed by Kubelet, while certificates can be rotated automatically, bringing certificate lifecycle management closer to a practical and controllable security model. For scenarios that require mutual verification between internal services, mTLS can verify both sides' identities at the same time, reducing the problem of overly loose one-way Token authorization.
The value of Cluster Trust Bundles lies in strengthening trust anchor management. When workloads switch to certificate-based mutual trust, managing the trust chain and certificate sources becomes critical. This mechanism allows the description of trust roots inside the cluster to be more centralized, reducing fragmentation and configuration drift caused by each service maintaining its own certificate trust settings.
However, this capability is not completely ready to use out of the box. Kubernetes core does not yet provide a Pod Certificates signer, so administrators still need to deploy a separate Signer Controller to issue and update certificates and maintain trust anchor information in Cluster Trust Bundles. In other words, Stable does not mean no operations; it means the API and behavior are mature enough, while surrounding controllers and processes are still required.
The upgrade of Manifest-based Admission Control to Beta is also a noteworthy security improvement. Traditionally, Admission control often depends on cluster components and API resource management. Once an attacker gains elevated API permissions, they may try to adjust policies or remove restrictions. By loading policies from local static files, the policies are not stored through etcd and cannot be modified through the Kubernetes API, which can significantly reduce the surface area for online tampering.
This design is especially suitable for high-sensitivity environments, because admission logic itself is part of the cluster security boundary. Extracting key policies from the data plane that can be manipulated by the API is equivalent to moving part of the security control earlier into a more closed startup phase, providing additional protection when administrative privileges are misused.
The biggest impact of this update is on environments already running important internal services, microservice communication, and sensitive workloads on Kubernetes. Any cluster that relies on Service Account JWTs as the primary basis for workload identity should reassess whether to gradually adopt Pod Certificates to reduce the risk of lateral movement after token leakage.
For systems with high service-to-service communication requirements, such as applications that need TLS or mTLS, Pod Certificates can provide a more consistent certificate-based authentication foundation. This is especially beneficial for large clusters, cross-namespace service trust, or scenarios that require more fine-grained trust management.
However, if a cluster does not deploy a Signer Controller, or lacks certificate rotation and trust anchor management processes, the benefits of adoption will be limited. In other words, the affected area is not only the application layer, but the overall cluster governance capability, including certificate issuance, renewal, revocation, and trust chain maintenance.
Manifest-based Admission Control mainly affects administrators who need stronger anti-tampering policy protection. For high-security environments, infrastructure subject to regulatory constraints, or clusters with multiple administrative roles, this type of admission mechanism based on static files can serve as a more conservative way to host policies.
Administrators should first inventory current workload identity usage and determine which services still rely entirely on Service Account JWTs and which services already require certificate-based authentication. If there is already an internal mTLS or TLS verification plan, the adoption path for Pod Certificates should be evaluated first.
Second, the Signer Controller and trust anchor management process need to be completed. Although Pod Certificates are now Stable, actual security still depends on whether issuance, rotation, and trust bundle updates are consistent and observable. Without monitoring for the certificate lifecycle, the new authentication model may instead become an operational risk.
Third, Manifest-based Admission Control is recommended as part of the policy design for high-sensitivity clusters. Especially in scenarios where admission policies should not be directly modified by the API layer, critical policies can be moved out of etcd management to reduce the risk of policy failure when internal privileges are abused.
Fourth, certificate rotation and policy file changes should be included in change management and audit processes. When security controls shift from dynamic API resources to local static files, version control, deployment validation, and rollback mechanisms become even more important.