Skip to content
kix /docs
Install the CLI

How-to guide Policy, CI, and compliance

Attest a deployment from its cluster receipt

Generate SLSA provenance for the version of a Kix cluster that is currently deployed.

Use --from-cluster when the attestation must describe what Kix deployed, rather than a fresh evaluation of the repository. Kix reads the receipt from the active Activation and turns it into an in-toto Statement with a SLSA v1 provenance predicate.

This guide assumes Kix has deployed the cluster at least once and your current Kubernetes context can read its Activation resources.

Generate the attestation

Section titled “Generate the attestation”

Pass the same cluster name used for deployment:

kix-examples/ output excerpt live capture 
❱ kix compliance attest how-to-application --from-cluster --builder-id https://ci.example/runs/1842 --invocation-id 1842
Show outputHide output · 48 lines 
{
  "_type": "https://in-toto.io/Statement/v1",
  "predicateType": "https://slsa.dev/provenance/v1",
  "subject": [
    {
      "digest": {
        "nixStoreHash": "gb5d6ry45b5ll664ahagxldh9na9z3y5"
      },
      "name": "cluster-how-to-application-activation"
    }
  ],
  "predicate": {
    "buildDefinition": {
      "buildType": "https://kix.run/build/v1",
      "externalParameters": {
        "cluster": "how-to-application",
        "flakeLock": "blake3:8ef54ccce598d282f28fc5a8d2cd4d49842c921b810bdc93ce635335f1fc2836",
        "flakeRef": "kix-examples"
      },
      "resolvedDependencies": [
        {
          "digest": {
            "gitCommit": "7cf72d978629469c4bd4206b95c402514c1f6000",
            "narHash": "sha256-SPm9ck7jh3Un9nwPuMGbRU04UroFmOHjLP56T10MOeM="
          },
          "uri": "flake-input:crane"
        },
        {
          "digest": {
            "gitCommit": "9dcf5b3e33b728ef3fc76a693e4feda2921b1913",
            "narHash": "sha256-aXiQ4IWL2o/X4k1ZMLapbHKxLdaYDNyBi6qvaigDXLo="
          },
          "uri": "flake-input:kixpkgs"
        }
      ]
    },
    "runDetails": {
      "builder": {
        "id": "https://ci.example/runs/1842"
      },
      "metadata": {
        "finishedOn": "2026-09-28T07:55:30Z",
        "invocationId": "1842",
        "startedOn": "2026-09-28T07:55:30Z"
      }
    }
  }
}

--builder-id should identify the system producing the attestation. In CI, a workflow run URL is a useful value. --invocation-id identifies the specific run. Both flags are optional.

The output excerpt shows the statement type, subject, build parameters, and run details. The full statement also contains the source revision, locked flake inputs, and image references recorded at deploy time.

Write it to a file

Section titled “Write it to a file”

Redirect stdout when the statement will be stored or signed by another tool:

❱ kix compliance attest how-to-application --from-cluster --builder-id "$CI_RUN_URL" --invocation-id "$CI_RUN_ID" > provenance.json

Kix writes an unsigned JSON statement. Signing and publishing can be handled by the attestation system used by your CI environment.

Check the statement

Section titled “Check the statement”

Confirm that the subject names the deployed cluster and has an activation digest:

❱ jq -e '.predicate.buildDefinition.externalParameters.cluster == "how-to-application" and (.subject[0].digest.nixStoreHash | length) > 0' provenance.json

If Kix reports that no receipt exists, deploy the cluster again with a Kix version that writes receipts. If it cannot find an Activation CRD, confirm the Kubernetes context and cluster name before retrying.