Red Hat’s OpenStack audit turns post-quantum readiness into a code-removal problem

Red Hat has published the results of a broad post-quantum cryptography review across Red Hat OpenStack Services on OpenShift and the upstream OpenStack ecosystem. The important finding is not simply that classical algorithms remain everywhere. It is that application code often prevents newer platform cryptography from taking effect.

What the audit found

According to Red Hat’s engineering account, 27 teams examined more than 90 repositories with a purpose-built scanner and documented 572 findings across 23 teams. The review grouped recurring problems into hardcoded asymmetric algorithms, TLS settings that block TLS 1.3, disabled certificate validation, and Kubernetes operator defaults that still produce RSA-2048 keys.

The affected paths sit close to OpenStack’s trust boundaries. Barbican generates and stores keys, Keystone signs authentication tokens, and oslo.messaging carries control-plane traffic over RabbitMQ. Red Hat says hardcoded choices in those components can stop services from inheriting post-quantum protections already available lower in the stack.

Why crypto-agility comes first

The remediation plan starts by making algorithm choices configurable. Submitted changes let Barbican select a default asymmetric-key algorithm and let Keystone configure JWS signing and accepted algorithms during migration. Red Hat also describes removal of a legacy RabbitMQ TLS protocol map so oslo.messaging can negotiate TLS 1.3, plus centralized certificate and TLS changes for OpenStack operators on OpenShift.

That approach matters because OpenSSL 3.5 and recent pyca/cryptography releases already expose ML-KEM and ML-DSA capabilities. Services that use modern TLS contexts without pinning protocols or algorithms can gain hybrid key exchange from the platform; services with classical-only assumptions need application changes. Red Hat says the current OpenStack patches are under upstream review, so this is a migration program rather than a claim that every finding is already fixed.

What teams should do now

For OpenStack developers, the practical work is to search for hardcoded values such as ES256, RS256, RSA key-generation calls and forced TLS 1.2 settings. Red Hat recommends replacing legacy socket wrapping with SSLContext, allowing TLS 1.3 negotiation, exposing algorithm selection through configuration, and using algorithm-neutral PKCS #8 serialization.

Operators have a different dependency: keep the underlying platform current, then test hybrid TLS in staging and identify components that fail to inherit it. Red Hat’s six-phase roadmap marks the initial crypto-agility and quick-win patches as submitted, operator TLS hardening as in progress, and end-to-end Tempest validation as blocked until earlier phases land.

The useful takeaway is sober: post-quantum readiness here is less about dropping a new cipher into one component than removing assumptions spread across an entire control plane. The audit gives OpenStack teams a concrete inventory and an upstream work queue, but deployment guidance should wait for the individual changes to merge and ship.