# 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](https://go.dev/doc/security/fips140).

The cryptographic module embedded in Kedify binaries is the Go Cryptographic Module, and its CMVP status is [tracked by the upstream Go team](https://go.dev/security/fips140). 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](https://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:

```sh
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:

```sh
# 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](https://go.dev/doc/security/fips140) 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.

```yaml
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`](https://hub.docker.com/r/hashicorp/envoy-fips) (free, BoringSSL FIPS, linux/amd64 + linux/arm64).

- [Chainguard `envoy-fips`](https://images.chainguard.dev/directory/image/envoy-fips/overview) (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`](https://docs.kedify.io/attestations/agent-fips-140-3.md) / [`.sig`](https://docs.kedify.io/attestations/agent-fips-140-3.md.sig) | [`agent-fips-140-3.pdf`](https://docs.kedify.io/attestations/agent-fips-140-3.pdf) / [`.sig`](https://docs.kedify.io/attestations/agent-fips-140-3.pdf.sig) |
| Kedify build of KEDA | [`keda-fips-140-3.md`](https://docs.kedify.io/attestations/keda-fips-140-3.md) / [`.sig`](https://docs.kedify.io/attestations/keda-fips-140-3.md.sig) | [`keda-fips-140-3.pdf`](https://docs.kedify.io/attestations/keda-fips-140-3.pdf) / [`.sig`](https://docs.kedify.io/attestations/keda-fips-140-3.pdf.sig) |
| Kedify HTTP Add-on | [`http-add-on-fips-140-3.md`](https://docs.kedify.io/attestations/http-add-on-fips-140-3.md) / [`.sig`](https://docs.kedify.io/attestations/http-add-on-fips-140-3.md.sig) | [`http-add-on-fips-140-3.pdf`](https://docs.kedify.io/attestations/http-add-on-fips-140-3.pdf) / [`.sig`](https://docs.kedify.io/attestations/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](https://docs.kedify.io/kedify-cosign.pub):

```sh
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.

```sh
# 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:

```sh
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](mailto:support@kedify.io).

## References

- Go Cryptographic Module CMVP status: [go.dev/security/fips140](https://go.dev/security/fips140)

- Go FIPS 140-3 documentation: [go.dev/doc/security/fips140](https://go.dev/doc/security/fips140)

- NIST CMVP program: [csrc.nist.gov/projects/cryptographic-module-validation-program](https://csrc.nist.gov/projects/cryptographic-module-validation-program)

## Continue with this topic

**Reference:** [Versions](https://docs.kedify.io/getting-started/versions/).

**Related capabilities:** [Security & Compliance](https://docs.kedify.io/security-and-compliance/) · [Access, telemetry and connectivity boundaries](https://docs.kedify.io/security-and-compliance/access-and-data/).

Technical content reviewed Sep 21, 2026.

---
Canonical: https://docs.kedify.io/security-and-compliance/fips/
Source: src/content/docs/security-and-compliance/fips.mdx
Documentation index: https://docs.kedify.io/llms.txt