Skip to content

REDPANDA 2025-05-20

Read original ↗

Redpanda — Implementing FIPS compliance in Redpanda

Summary

Redpanda (unsigned, 2025-05-20) publishes a configuration-walkthrough post on enabling FIPS 140-2 compliance mode in a self-managed Redpanda cluster on RHEL. Canonicalises three primitives the wiki had seen only at the application / client altitude until now: (1) the FIPS-140-validated cryptographic module as a broker-embedded library (OpenSSL 3.0.9 validated for FIPS 140-2; OpenSSL 3.1.2 under NIST validation for FIPS 140-3); (2) the three-state FIPS mode setting disabled / enabled / permissive as Redpanda's deployment-altitude config dial; (3) the startup-time fail-fast enforcement shape — "Redpanda will log an error and exit if the underlying operating system isn't properly configured" — a structurally different enforcement altitude from logging-mode-then-enforcement-mode rollouts.

Batch-skip override per explicit user full-ingest instruction. Raw frontmatter had carried ingested: true + skip_reason: batch-skip — zero architecture signals in 7896-char body (pure marketing). Post is short (~1,100 words) and configuration-walkthrough voice rather than architecture retrospective, but does canonicalise three compliance-substrate primitives missing from the wiki's FIPS coverage (which prior to this ingest was anchored only on GitHub's PQ-SSH rollout via concepts/fips-cryptographic-boundary).

Key takeaways

  • Redpanda's FIPS substrate is OpenSSL 3.0.9 — a FIPS-140-2- validated cryptographic module — consumed verbatim by both the redpanda broker binary and the rpk CLI. OpenSSL 3.1.2 (FIPS 140-3 validated) is on the late-2025 upgrade roadmap to handle FIPS 140-2 → 140-3 expiry. Canonical operational framing: "Both Redpanda brokers and the rpk command-line tool leverage validated OpenSSL libraries for all security-related cryptography operations." (Source: sources/2025-05-20-redpanda-implementing-fips-compliance-in-redpanda)
  • FIPS mode is a three-state dial: disabled / enabled / permissive. enabled requires the OS to be FIPS-configured and refuses to start otherwise; permissive is a non-production safety option that lets Redpanda run as close to FIPS as possible without OS-level support "but anything crypto-related that relies on the operating system (such as sourcing entropy) may not be in full compliance". The permissive tier specifically canonicalises a development-environment deployment where the OS doesn't hold FIPS state but the broker still gates its cipher list.
  • FIPS is enforced at broker startup, not at configuration write. Canonical verbatim: "Redpanda will log an error and exit if the underlying operating system isn't properly configured." Instantiates patterns/startup-enforcement-fail-fast-on-config-noncompliance — the broker refuses to hold a half-valid state; a misconfiguration manifests as a hard startup failure rather than a silent downgrade or warning log. Structurally stronger than the logging-mode-then-enforcement-mode rollout shape canonicalised elsewhere on the wiki, because regulated-workload compliance has no "warn-only" regime by design.
  • Deployment surface is package-level, not build-flag-level — two separate RPM/Debian packages (redpanda-fips containing the OpenSSL FIPS module; redpanda-rpk-fips containing the FIPS- compliant rpk) install alongside the base Redpanda packages. redpanda.yaml is then edited with three fields: fips_mode: enabled, openssl_config_file, and openssl_module_directory. This is a FIPS-boundary-aware artefact-distribution choice: the same broker source compiles to two distinct-but-co-installable binaries (non-FIPS + FIPS), so customers inside and outside the boundary can share a single upgrade pipeline.
  • FIPS compliance is license-gated and currently scoped to self-managed RPM / Debian deployments only. Redpanda Cloud, Kubernetes deployments, and Redpanda Connect are on the roadmap. The FIPS boundary therefore currently manifests at the deployment-topology level for Redpanda customers: VM / bare-metal / self-managed is inside the boundary; managed-service and containerised deployments are outside it pending further validation.
  • OS-level FIPS is a precondition for fips_mode: enabled. On RHEL 8+, the fips-mode-setup --enable command completes FIPS module installation (fips-finish-install) and changes the system cryptographic policy to FIPS. A reboot is mandatory before the OS reports FIPS mode is enabled in fips-mode-setup --check. Only then will Redpanda's enforcement gate succeed at startup. Canonical composition: OS-level FIPS mode + module-level FIPS mode = two-layer compliance stack, with the broker as enforcement point for the two-layer precondition.
  • Deployment-automation integration via Redpanda's Ansible Collection: the collection pulls FIPS-compliant binaries when enable_fips=true + fips_mode=enabled variables are passed to the provision-cluster.yml playbook. Non-FIPS is the default; FIPS is an explicit Ansible-variable opt-in. This is the operations-altitude instantiation of the package-level distribution choice above.

Systems, concepts, patterns extracted

Operational numbers

  • OpenSSL versions: 3.0.9 (current; FIPS 140-2 validated; 140-3 validation in progress per this post's framing); 3.1.2 (target; FIPS 140-3 validated; late-2025 Redpanda upgrade).
  • FIPS mode settings (3): disabled (default), enabled (production, requires OS FIPS), permissive (development).
  • FIPS-enabled deployment platforms (at post publication, 2025-05-20): RHEL 8+ via RPM / Debian packages. On roadmap: Redpanda Cloud, Kubernetes deployments, Redpanda Connect.
  • Ansible variables: enable_fips=true + fips_mode=enabled override the non-FIPS default.

Caveats

  • Configuration-walkthrough voice, not architecture retrospective. No production incident narrative, no customer case study, no before/after numbers on FIPS-mode overhead vs non-FIPS, no audit of which specific primitive operations are negotiated on the wire.
  • No wire-protocol disclosure. The post doesn't enumerate which ciphers / MACs / KEX / signature algorithms are advertised in FIPS mode vs non-FIPS mode — readers can't infer the algorithm-list filtering surface a FIPS boundary manifests as without consulting OpenSSL's FIPS provider configuration.
  • FIPS 140-3 transition underspecified. Post says 140-2 "expires" without citing the formal NIST sunset date 2026-02-22; the OpenSSL 3.1.2 upgrade landing "late 2025" leaves a narrow cushion before 140-2 validations stop being acceptable for new procurements. Operational risk framing is absent.
  • permissive mode failure surface underspecified. The post names the entropy-sourcing example as "may not be in full compliance" without enumerating what else can leak outside the boundary on non-FIPS OS (kernel randomness, /dev/urandom, TLS ticket secrets, etc.). Customers wanting to reason about the dev-vs-prod gap are left to infer.
  • Cloud / K8s / Connect gap is a real compliance-boundary limitation. Customers running managed Redpanda Cloud, K8s- deployed Redpanda clusters, or Redpanda Connect pipelines cannot achieve FIPS compliance at publication time — this is a material constraint the post treats as a roadmap item rather than a scoping decision worth architectural discussion.
  • Non-RHEL OS coverage elided. Ubuntu FIPS, Amazon Linux FIPS, and SLES FIPS instantiations are not discussed; RHEL is the chosen worked example without a note on whether the same mechanism composes on other distributions.
  • Validation-lag on OpenSSL 3.1.2 inherits the same lag risk flagged on the FIPS boundary page — module upgrades need NIST re-validation before they're usable inside the boundary; hotfixes / CVE patches on FIPS-validated modules have longer mean-time-to-eligible-deploy than non-validated builds.
  • No byline. Post is unsigned Redpanda marketing/engineering content.

Cross-source continuity

  • Complements GitHub's 2025-09-15 PQ-SSH rollout — that post canonicalised the FIPS boundary at the SSH-endpoint / algorithm-negotiation altitude where the boundary manifests as a filtered primitive-advertisement list on the wire; this post canonicalises it at the streaming-broker-startup / validated-module altitude where the boundary manifests as a two-package artefact + three-state config dial + startup enforcement gate. Together they bracket the FIPS-boundary compliance surface across two different architectural layers of a regulated deployment.
  • Complements Meta's 2026-04-16 PQC migration framework post — that post canonicalised crypto-API guardrails as the "prevent new vulnerable usages at code-review time" layer of cryptographic governance; this post canonicalises the "validated module + startup enforcement" layer of the same governance stack at the product-deployment altitude.
  • Opens the Redpanda security-substrate axis on the wiki for the first time. Prior Redpanda ingests covered streaming substrate (batch tuning, stretch clusters, Iceberg topics, CDC, Kubernetes, agents); this is the first to canonicalise Redpanda's security-compliance substrate.

Source

Last updated · 470 distilled / 1,213 read