Supply-Chain Evidence

Running cloudtaser is a trust shift. You are moving responsibility for secret handling FROM "the US cloud provider + their build pipelines + their signing root" TO "cloudtaser + OpenBao + your chosen EU substrate + cloudtaser's build pipelines." That shift is the product. This page gives you the cryptographic handle to audit the cloudtaser side of that shift, so you have evidence -- not assurance -- that the bits you run are the bits we shipped.

What release verification establishes

Release images, binary checksum manifests and chart archives carry key signatures. SBOM availability varies by release. The public installer carries its verification key in its own content rather than downloading the key beside the artefact. A Sigstore bundle may carry transparency-log evidence; its presence alone does not establish inclusion (the chart 1.0.359 bundle has zero log entries). These are separate properties: a pinned-key signature authenticates the signer, while a verified log entry additionally proves transparency-log inclusion. You still trust the reviewed installer revision and the channel that delivers it.

---

What we sign

Artefact type	Signing mechanism	Distribution
Container images (operator, wrapper, eBPF agent, port, beacon, S3/DB proxy, init container)	cosign sign with a signing key delivered through the CI secret store as a filesystem input; some release steps copy it into a credential file against GAR (europe-west4-docker.pkg.dev/skipopsmain/cloudtaser/*) tags, recursive across multi-arch manifests	Registry-attached signatures
Linux binaries (port, enroll, CLI, wrapper, etc.)	Signed SHA256SUMS authenticates the binary digest; per-binary .sig availability varies by component/release	https://releases.cloudtaser.io/<component>/<version>/
Checksums file	cosign sign-blob produces SHA256SUMS.sig	Same release URL
SBOM	syft can generate SPDX JSON; inspect the individual release for availability and signature evidence	Not present at the release URLs for CLI v0.19.173, beacon v0.6.23 or Port v0.4.133
Helm charts	Archive key signature in .tgz.sigstore.json; inspect each bundle separately for transparency-log evidence	https://charts.cloudtaser.io

CloudTaser signing steps hard-fail in CI if the signing key is missing. Third-party chart helpers have the narrower evidence described below.

---

Trust root -- the public key

The single public key that validates every cloudtaser signature:

• Installer pin: SHA-256 036dd71c9d3c07a19bff06d4392874014573f695620ac8554d9df175094c4a31
• Convenience copy: https://releases.cloudtaser.io/keys/release.pub
• Format: PEM-encoded ECDSA P-256 (cosign.pub)

The convenience URL is not an independent trust root when it is downloaded from the same origin as the artefact. The public install.sh therefore embeds the PEM and checks its fingerprint before using it. A release-origin compromise cannot replace the binary, checksum, signature, and verification key together. For air-gapped or manual verification, copy the key from a reviewed installer revision or another independently controlled source and verify its fingerprint. Embedding the key protects against compromise of the release artefact origin; it does not protect against an attacker who can replace the installer itself.

Rotating the key is a versioned event

A planned rotation starts with a reviewed installer update that embeds both old and new public keys and records both fingerprints. A rotation statement signed by both keys defines the overlap deadline; only after that overlap may a second reviewed installer update remove the old key. Releases do not switch signers before the dual-key installer is published. Emergency revocation follows the same independently published update path, but may omit the overlap when the old private key is suspected compromised.

---

How to verify an image

The recorded verification used this operator example with Cosign v3.1.4, exiting zero on the source VM and in a clean management-host environment, for chart 1.0.359 and operator v0.13.209. Release source signs images with --tlog-upload=false; its verification helper uses --insecure-ignore-tlog. This checks a key signature without claiming transparency-log inclusion.

set -euo pipefail
# Fetching from the release origin is convenient, but verify this fingerprint
# against the independently published installer or your own pinned copy.
curl -sSLf https://releases.cloudtaser.io/keys/release.pub -o release.pub
printf '%s  %s\n' \
  036dd71c9d3c07a19bff06d4392874014573f695620ac8554d9df175094c4a31 \
  release.pub | sha256sum -c -

# Authenticate the requested version and read its signed index digest.
ORIGIN="https://releases.cloudtaser.io/operator/v0.13.209"
curl --fail --silent --show-error --proto '=https' "$ORIGIN/release.json" -o operator-release.json
curl --fail --silent --show-error --proto '=https' "$ORIGIN/release.json.sig" -o operator-release.json.sig
base64 -d operator-release.json.sig > operator-release.signature
openssl dgst -sha256 -verify release.pub \
  -signature operator-release.signature operator-release.json
jq -e '.component == "operator" and .version == "v0.13.209"' operator-release.json >/dev/null
REPOSITORY=europe-west4-docker.pkg.dev/skipopsmain/cloudtaser/cloudtaser-operator
DIGEST=$(jq -er --arg r "$REPOSITORY" '.images[$r].index' operator-release.json)
printf '%s\n' "$DIGEST" | grep -Ex 'sha256:[0-9a-f]{64}' >/dev/null
IMAGE="$REPOSITORY@$DIGEST"
cosign verify --key release.pub --insecure-ignore-tlog "$IMAGE"

A successful command must exit zero and report the expected verified image digest. On failure, do not deploy. No Rekor UUID is expected for these signatures. Cosign v3.1.4 printed Existence of the claims in the transparency log was verified offline even with --insecure-ignore-tlog; no log entry exists for these signatures. That output is not evidence of inclusion.

The first management-host verification failed UNAUTHORIZED at the registry token endpoint because of a stale Podman credential in its XDG_RUNTIME_DIR auth environment. The same block passed in a clean environment and on the source VM. Check the host's registry credential selection or use a reviewed clean credential environment; keep signature/digest checks enabled.

Verifying all cloudtaser-managed images before a release

Repeat the signed-metadata and digest verification for each component/version in the matched chart. Components have independent versions; do not assign one shared tag to them. The recorded verification covered all nine matched CloudTaser images with Cosign v3.1.4. Wrong-key, unsigned-helper and required-log-inclusion controls failed. For each row below, fetch /COMPONENT/VERSION/release.json and its signature from the release origin, verify both component and version, then read .images[repository].index. Compare that digest with the signed chart's selected image before verification. Repository names below share prefix europe-west4-docker.pkg.dev/skipopsmain/cloudtaser/:

Release component	Matched version	Image repository suffix(es)
operator	v0.13.209	cloudtaser-operator
wrapper	v0.2.207	cloudtaser-wrapper, cloudtaser-wrapper-init
ebpf	v0.13.164	cloudtaser-ebpf
port	v0.4.133	cloudtaser-port, cloudtaser-bootstrap
beacon	v0.6.23	cloudtaser-beacon
db-proxy	v0.1.55	cloudtaser-db-proxy
s3-proxy	v0.2.61	cloudtaser-s3-proxy

In chart 1.0.359, eBPF is v0.13.164 and DB proxy is v0.1.55; wrapper-init metadata belongs to component wrapper, not wrapper-init. Image-signature success does not qualify proxy serving on the host-Port path.

The chart also uses third-party busybox (including the beacon-auth-key-receiver) and alpine/k8s images. They returned no signatures found with the CloudTaser release key. Their digests are pinned by the signed chart; they are not release-key signed. Retain that distinction when reviewing the complete render.

---

How to verify a binary

Use the signed checksum manifest, then check the selected binary's digest. A per-binary .sig is not guaranteed: CLI v0.19.173 publishes SHA256SUMS.sig, while cloudtaser-cli-linux-amd64.sig returns 404. The matched CLI and beacon commands below use the manifest route verified in the recorded verification run. The Port installer verifies its pinned release metadata and digest.

Fetch and verify the matched host release

These commands target Linux amd64, the measured host platform. Require Bash, curl, OpenSSL, base64, sha256sum, jq and tar. Run in root Bash with tracing off. On both source/management and relay hosts, fetch the pinned public key and CLI v0.19.176. The recorded verification used CLI v0.19.176 on both EU hosts, verifying the checksum signature, binary digest and signed release.json:

set +x
set -euo pipefail
umask 077
install -d -m 0700 /root/cloudtaser-release
cd /root/cloudtaser-release
curl --fail --silent --show-error --proto '=https' \
  https://releases.cloudtaser.io/keys/release.pub -o release.pub
printf '%s  %s\n' \
  036dd71c9d3c07a19bff06d4392874014573f695620ac8554d9df175094c4a31 \
  release.pub | sha256sum -c -

fetch-verified-binary() {
  local component="$1" version="$2" binary="$3"
  local origin="https://releases.cloudtaser.io/$component/$version"
  mkdir -p "$component"
  curl --fail --silent --show-error --proto '=https' "$origin/$binary" -o "$component/$binary"
  curl --fail --silent --show-error --proto '=https' "$origin/SHA256SUMS" -o "$component/SHA256SUMS"
  curl --fail --silent --show-error --proto '=https' "$origin/SHA256SUMS.sig" -o "$component/SHA256SUMS.sig"
  base64 -d "$component/SHA256SUMS.sig" > "$component/SHA256SUMS.signature"
  openssl dgst -sha256 -verify release.pub \
    -signature "$component/SHA256SUMS.signature" "$component/SHA256SUMS"
  (cd "$component"; grep " $binary$" SHA256SUMS | sha256sum -c -)
  curl --fail --silent --show-error --proto '=https' "$origin/release.json" -o "$component/release.json"
  curl --fail --silent --show-error --proto '=https' "$origin/release.json.sig" -o "$component/release.json.sig"
  base64 -d "$component/release.json.sig" > "$component/release.json.signature"
  openssl dgst -sha256 -verify release.pub \
    -signature "$component/release.json.signature" "$component/release.json"
  jq -e --arg c "$component" --arg v "$version" --arg b "$binary" \
    --arg d "sha256:$(sha256sum "$component/$binary" | cut -d " " -f 1)" \
    '.component == $c and .version == $v and .artifacts[$b] == $d' \
    "$component/release.json" >/dev/null
}
fetch-verified-binary cli 'v0.19.176' cloudtaser-cli-linux-amd64
install -o root -g root -m 0755 cli/cloudtaser-cli-linux-amd64 /usr/local/bin/cloudtaser-cli
cloudtaser-cli version

Check the key fingerprint against this reviewed documentation or your independently pinned copy. Stop on any failed command: Verified OK for a manifest is only half the check; sha256sum must also report the selected binary OK. The signed release.json must name the requested component/version and this binary's digest. This rejects older signed CLI or beacon metadata and an older binary paired with the current record; a signature alone does not establish the requested version.

On the source/management host, in the same shell/directory, fetch and verify the chart archive, then extract the matching values files:

set -euo pipefail
CHART="cloudtaser-1.0.359.tgz"
curl --fail --silent --show-error --proto '=https' \
  "https://charts.cloudtaser.io/$CHART" -o "$CHART"
curl --fail --silent --show-error --proto '=https' \
  "https://charts.cloudtaser.io/$CHART.sigstore.json" -o "$CHART.sigstore.json"
jq -er '.messageSignature.signature' "$CHART.sigstore.json" | base64 -d > chart.signature
openssl dgst -sha256 -verify release.pub -signature chart.signature "$CHART"
tar -xzOf "$CHART" cloudtaser/Chart.yaml | grep -x 'version: 1.0.359' >/dev/null
mkdir -p matched-chart
tar -xzf "$CHART" -C matched-chart --strip-components=1 \
  cloudtaser/values-production.yaml cloudtaser/values-gke-cos.yaml

This verifies the archive bytes against the pinned release key. Chart 1.0.359 has zero transparency-log entries in its bundle; no log-inclusion claim follows. The signed archive's Chart.yaml must name the requested version before values are extracted; signed charts 1.0.358 and 1.0.357 are refused. Keep chart image/admission signature enforcement enabled as well.

On the relay host, in the shell where fetch-verified-binary was defined:

set -euo pipefail
cd /root/cloudtaser-release
fetch-verified-binary beacon 'v0.6.23' cloudtaser-beacon-linux-amd64
install -o root -g root -m 0755 beacon/cloudtaser-beacon-linux-amd64 /usr/local/bin/cloudtaser-beacon

Continue with the EU Port guide or relay setup.

Detached .sig verification authenticates the bytes against the pinned key, but it does not by itself prove transparency-log inclusion. When a release also publishes a .sigstore.json bundle, retain and inspect it with the audit evidence. The inspected chart 1.0.359 and CLI v0.19.173 checksum bundles contain no log entry; a bundle alone does not prove inclusion. The OpenSSL commands above verify key signatures. Cosign bundle verification has not been run here.

The verification chain is the pinned key, the signed checksums file, and the matching digest of the selected binary.

---

How to fetch an SBOM

SBOM publication is not established for this matched release set: sbom.spdx.json returns 404 for CLI v0.19.173, beacon v0.6.23 and Port v0.4.133. For releases that publish an SPDX SBOM, fetch and inspect it as follows:

curl -sSLfO "https://releases.cloudtaser.io/${COMPONENT}/${VERSION}/sbom.spdx.json"

# Quick inventory
jq '.packages | map({name, versionInfo}) | .[]' sbom.spdx.json | head -40

# Or feed into Grype / Trivy for vulnerability scanning
grype sbom:sbom.spdx.json
trivy sbom sbom.spdx.json

Check the individual Codeberg release under cloudtaser/<component> for assets; do not assume every release has an SBOM or that an available SBOM is verified.

---

Admission-policy enforcement

You can enforce signature verification at admission time in your cluster, so that an unsigned image (or an image tag swap, or a rollback to a non-signed digest) is rejected before the pod schedules. The cloudtaser Helm chart ships this as an opt-in:

# values.yaml
admission:
  enforceSignature: true
  mode: kyverno          # or "vap", or "both"
  signature:
    publicKey: ""        # inline PEM for air-gapped; default is publicKeyURL
    publicKeyURL: "https://releases.cloudtaser.io/keys/release.pub"
    rekorURL: "https://rekor.sigstore.dev"
    ignoreTlog: true      # release images use --tlog-upload=false; key signature only
    additionalImageReferences: []
      # - "europe-west4-docker.pkg.dev/customer-project/*"

ignoreTlog: true is an explicit override for the current no-tlog signatures; the chart default is still false and needs review in the next chart. This optional Kyverno verification path was not exercised in the live EU Port test.

See Helm Values Reference for the full admission options. The default is enforceSignature: false during Preview; once the trust root is broadly published, the default flips in a subsequent minor. If you want strict behaviour today, set it to true now and add your own signed images under additionalImageReferences to extend the same trust root to your internal registry.

Engine selection:

• kyverno (recommended) uses Kyverno's native verifyImages rule; requires Kyverno ≥ 1.11 installed in the cluster.
• vap renders a Kubernetes 1.30+ ValidatingAdmissionPolicy that enforces digest-pinned images (@sha256:...) without requiring an external controller. It cannot verify signatures by itself (VAP has no egress) but it closes the tag-swap / latest-rollback gap.
• both renders both, for defence-in-depth or during a Kyverno install/uninstall migration.

Metrics you can scrape: cloudtaser_admission_signature_enforced (gauge) and cloudtaser_admission_signature_rejections_total (counter).

---

What's on the roadmap

• Reproducible builds: verify that a given Git SHA produces a byte-identical image locally and in CI. Currently partial (Go binaries are reproducible with -trimpath -buildvcs=false -ldflags="-buildid="; container layer ordering is not fully pinned). Tracker: cloudtaser-pipeline# (filed in the same PR as this page -- see release notes).
• Third-party penetration test: targeted Q2 2026; results publishable in a redacted executive summary. See Preview Status & Roadmap.
• SLSA level 3 aspiration: signed provenance attestation attached to every image (beyond the basic Cosign signature). Depends on build-environment isolation work currently underway in the pipeline repo.
• Rekor-only verification flows for customers who cannot tolerate fetching release.pub at admission time: we document the Rekor UUIDs per release so you can verify against the transparency log without holding a local copy of the public key.

---

Acknowledging the trust shift

Using cloudtaser IS a trust shift. You go from:

• Before: trusting the US cloud provider + their key-management service + their Vault Enterprise build pipeline + their signing root.
• After: trusting cloudtaser's codebase + your chosen EU substrate (OpenBao + provider) + cloudtaser's build pipeline + cloudtaser's signing root.

The shift is the value proposition -- we are moving secret material out of the compelled surface into a jurisdictionally and architecturally distinct surface. But it is not an elimination of trust; it is a relocation of it. This page exists to give you the cryptographic handle to audit the cloudtaser side of that shift with pinned-key signatures and digest checks. SBOM availability and transparency-log inclusion require separate release evidence, as described above.

If you need evidence beyond what's documented here -- a pentest report, a SOC 2 letter, a penetration-test attestation, a specific build-provenance format -- reach out. Those items are on the roadmap; several are available under NDA today.

---

Related pages

• Security Model -- threat model and defence layers
• Shared Responsibility -- what you still own after the trust shift
• Preview Status & Roadmap -- current honest-state of audit and pentest milestones
• Helm Values Reference -- admission.enforceSignature and related options
• Operational Readiness -- blast radius, backout, SLA posture

Per-component SBOM declarations

Component	SBOM in published release pipeline
beacon	SPDX artifact declared; verify the release checksum and signature
cli	No SPDX artifact declared; do not infer availability
db-proxy	SPDX artifact declared; verify the release checksum and signature
ebpf	No SPDX artifact declared; do not infer availability
operator	SPDX artifact declared; verify the release checksum and signature
port	SPDX artifact declared; verify the release checksum and signature
s3-proxy	SPDX artifact declared; verify the release checksum and signature
wrapper	SPDX artifact declared; verify the release checksum and signature

This table is inferred from each published release pipeline, not a live artifact readback. Signing steps read key material from filesystem paths; whether a specific mount is memory-backed requires runtime mount evidence. File delivery is not an environment-only or never-on-disk guarantee.