Skip to content

CONCEPT Cited by 1 source

FIPS mode tri-state

Definition

FIPS mode tri-state is a three-valued deployment-altitude config dial exposed by products that support FIPS 140 compliance. Canonical instantiation from Redpanda's 2025-05-20 configuration walkthrough:

  • disabled — default state, not running in FIPS mode. The broker uses the full cipher + KEX + signature catalogue its library supports.
  • enabled — full FIPS compliance mode. Requires the operating system to be FIPS-configured (on RHEL: fips-mode-setup --enable
  • reboot). Broker refuses to start if the OS isn't configured.
  • permissive — non-production safety option. The broker runs "as close as it can to FIPS mode" without requiring the OS to be FIPS-configured. Canonical trade-off verbatim: "anything crypto-related that relies on the operating system (such as sourcing entropy) may not be in full compliance." (Source: sources/2025-05-20-redpanda-implementing-fips-compliance-in-redpanda)

Canonical example of shipping: Redpanda exposes the dial as fips_mode: <value> in redpanda.yaml alongside openssl_config_file and openssl_module_directory. The tri-state mirrors the operational topology: production (OS-FIPS + broker-FIPS) uses enabled; development (no-OS-FIPS + broker-FIPS) uses permissive; non-regulated deployments use disabled.

Why three states, not two

A naive design would expose a binary on/off. The tri-state exists because a regulated deployment has two composed compliance layers (OS + cryptographic module), and engineers frequently need a development environment where the module layer is under test but the OS layer is unavailable (e.g., local laptop, shared CI image, containerised tooling on non-FIPS hosts). Without permissive, every developer would need a FIPS-configured host machine, or the broker would refuse to start in dev — both operationally hostile.

The tri-state decomposes as:

Setting OS FIPS? Module in FIPS mode? Use case
disabled any no non-regulated
enabled yes yes production compliance
permissive no yes (best-effort) developer machine

permissive is explicitly not a compliance-claim target — it's a dev-ergonomics affordance that gates the broker's own code paths through FIPS-mode logic while acknowledging that the OS- sourced primitives (random, entropy, kernel crypto) can't pass the boundary. Audit-time, only enabled on a FIPS OS counts.

Contrast with logging-vs-enforcement rollouts

The tri-state is structurally different from a logging-then-enforcement rollout shape used for gradual deployment of policies:

  • Logging-then-enforcement is a temporal progression — the same environment transitions through the modes over time, from violation-detection (no blocking) to violation-blocking.
  • FIPS mode tri-state is an environmental choice — dev, QA, and prod environments pick different states permanently; the tri-state is not a staged rollout but a deployment-topology dial.

Both patterns are used to manage the reality of imperfect configuration in running systems, but the FIPS tri-state has no warn-only audit regime by design — regulated workloads either pass the boundary or they don't, and permissive is explicitly scoped out of compliance claims.

Composition with startup enforcement

fips_mode: enabled composes with patterns/startup-enforcement-fail-fast-on-config-noncompliance: the broker validates the OS-level FIPS state at startup and refuses to come up if the OS isn't configured. permissive bypasses the OS-level precondition but still initialises the module in FIPS mode (filtered cipher surface, power-on self-tests on the validated module). disabled skips both.

Operational discipline

  • Deployment default should be disabled, not enabled — operators of regulated clusters must explicitly opt in, avoiding the failure mode where a production cluster refuses to start on a non-FIPS host because of a forgotten config flip.
  • Never run permissive in production. The primitive boundary is partially breached (entropy source); audit will fail.
  • Document the rationale on permissive. Without the OS- level state, dev breakage won't surface until a prod cluster (enabled on FIPS OS) hits it. Operators should drive as much of the CI surface against enabled as feasible.

Seen in

Last updated · 470 distilled / 1,213 read