Deploy FIPS 140-3 compliant Consul servers
Builds of Consul Enterprise marked with a fips1403 feature name include built-in support for FIPS 140-3 compliance.
To use this feature, you must have an active or trial license for Consul Enterprise. To start a trial, contact HashiCorp sales.
Enterprise
This feature requires Consul Enterprise(opens in new tab).
Using FIPS 140-3 Consul Enterprise
FIPS 140-3 builds of Consul Enterprise behave in the same way as non-FIPS builds. There are no restrictions on Consul algorithms, and ensuring that Consul 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. Consul products surface some helpful warnings where settings are insecure.
Encryption is disabled in Consul Enterprise by default. As a result, Consul may transmit sensitive control plane information. You must ensure that gossip encryption and mTLS is enabled for all agents when running Consul with FIPS-compliant settings.
HashiCorp is not a NIST-certified testing laboratory and can only provide general guidance about using Consul Enterprise in a FIPS-compliant manner. We recommend consulting an approved auditor for further information.
The FIPS 140-3 variant of Consul uses separate binaries that are available from the following sources:
- The HashiCorp Releases page, releases ending with the
+ent.fips1403suffix. - The Docker Hub
hashicorp/consul-enterprise-fipscontainer repository. - The AWS ECR
hashicorp/consul-enterprise-fipscontainer repository. - The Red Hat Access
hashicorp/consul-enterprise-fipscontainer repository.
The aforementioned naming conventions, which append .fips1403 to binary names and tags, and -fips to registry names, also apply to consul-k8s, consul-k8s-control-plane, consul-dataplane, and consul-ecs, which are packaged separately from Consul Enterprise.
Artifact names
Releases that support FIPS 140-3 use different artifact names than releases that support FIPS 140-2. Update any automation that pins FIPS artifact names, package names, or version strings before you upgrade.
| Artifact | FIPS 140-2 | FIPS 140-3 |
|---|---|---|
| Consul Enterprise version metadata | +ent.fips1402 | +ent.fips1403 |
consul-k8s, consul-dataplane, and consul-ecs version metadata | +fips1402 | +fips1403 |
| Operating system packages | consul-F2_1.20.4-1_amd64.deb | consul-F3_1.20.4-1_amd64.deb |
| Envoy container images | hashicorp/envoy-fips:VERSION-fips1402 | hashicorp/envoy-fips:VERSION-fips1403 |
Usage restrictions
When using Consul 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 Consul to FIPS builds of Consul, regardless of version. A fresh cluster installation is required to support FIPS 140-3. You cannot upgrade directly to a FIPS-compliant build.
You can upgrade from a FIPS 140-2 build to a FIPS 140-3 build. Refer to heterogeneous cluster deployments for more information.
TLS restrictions
Consul Enterprise's FIPS modifications include restrictions to supported TLS cipher suites and key information. Only the following TLS v1.2 cipher suites are allowed:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Only the following TLS v1.3 cipher suites are allowed:
In addition, only the following key types are allowed in TLS chains of trust:
- RSA 2048-bit and larger
- ECDSA P-256, P-384, and P-521
- Ed25519
Both TLS v1.2 and TLS v1.3 are supported in FIPS mode. When a connection uses TLS v1.2, both peers must support the extended master secret extension described in RFC 7627. Handshakes with peers that do not support the extension fail.
Heterogeneous cluster deployments
We do not support deployment scenarios that mix FIPS and non-FIPS Consul binaries within the same cluster. Running a heterogeneous cluster is not permitted by FIPS, as components of the system are not compliant with FIPS. When an agent attempts to join a cluster whose FIPS status does not match its own, the join fails with a Cannot join FIPS and non-FIPS Consul error.
Agents that support FIPS 140-2 and agents that support FIPS 140-3 can join the same cluster. Both levels use approved cryptographic primitives, so you can perform a rolling upgrade from +ent.fips1402 to +ent.fips1403 without restarting the entire cluster at once.
Envoy
To enable users to deploy a FIPS compliant service mesh with Consul, HashiCorp provides FIPS compliant versions of Envoy available for download. Contact Hashicorp sales for more information.
Deployment prerequisites
Depending on your Consul runtime, there are additional requirements for using FIPS 140-3.
VMs
If using Consul on VMs, you must use a FIPS compliant version of Envoy. Contact HashiCorp sales to learn how to obtain a FIPS compliant version of Envoy.
consul-k8s and Helm
When deploying the FIPS builds of Consul on Kubernetes using consul-k8s or Helm, you must ensure that the Helm chart is updated to use FIPS builds of Consul Enterprise, Consul Dataplane, and Envoy images.
Technical details
Consul's FIPS 140-3 products use the Go Cryptographic Module, a cryptographic module included in the official Go toolchain. HashiCorp builds these products with GOFIPS140=v1.0.0 so that the binary links the module version that holds CMVP certificate #5247. Linux and Windows builds use the same module.
Because the module is written in Go, FIPS 140-3 binaries do not depend on cgo. Unlike FIPS 140-2 Linux binaries, they do not require a GNU C Library (glibc) Linux distribution.
To ensure your build of Consul Enterprise includes FIPS support, confirm that a line beginning with FIPS: appears when you run a version command. For example, the following message appears when the agent operates in FIPS mode:
FIPS: FIPS 140-3 Enabled, crypto module v1.0.0
FIPS mode at runtime
FIPS builds of Consul set fips140=on as the default value of the GODEBUG environment variable, so the binary operates in FIPS mode without additional configuration.
This default is not an enforcement. If you set GODEBUG=fips140=off in the agent's environment, the binary starts without FIPS mode enabled. The agent then reports that FIPS is not enabled, stops advertising FIPS status to other agents, and cannot join a FIPS cluster. Do not override the fips140 setting in GODEBUG on agents that must operate in FIPS mode.
Validating FIPS crypto modules
To validate that a binary links the certified cryptographic module, run go version -m on the binary and inspect its build settings.
$ go version -m consul | grep -e GOFIPS140 -e DefaultGODEBUG -e tags
build -tags=consulent,fips,fips140v1.0
build DefaultGODEBUG=fips140=on
build GOFIPS140=v1.0.0
Non-FIPS builds do not report the GOFIPS140 or DefaultGODEBUG=fips140=on build settings.
Leidos validation
In 2024, Leidos certified the integration of FIPS 140-2 cryptographic module BoringCrypto Cert. #4407 for the following Consul releases:
- Consul Enterprise builds:
- Consul Dataplane builds:
- Consul K8s builds:
- Consul K8s Control Plane builds:
For more information about verified platform architectures and confirmed feature support, review the Leidos certification letter.