Fips Compliance

FIPS Compliance

Guidance for enforcing Federal Information Processing Standards (FIPS) 140-2 and 140-3 across RHEL/RHCOS nodes, OpenShift clusters, Go applications, and container workloads. For general algorithm guidance and post-quantum readiness, see algorithm-selection. For TLS version and cipher suite enforcement on Kubernetes, see tls-compliance.

FIPS Mode Enforcement

Critical: OpenShift FIPS mode must be enabled at install time — it cannot be enabled post-deployment. The installer must run from a RHEL host already in FIPS mode, using the openshift-install-fips binary extracted from the release image.

SSH keys: Do not use ed25519 keys when installing a FIPS-enabled cluster. ed25519 is not FIPS-approved — use RSA instead.

FIPS-Approved and Prohibited Algorithms

FIPS and PQC are mutually exclusive today. Post-quantum algorithms like X25519MLKEM768 cannot be used on FIPS-enabled clusters because they have not been submitted to NIST for FIPS validation. Plan for this to change as NIST completes PQC module validation.

RHEL Crypto Policies

RHEL system-wide crypto policies enforce FIPS constraints across all crypto libraries (OpenSSL, GnuTLS, NSS, libgcrypt, Kernel Crypto API).

bashCopy code
# Set FIPS policy
update-crypto-policies --set FIPS

# Verify active policy
update-crypto-policies --show

Subpolicies

Apply subpolicies on top of FIPS for additional restrictions or compatibility workarounds:

Custom Subpolicies

Create .pmod files in /etc/crypto-policies/policies/modules/ for site-specific restrictions:

iniCopy code
# /etc/crypto-policies/policies/modules/SITE.pmod
cipher@SSH = -CHACHA20-POLY1305
ssh_etm = 0

bashCopy code
update-crypto-policies --set FIPS:SITE

Go FIPS Builds

Two distinct paths exist for building FIPS-compliant Go binaries. Choose based on your environment.

Red Hat Go Toolset (RHEL)

Red Hat's Go toolset routes crypto calls to the FIPS-validated OpenSSL module via CGO — it does not use Google's BoringCrypto.

goCopy code
import "github.com/golang-fips/openssl/v2"

func init() {
    openssl.Init("")
}

// Check FIPS status at runtime
if openssl.FIPS() {
    // Using FIPS-validated OpenSSL path
}

bashCopy code
# Verify binary links to OpenSSL
go tool nm ./myapp | grep -i dlopen_openssl

Upstream Go 1.24+ (Native FIPS 140-3)

Go 1.24 introduced native FIPS 140-3 support with CMVP Certificate #5247, independent of Red Hat's OpenSSL approach.

When FIPS mode is active, Go performs integrity self-checks at init, runs known-answer self-tests per FIPS 140-3 Implementation Guidance, and restricts crypto/tls to approved cipher suites and key exchange mechanisms.

Common Violations

Historical: CVE-2023-3089

OpenShift 4.10–4.12 Go components were not configured to use FIPS-validated crypto modules, defaulting to Go's standard crypto library instead of OpenSSL. Approximately 50% of certificates on affected clusters were produced by non-compliant modules. Remediation required updating to patched releases and rotating certificates (or full reinstall for the most regulated environments). Red Hat has since added build-time enforcement policies that terminate builds using non-compliant crypto.

TLS in FIPS Mode

FIPS-Approved Cipher Suites

FIPS mode filters out non-approved ciphers. On OpenShift, the Ingress Operator automatically detects FIPS mode and removes non-compliant ciphers.

TLS 1.2 (FIPS-approved):

TLS 1.3 (FIPS-approved):

Extended Master Secret (EMS) Enforcement

Starting with RHEL 9.2, TLS Extended Master Secret (RFC 7627) is mandatory for all TLS 1.2 connections in FIPS mode. This is a FIPS 140-3 requirement.

Breaking change: Legacy clients that do not support EMS or TLS 1.3 (including RHEL 6/7 and Go <= 1.18) cannot connect to FIPS-enabled RHEL 9.2+ systems over TLS 1.2.

Workaround (non-compliant — use only during migration):

bashCopy code
update-crypto-policies --set FIPS:NO-ENFORCE-EMS

etcd Encryption at Rest

Verification

bashCopy code
# OpenShift API server
oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

# Kubernetes API server
oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

# OAuth API server
oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

Expected output: EncryptionCompleted. Keys are rotated automatically on a weekly basis.

Limitation: Encryption keys are stored in plaintext on the nodes hosting the API server, co-located with etcd. This provides protection for etcd backups and offline disk access, but limited benefit against node-level compromise.

Operator and Workload Considerations

• cert-manager: Certificate resources must specify FIPS-compliant key algorithms — RSA >= 2048 or ECDSA P-256/P-384 via spec.privateKey.algorithm and spec.privateKey.size. Do not use ed25519.
• Service mesh: mTLS cipher suites must use FIPS-approved algorithms only. Post-quantum key exchange (X25519MLKEM768) is not available on FIPS-enabled clusters. Ambient mode (ztunnel) supports FIPS 140-2 with TLS 1.2.
• Container images: Use FIPS-enabled UBI base images (registry.access.redhat.com/ubi9/ubi-minimal). The Red Hat Go toolchain must be used for the build stage. OpenSSL must be present in the runtime image.
• Containers inherit host FIPS: Containers detect FIPS mode via /proc/sys/crypto/fips_enabled from the host kernel — no per-container FIPS configuration is needed.
• FIPS validation terminology: Use "FIPS validated" (applies to cryptographic modules). "FIPS compliant" and "FIPS certified" are incorrect terms per NIST.

FIPS Validation Status

Red Hat submits five cryptographic modules per RHEL release for NIST CMVP validation:

Auditing FIPS Compliance

bashCopy code
# Verify all nodes have FIPS kernel enabled
oc debug node/<node> -- chroot /host cat /proc/sys/crypto/fips_enabled

# Check crypto policy on nodes
oc debug node/<node> -- chroot /host update-crypto-policies --show

# Verify FIPS boot parameter
oc debug node/<node> -- chroot /host grep -o 'fips=[01]' /proc/cmdline

# Check IngressController TLS profile (should not include ChaCha20 on FIPS clusters)
oc get ingresscontroller default -n openshift-ingress-operator -o jsonpath='{.spec.tlsSecurityProfile}'

# Verify etcd encryption status
oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}'

# Verify Go binary uses OpenSSL (Red Hat Go toolset)
go tool nm <binary> | grep -i dlopen_openssl

# Check kernel FIPS self-test results
oc debug node/<node> -- chroot /host journalctl -b | grep -i fips

Implementation Checklist

• Cluster installed with fips: true in install-config from a FIPS-enabled RHEL host
• All nodes report fips_enabled = 1 via /proc/sys/crypto/fips_enabled
• Crypto policy set to FIPS (verify with update-crypto-policies --show)
• Go binaries built with CGO_ENABLED=1 and dynamic linking (Red Hat path) or GOFIPS140=latest (upstream Go 1.24+)
• No static linking, no_openssl tags, or golang.org/x/crypto usage in FIPS-critical paths
• etcd encryption at rest enabled (aescbc or aesgcm) — not identity
• TLS cipher suites restricted to FIPS-approved algorithms (no ChaCha20-Poly1305)
• EMS enforcement verified for TLS 1.2 connections (RHEL 9.2+) or NO-ENFORCE-EMS applied with documented justification
• cert-manager Certificates use RSA >= 2048 or ECDSA P-256/P-384 — no ed25519
• Container base images are FIPS-enabled UBI with OpenSSL present
• SSH keys use RSA — no ed25519
• OCP 4.10–4.12 clusters have applied CVE-2023-3089 remediation and rotated certificates

References

• OpenShift FIPS Support Documentation
• NIST CMVP Validated Modules List
• RHEL 9 Security Hardening — Crypto Policies
• Go FIPS 140-3 Security Documentation
• Red Hat Go Toolset FIPS Mode
• Is Your Go Application FIPS Compliant?
• RHSB-2023-001: CVE-2023-3089 — OpenShift FIPS Misconfiguration
• TLS Extended Master Secret and FIPS in RHEL
• RHEL Core Cryptographic Components
• OpenShift FIPS Compliance FAQ