thorasVersion 4.132.0 or newer, which is the first release that
publishes -fips images.
What changes
- Every Thoras image tag gets a
-fipssuffix:thorasVersion4.132.0pullsservices:4.132.0-fips. A per-componentimageTagoverride gets the same suffix. A tag that already ends in-fipsis used as is, and a tag with a digest fails the render, because a digest cannot take the suffix. - The Go binaries (the
servicesimage and oauth2-proxy) run withGODEBUG=fips140=onand use the Go Cryptographic Module v1.0.0 (CMVP certificate 5247). - The forecast worker image uses the UBI 9 system OpenSSL with the Red Hat FIPS provider enforced.
- The oauth2-proxy sidecar uses
thorasDashboard.auth.fipsImageTag.
Requirements
The chart refuses to render unless all of these are set:- An external database. The bundled TimescaleDB has no FIPS build. Set
externalTimescaleand run the database on your own FIPS platform. The DSN must containsslmode=verify-fullexactly once, and the database password must be at least 14 bytes, because FIPS mode rejects shorter HMAC keys. See External TimescaleDB. - No htpasswd dashboard sign-in. It checks a bcrypt hash, which is not FIPS
approved. Use OIDC (
thorasDashboard.auth.mode: oidc), turn dashboard auth off and put your own in front, or turn the dashboard off. See Dashboard authentication. - cert-manager for the webhook certificates
(
thorasOperator.webhookCertGen.certManager.enabled: true). The kube-webhook-certgen Jobs are not used.
alpine, httpd or kube-webhook-certgen.
Example values
GODEBUG with fips140=only: oauth2-proxy does not start in
that mode. A GODEBUG you set in env is applied after the chart’s, so the
container keeps yours.
Further reading
- FIPS mode in the chart README for the exact render-time checks.

