Deploy FIPS 140-3 compliant Nomad servers

The Federal Information Processing Standard is a cryptography-focused certification standard for U.S. Government usage.

Builds of Nomad Enterprise marked with a fips1403 feature name include built-in support for FIPS 140-3 compliance. Environments that don't have a specific need for FIPS-140-3 compliance should not run these variants of Nomad Enterprise.

To use this feature, you must have an active or trial license for Nomad Enterprise. To start a trial, contact HashiCorp sales.

Enterprise

This feature requires Nomad Enterprise(opens in new tab).

Using FIPS 140-3 Nomad Enterprise

FIPS 140-3 builds of Nomad Enterprise behave in the same way as non-FIPS builds. Ensuring that Nomad remains in a FIPS-compliant mode of operation is your responsibility. To maintain FIPS-compliant operation, you must ensure that TLS is enabled so that communication is encrypted. Nomad surfaces some helpful error messages where settings are insecure.

Transport encryption is disabled in Nomad Enterprise by default. As a result, Nomad may transmit sensitive control plane information. You must ensure that gossip encryption and mTLS is enabled for all agents when running Nomad with FIPS-compliant settings. In addition, be aware that TLSv1.3 does not work with FIPS 140-3, as HKDF is not a certified primitive.

HashiCorp is not a NIST-certified testing laboratory and can only provide general guidance about using Nomad Enterprise in a FIPS-compliant manner. We recommend consulting an approved auditor for further information.

The FIPS 140-3 variant of Nomad uses separate binaries that are available from the HashiCorp Releases page. Use releases ending with the +ent.fips1403 suffix. Only Linux binaries are available.

Usage restrictions

When using Nomad Enterprise with FIPS 140-3, be aware of the following operation restrictions.

Migration restrictions

We do not support in-place migrations from non-FIPS builds of Nomad to FIPS builds of Nomad, regardless of version. A fresh cluster installation is required to receive support.

We generally recommend avoiding direct upgrades and replicated-migrations because existing wrapped key material is encrypted with non-FIPS compliant cryptographic modules, and all Nomad Variables and Workload Identities have been encrypted or signed with this non-compliant key material. Additionally, service IDs and other identifiers have been derived from non-compliant hash functions, which may lead to workload service interruptions during migration.

As such HashiCorp cannot provide support for workloads that are affected either technically or via non-compliance that results from converting existing cluster workloads to the FIPS-compliant binary.

Instead, we suggest leaving the existing cluster in place, and carefully consider migration of specific workloads to the FIPS cluster.

TLS restrictions

Nomad Enterprise's FIPS modifications include restrictions to supported TLS cipher suites and key information. Only the following cipher suites are allowed in TLS1.2 and below:

In addition, only the following key types are allowed in TLS chains of trust:

RSA 2048, 3072, 4096, 7680, and 8192-bit
ECDSA P-256, P-384, and P-521

Feature restrictions

The following features are not available or work in a modified way on FIPS mode binaries:

The nomad alloc exec and nomad job action commands, and their related APIs, are not available and return an error message.
OIDC auth method configuration does not allow the x5t key ID header for client assertions. Only the x5t#S256 header is allowed.
The md5 and sha1 HCL2 functions return an error if used in a job specification.
The md5 and sha1 checksum functions for artifact blocks return an error if used in a job specification.
The md5sum function returns an error if used in the content of a template block.

Third-party restrictions

Nomad executes third-party binaries and workloads and communicates with external APIs that may not meet FIPS-140-3 compliance requirements, such as git, Docker, or a cloud provider. You have responsibility for ensuring that the other software in your cluster is compliant.

Heterogeneous cluster deployments

We do not support mixed deployment scenarios within the same Nomad cluster. An example of an unsupported deployment scenario is one that mixes FIPS and non-FIPS Nomad binaries. Nodes across the entire cluster must use a single binary or deployment type.

Running a heterogeneous cluster is not permitted by FIPS, as components of the system are not compliant with FIPS. Attempts to join non-FIPS and FIPS nodes or servers may fail. Federation between non-FIPS and FIPS clusters is not supported and may fail.

Technical details

Nomad's FIPS 140-3 Linux products use the Go Cryptographic Module version 1.0.0 in the official Go 1.26+ toolchain, which include a FIPS-validated crypto module.

To ensure your build of Nomad Enterprise includes FIPS support, confirm that the version command includes the string fips1403. For example:

Nomad v2.0.5+ent.fips1403

In addition, the following message appears in the agent's banner on startup.

Fips Mode: FIPS-140-3 enabled (version: v1.0.0)

Validating FIPS crypto modules

To validate that a FIPS 140-3 Linux binary is configured correctly to enable the Go Cryptographi Module, run go version -m on the binary to get build metadata.

$ go version -m ./nomad | grep FIPS
    build   GOFIPS140=v1.0.0-c2097c7c

On both Linux and Windows non-FIPS builds, the search output yields no results.

Certification

Nomad Enterprise FIPS compliance has not yet been independently certified.