> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify Image Signatures

> Confirm that a 2501 container image is authentic and unmodified, using a public key you hold and no 2501 service

Every container image 2501 publishes is signed with a single ECDSA P-256 key held in AWS KMS. The private half is non-exportable and never leaves KMS. We publish the public half so you can verify any image against a key you hold, with no call to a 2501 service, using [cosign](https://github.com/sigstore/cosign).

## Signing key

```
https://keys.2501.ai/cosign.pub
```

Download the key once and keep your own copy. Its SHA-256 fingerprint is:

```
9bd13e17f78c78dfd21a4b1c8c19804df24f501620a27d5a25fa24c56eaa2d55
```

Check what you downloaded against it, and pin that fingerprint in your own procedures:

```bash theme={null}
curl -fsSL https://keys.2501.ai/cosign.pub | sha256sum
```

We announce any key rotation in the release notes, so treat an unannounced change as a verification failure. A superseded key stays published under a dated name, so images signed with it remain verifiable.

## Verify an image

Verify against the image digest, not the tag: a tag can be reassigned, a digest cannot.

```bash theme={null}
cosign verify \
  --key https://keys.2501.ai/cosign.pub \
  --insecure-ignore-tlog=true \
  <registry>/engine@sha256:<digest>
```

If verification fails, do not deploy the image. Keep the digest and the cosign output, and contact 2501 support.

## Verify the installation files

Every file of a Release on [github.com/2501-ai/install](https://github.com/2501-ai/install) comes with its signature, `<file>.bundle`, made with the same key. Verify each file before you apply it:

```bash theme={null}
cosign verify-blob \
  --key https://keys.2501.ai/cosign.pub \
  --insecure-ignore-tlog=true \
  --bundle 2501-<build>.tgz.bundle \
  2501-<build>.tgz
```

If verification fails, do not use the file: download it again, and contact 2501 support if it still fails.

The chart and `compose.yaml` carry the digest of every image they run, so a verified file installs only the images it was built with. Verify those images too when you copy them into your registry.

## Verify the chart in the registry

The chart of each build is also at `oci://ghcr.io/2501-ai/charts/2501`, with the build as its version, signed with the same key. Verify it before Helm or ArgoCD pulls it:

```bash theme={null}
cosign verify \
  --key https://keys.2501.ai/cosign.pub \
  --insecure-ignore-tlog=true \
  ghcr.io/2501-ai/charts/2501:<build>
```

## Verify the SBOM

Every image carries a software bill of materials (SBOM), the full list of packages it contains, in SPDX format. It is signed with the same key:

```bash theme={null}
cosign verify-attestation \
  --key https://keys.2501.ai/cosign.pub \
  --insecure-ignore-tlog=true \
  --type spdxjson \
  <registry>/engine@sha256:<digest>
```

> [!NOTE]
>
> `--insecure-ignore-tlog=true` is required. We sign without publishing to the public Rekor transparency log, so verification rests on the key alone. The flag disables the transparency-log lookup, not the signature check.

## Verify without network access

`--key` also accepts a local file, so the check needs no route to us once the key is on the host. Fetch the key on a connected machine, confirm its fingerprint, then carry it across:

```bash theme={null}
cosign verify \
  --key cosign.pub \
  --insecure-ignore-tlog=true \
  <registry>/engine@sha256:<digest>
```

cosign stores the signature and the SBOM attestation in the registry beside the image, under tags derived from its digest. A mirrored or air-gapped registry has to carry those across too, or there is nothing left to verify against. `cosign save` writes the image and both to disk for transfer and `cosign load` pushes them into the destination registry; `oras copy -r` does the same registry to registry.

## Enforce verification at admission

On Kubernetes you can reject unsigned images at admission rather than verifying them by hand. Any policy engine with cosign key verification works, Kyverno and the Sigstore Policy Controller among them: point it at the same key, and disable the transparency-log check as above. This is how 2501 operates its own clusters.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.