For the complete documentation index and AI-optimized content, see /llms.txt. All pages support markdown format via .md extension or Accept: text/markdown header.

FIPS 140-3 Compliance

For the complete documentation index and AI-optimized content, see /llms.txt. All pages support markdown format via .md extension or Accept: text/markdown header.

Kedify ships hardened container image variants whose Go binaries are built against the Go Cryptographic Module v1.0.0, a FIPS 140-3 in-process module maintained by the upstream Go security team. When a *-hardened Kedify image is run, all approved cryptographic operations performed by the Go binary go through that module. Non-approved primitives are not allowed, preventing accidental use of weak algorithms in regulated environments.

The cryptographic module embedded in Kedify binaries is the Go Cryptographic Module, and its CMVP status is tracked by the upstream Go team. Customers in regulated environments who need a FIPS compliant build but do not strictly require a CMVP-certified vendor product can use the Kedify hardened images directly.

FIPS Compliant Images

The latest released images embedding the Go FIPS 140-3 module are:

ghcr.io/kedify/agent:v0.5.7-hardened
ghcr.io/kedify/keda-operator:v2.19.0-3-hardened
ghcr.io/kedify/keda-admission-webhooks:v2.19.0-3-hardened
ghcr.io/kedify/keda-metrics-apiserver:v2.19.0-3-hardened
ghcr.io/kedify/http-add-on-operator:v0.11.1-4-hardened
ghcr.io/kedify/http-add-on-interceptor:v0.11.1-4-hardened
ghcr.io/kedify/http-add-on-scaler:v0.11.1-4-hardened

Tags without the -hardened suffix (:vX.Y.Z, :latest) are not FIPS compliant. They use upstream Go’s standard crypto and are intended for environments where FIPS is not a requirement.

Cryptographic module

Item	Value
Module name	Go Cryptographic Module
Module version	v1.0.0
FIPS standard	FIPS 140-3
CMVP status	Tracked at go.dev/security/fips140
Build flag (Go)	`GOFIPS140=v1.0.0`
Required Go version	1.24 or later
External dependencies	None. The module is statically compiled into each Kedify binary.

The CMVP cert state for the Go Cryptographic Module changes over time as it moves through validation. The link above is the source of truth at any given moment.

Verification

Each -hardened Kedify image carries OCI labels announcing the embedded module. Customers can confirm a pulled image was built with the FIPS module without running it:

docker inspect ghcr.io/kedify/agent:latest-hardened \
  --format '{{ index .Config.Labels "io.kedify.crypto.module" }} {{ index .Config.Labels "io.kedify.crypto.version" }}'
# Expected: go-fips140 v1.0.0

For a stronger check, extract the binary from the image and inspect its build settings with the Go toolchain:

# Pull a hardened image and copy out the manager binary
docker create --name kedify-fips-check ghcr.io/kedify/agent:v0.5.7-hardened
docker cp kedify-fips-check:/manager ./manager-hardened
docker rm kedify-fips-check

# Confirm the FIPS module is linked
go version -m ./manager-hardened | grep GOFIPS140
# Expected: build  GOFIPS140=v1.0.0

The same pattern works for any of the Kedify hardened images. Replace /manager with the binary path inside that image (/keda, /keda-adapter, /keda-admission-webhooks, /operator, /interceptor, /scaler).

Kedify’s release pipeline runs the equivalent check on every hardened binary before publishing the image. A build that does not embed GOFIPS140=v1.0.0 fails the pipeline, so the announced labels and the actual binary state cannot drift.

Host requirements

The FIPS-validated cryptographic module is statically compiled into each Kedify binary. There is no dependency on host OpenSSL, system crypto policies, or kernel fips=1 mode. Kedify hardened images run identically on:

a stock Linux host (any distribution, any kernel)
a host configured with fips=1 and update-crypto-policies --set FIPS
a hardened RHEL / UBI host
a Chainguard-based or distroless minimal host

Kedify’s model is in-process: each binary carries its own validated cryptographic module, so the host does not need to be FIPS-configured for the application to be FIPS compliant. The verification command above produces the same result regardless of host configuration.

Kedify Proxy

The kedify-proxy data plane is a fleet of Envoy instances configured over xDS by the http-add-on interceptor. The kedify-proxy Helm chart’s default image is upstream envoyproxy/envoy, which is not a FIPS-built variant.

Envoy is implemented in C++ and relies on a FIPS-validated TLS library (BoringSSL FIPS or AWS-LC FIPS) chosen at build time. Upstream Envoy does not publish a separate FIPS Docker image today: FIPS Envoy is a build-from-source configuration (--config=boringssl-fips or --config=aws-lc-fips), and pre-built FIPS images are published only by third-party distributors. The user chooses which distribution to deploy; the kedify-agent chart provides the override mechanism.

Configuring a FIPS Envoy image

Override agent.kedifyProxy.globalValues.image in the kedify-agent chart values. Settings under globalValues flow through to every deployed kedify-proxy instance. Per-namespace overrides are available via agent.kedifyProxy.namespacedValues.<namespace>.image if a subset of namespaces needs a different Envoy build.

agent:
  kedifyProxy:
    globalValues:
      image:
        repository: <fips-envoy-distribution>
        tag: <version-from-that-distribution>

Distribution options

These are third-party FIPS-built Envoy images:

hashicorp/envoy-fips (free, BoringSSL FIPS, linux/amd64 + linux/arm64).
Chainguard envoy-fips (FedRAMP-aligned, paid tier).

Either is a drop-in for image.repository / image.tag. Users inherit the distributor’s release cadence and FIPS posture.

Verification

To verify a FIPS Envoy build, users should rely on the chosen distribution’s published evidence (HashiCorp’s release notes and SBOM, Chainguard’s compliance documentation), plus image-digest pinning in the chart values to lock the build that was reviewed.

Per-release attestation

Each Kedify release that ships hardened images contains a FIPS attestation: signed document listing the exact image manifests in scope, the embedded module and version, the build evidence, and reproducible verification commands. The latest attestation for each component is available at the table below:

Component	Markdown	PDF
Kedify Agent	`agent-fips-140-3.md` / `.sig`	`agent-fips-140-3.pdf` / `.sig`
Kedify build of KEDA	`keda-fips-140-3.md` / `.sig`	`keda-fips-140-3.pdf` / `.sig`
Kedify HTTP Add-on	`http-add-on-fips-140-3.md` / `.sig`	`http-add-on-fips-140-3.pdf` / `.sig`

Signing model

Kedify signs each attestation document and each hardened container manifest with a long-lived Cosign keypair. The public key is published at docs.kedify.io/kedify-cosign.pub:

curl -O https://docs.kedify.io/kedify-cosign.pub

The same key signs every release, verifying an attestation or an image only requires that public key.

Verify the attestation document

Download the latest attestation and its signature, then verify with the public key.

# Markdown
curl -fLO https://docs.kedify.io/attestations/keda-fips-140-3.md
curl -fLO https://docs.kedify.io/attestations/keda-fips-140-3.md.sig
cosign verify-blob \
  --key https://docs.kedify.io/kedify-cosign.pub \
  --signature keda-fips-140-3.md.sig \
  keda-fips-140-3.md

# PDF
curl -fLO https://docs.kedify.io/attestations/keda-fips-140-3.pdf
curl -fLO https://docs.kedify.io/attestations/keda-fips-140-3.pdf.sig
cosign verify-blob \
  --key https://docs.kedify.io/kedify-cosign.pub \
  --signature keda-fips-140-3.pdf.sig \
  keda-fips-140-3.pdf

Similarly for the agent and HTTP Add-on attestations. A passing verification proves the document was signed by Kedify and has not been tampered with since signing.

Verify a hardened image manifest

The attestation pins each hardened image by tag and digest. Verify the published manifest directly against the public key:

cosign verify \
  --key https://docs.kedify.io/kedify-cosign.pub \
  ghcr.io/kedify/<image>:<tag>-hardened

A passing verification proves that the image bytes match what was attested for that release. The full set of image references for the current release is listed in the attestation document.

Reporting and contact

Security findings related to the FIPS posture (a hardened image that fails verification, an unexpected non-approved primitive in a code path, a procurement question requiring a written response) should be sent to support@kedify.io.

References

Go Cryptographic Module CMVP status: go.dev/security/fips140
Go FIPS 140-3 documentation: go.dev/doc/security/fips140
NIST CMVP program: csrc.nist.gov/projects/cryptographic-module-validation-program