Post-Quantum Cryptography
Red Hat Ansible Automation Platform
Leverages Red Hat Enterprise Linux's cryptographic foundation to secure automation traffic and node communications against quantum threats — a feature-by-feature look at Ansible Automation Platform's PQC readiness, constraints, and roadmap.
For threat model definitions — Harvest Now, Decrypt Later and Quantum Forgery — and status definitions, see Post-Quantum Cryptography at Red Hat.
PQC overview
As a critical automation and orchestration platform, the Red Hat Ansible Automation Platform (AAP) requires a comprehensive Post-Quantum Cryptography (PQC) strategy to protect automation traffic, execution environments, content signing, and node communication channels. This assessment covers the PQC roadmap, transitions, and threat landscape across active streams of Ansible Automation Platform.
Ansible relies heavily on the underlying Red Hat Enterprise Linux (RHEL) security baseline for core cryptographic primitives, particularly via Python libraries and OpenSSH bindings.
Scope
|
In-scope components
|
Out-of-scope (already quantum-resistant)
|
Constraints
Python-cryptography blockers
Python-cryptography (PyCA) serves as a core dependency for Ansible. PQC landed upstream in PyCA 48.0 and 49.0, and all supported AAP components that make use of python-cryptography need to update to 40.0.0 or later.
Go Upstream Mesh Blocker
Ansible Automation Mesh relies heavily on the Go language toolchain. Because upstream Go has pushed native ML-DSA signature support out to Go 1.27, updating the automation mesh to a pure PQC mTLS architecture is under development.
FIPS mutual exclusivity
Strict FIPS compliance mode restricts operations to approved classical or specific hybrids due to a lack of mature certified PQC modules from NIST. Running AAP in strict FIPS mode currently makes pure PQC and FIPS compliance mutually exclusive until a later date.
Threat: Harvest Now, Decrypt Later (HNDL)
At-a-glance PQC status for each Ansible Automation Platform capability against passive data-harvesting attacks. Expand any capability below the table for notes and references.
| Capability | Status | Min. version | Risk |
|---|---|---|---|
| Managed node connections (SSH) | Depends on version | — | High |
| Web & API access (TLS) | Under active development | — | High |
| Automation mesh traffic mTLS |
Under active development | — | High |
| Local secret storage | PQ-Ready | — | — |
Notes & references
▸ Managed node connections (SSH)
Status depends on the OpenSSH version you are running — PQ-Ready for OpenSSH 10.0+. Control-to-managed node communication sessions could be intercepted via Harvest Now, Decrypt Later (HNDL) attacks and retroactively decrypted. Ansible does not manage the cryptographic algorithms itself; it inherits whatever PQC capabilities are supported and configured by the system OpenSSH. OpenSSH 10.0+ defaults to PQC hybrid kex x25519 + ML-KEM-768; if control node and managed nodes run OpenSSH 10.x, Ansible traffic automatically uses ML-KEM PQC by default. OpenSSH 9.0–9.9 defaults to sntrup761 + x25519.
▸ Web & API access (TLS)
Web transport traffic to AAP API endpoints and consoles risks passive harvesting and retroactive future decryption. The Web UI and REST API components of Ansible (available via AAP) do not manage their own cryptographic TLS libraries; PQC status is inherited from the web server/reverse proxy (Nginx or Apache), RHEL, or OpenShift handling the TLS termination.
▸ Automation mesh traffic — mTLS
Inter-mesh communication between mesh routing nodes is susceptible to active traffic harvesting and subsequent decryption. Receptor establishes peer-to-peer connections and mandates TLS 1.3, requiring Go 1.23 or newer to compile and run.
▸ Local secret storage
Ansible Vault is already fully quantum safe today — it is built entirely on symmetric crypto and cryptographic hashing.
Threat: Quantum Forgery
At-a-glance PQC status for each Ansible Automation Platform capability against signature-forgery attacks. Expand any capability below the table for notes and references.
| Capability | Status | Min. version | Risk |
|---|---|---|---|
| Automation hub content signing Pulp |
Under active development | — | Critical |
| Automation mesh traffic mTLS |
Under active development | — | — |
| Managed node connections (SSH) | Under active development | — | — |
| Web & API access (TLS) | Under active development | — | — |
Notes & references
▸ Automation hub content signing — Pulp
Quantum Forgery would allow adversaries to sign malicious automation collections or playbooks, which systems would trust as authentic. To enable signing, admins supply a custom signing script, RH templates natively default to using GPG. GPG is slow to standardize PQC, AAP is tracking and depends on industry and upstream developments in this space.
▸ Automation mesh traffic — mTLS
Update to ML-DSA (for mTLS over QUIC) capable Go is required, waiting on upstream updates.
▸ Managed node connections (SSH)
Depends on underlying OpenSSH binary and OS running on the Ansible Control Node and Managed Nodes. PQC host keys and authentication keys in SSH are still being standardized.
▸ Web & API access (TLS)
Digital signatures for authentication, for example, your actual TLS/SSL certificate using ML-DSA, is still in development.
