Kubernetes 1.38 starts the post-quantum migration with ML-DSA certificates

September 29, 2026. The Kubernetes team publishes v1.38.0-alpha.1, the first pre-release of the next minor version, built with Go 1.27.1. September 29, 2026. The changelog adds beta support for signing pod certificates with ML-DSA, the post-quantum signature algorithm standardized by NIST. September 29, 2026. The gRPC dependencies are bumped to fix CVE-2026-84445 and CVE-2026-84304. Why it matters: this is the first time a post-quantum signature algorithm enters the core of Kubernetes, giving platforms a concrete place to rehearse their migration before quantum computers render RSA and ECDSA signatures obsolete.

ML-DSA, the reference post-quantum signature

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is the standardized form of Dilithium, selected by NIST in FIPS 204 in August 2024 as one of three signature algorithms chosen at the end of the post-quantum cryptography competition. It relies on the hardness of lattice problems, a family believed to resist a quantum computer running Shor’s algorithm — unlike RSA and ECDSA, whose security collapses in the face of such a machine.

Moving to ML-DSA comes with an accepted cost: keys and signatures that are substantially larger than today’s ECDSA. That is exactly why Kubernetes proceeds in stages — beta first — and why the migration is not meant to be switched on everywhere overnight. For an operator, the question is not “should we migrate” but “at what pace do we test interoperability while the standard matures.”

What actually lands in 1.38

The pre-release touches four points of the control plane and the client. The most visible is support for signing pod certificates with ML-DSA, added alongside the existing algorithms — both the pod certificate request (PodCertificateRequest) and the projected volume type are updated. In parallel, the API now accepts PKCS#10 signing requests signed with ML-DSA keys in CertificateSigningRequest objects, behind the CertificateSigningRequestMLDSA feature gate.

On the kubelet side, KubeletConfiguration can now select ECDSA, RSA or ML-DSA for client and server certificate requests — the default remains ECDSA-P256, confirming that ML-DSA is an opt-in option rather than a forced switch. Finally, client-go adds support for ML-DSA keys through the crypto/mldsa package in Go 1.27, making the algorithm usable from controllers and operators.

None of this is decorative. Pod certificates are one of the few Kubernetes mechanisms where the private key is generated and consumed automatically by the platform, which makes them an ideal place to exercise a post-quantum migration without asking every application to rewrite its code.

The breaking changes to prepare for

An alpha release is not a production release, and this changelog makes that clear through three changes that will break existing setups. First, out-of-tree scheduler plugins using the NominatedPodsForNode method must now pass a klog.Logger as the first argument — a signature change that forces extension maintainers to adapt before the upgrade.

Second, two feature gates are removed permanently. PodSchedulingReadiness is dropped because the feature is now always enabled, and SeparateTaintEvictionController disappears from the kube-controller-manager: any configuration that still references it in --feature-gates must remove it or fail at startup. Third, the DynamicResourceAllocation feature gate, locked to enabled since 1.35, is removed — dynamic resource allocation is now unconditional.

The message for teams running a production cluster is simple: 1.38 arrives with cleanup baggage, not just new features. Test the migration against real manifests and real plugins, not merely against “the cluster boots.”

Upgraded dependencies, including two gRPC fixes

The pre-release also carries dependency bumps that matter for security. Kubernetes moves to Go 1.27.1 and updates google.golang.org/grpc to v1.84.0, which fixes two vulnerabilities in the gRPC-Go library: CVE-2026-84445, which let an xds.NewGRPCServer() server accept a malformed RPC, and CVE-2026-84304, an HTTP/2 frame-fragmentation flaw that could lead to excessive memory consumption. For platforms that expose internal gRPC APIs — as etcd and many control planes do — these fixes propagate with the version by default.

What to test

A post-quantum migration is not tested in production. On a test cluster, enable the feature gate and watch how ML-DSA-signed CSRs behave:

# kube-apiserver: enable CSR signing with ML-DSA keys
--feature-gates=CertificateSigningRequestMLDSA=true

# Check the apiserver version running on the test cluster
kubectl version --short
# The output must show v1.38.0-alpha.1 or a later pre-release

The meaningful test is not to flip the feature gate and watch the cluster run: it is to submit a real CertificateSigningRequest signed with an ML-DSA key and confirm it is approved, issued, and then consumed by a pod without breaking certificate rotation. Map the components that speak gRPC to the apiserver or etcd, and validate that they accept the patched library versions.

Harvest now, decrypt later: the real timeline

The term that makes this migration urgent is “harvest now, decrypt later.” An adversary with enough resources can today intercept and archive traffic or artifacts signed with RSA or ECDSA, then decrypt or forge them once a quantum computer capable of running Shor’s algorithm becomes available. For long-lived certificates — enterprise root certificates, intermediate CAs, cluster node certificates that are rarely rotated — data signed today stays exposed for years.

That is why the testing has to begin before the threat is physically present. NIST has set 2030 as the target for US federal systems to begin migrating their most critical assets to post-quantum cryptography, with full migration expected by 2035. The fact that Kubernetes introduces ML-DSA as early as 1.38, in 2026, signals that the ecosystem treats this calendar as a design constraint rather than a watch-list item.

The concrete cost of ML-DSA is worth quantifying. The ML-DSA-65 variant produces a public key of roughly 1,952 bytes and a signature of roughly 3,309 bytes, versus 32 and 64 bytes for an Ed25519 key. That gap propagates into larger CSRs, larger certificates and heavier rotation traffic — an overhead to measure on dense control planes, and one more reason to test in a realistic environment before rolling out broadly.

Worth watching next: how quickly the CertificateSigningRequestMLDSA gate moves from beta toward GA, and whether the kubelet default key algorithm starts shifting as tooling matures. None of this requires a decision today, but the components that will carry your post-quantum posture — apiserver, kubelet, controllers, client libraries — are exactly the ones changing in 1.38.

One caveat worth stating plainly: beta support in an alpha release is not a production feature. The point of this milestone is to let operators and ecosystem vendors discover — early — where the larger keys and signatures stress their certificate pipelines, their logging and their admission webhooks, before the stable release forces the conversation.

Verdict

If you run a production cluster, do nothing more than prepare the ground: 1.38 is an alpha, and the ML-DSA migration remains opt-in. Read the three breaking changes — scheduler plugin signatures, the removal of SeparateTaintEvictionController and DynamicResourceAllocation — and plan their remediation in your extensions before the stable release. If you operate a platform with long-lived assets (long-duration certificates, hard-to-update devices), start ML-DSA interoperability testing on a test cluster now: the standard exists, and the migration cost is paid when you choose to do it, not when you are forced to. And if you maintain a control-plane component, upgrade gRPC-Go to v1.84.0 independently of Kubernetes: the two fixed CVEs do not depend on the cluster version bump.

References

• Kubernetes Announce — Kubernetes v1.38.0-alpha.1 is live! (September 29, 2026)
• GitHub — kubernetes/kubernetes CHANGELOG-1.38.md
• NVD — CVE-2026-84445, gRPC-Go xDS server malformed RPC
• NVD — CVE-2026-84304, gRPC-Go HTTP/2 frame fragmentation
• NIST — FIPS 204, Module-Lattice-Based Digital Signature Standard (August 2024)