FIPS 140-3 Compliance

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. FIPS mode performs module self-tests and restricts supported TLS negotiation; the build flag alone does not prohibit every non-approved operation exposed by Go APIs. See the Go FIPS mode documentation.

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.8.0-hardened
• ghcr.io/kedify/keda-operator:v2.21.0-0-hardened
• ghcr.io/kedify/keda-admission-webhooks:v2.21.0-0-hardened
• ghcr.io/kedify/keda-metrics-apiserver:v2.21.0-0-hardened
• ghcr.io/kedify/http-add-on-operator:v0.11.1-6-hardened
• ghcr.io/kedify/http-add-on-interceptor:v0.11.1-6-hardened
• ghcr.io/kedify/http-add-on-scaler:v0.11.1-6-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 Go cryptographic module is linked into the binary rather than supplied by host OpenSSL or kernel fips=1 mode. This removes a dependency on the host’s crypto library; it does not establish compliance on every distribution, kernel or architecture.

Check the selected module’s validation certificate and Security Policy for approved operating environments and conditions of use. A build-setting check proves which module was selected, not that the whole deployment meets a particular compliance requirement. The Go guidance distinguishes module use, runtime mode and validation scope. Its restrictive fips140=only mode is intended for testing and assessment, not production.

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

Continue with this topic

Reference: Versions.

Related capabilities: Security & Compliance · Access, telemetry and connectivity boundaries.