DEV Community

Leo
Leo

Posted on • Originally published at cicd.deployment.to

Packer 1.16 ships signed SLSA provenance, and a command to check it

#packer #slsa #provenance #supplychain

Your golden AMI is a stranger you agreed to boot as root a thousand times a day. (Nobody puts that on the slide.) Which is why the interesting part of Packer v1.16.0, announced by HashiCorp on August 13, is not the signing. It is the verify command.

The release adds native SLSA provenance generation, signing, and verification for the machine images Packer produces. Attestations are emitted as in-toto statements carrying an SLSA Provenance v1 predicate, capturing the Git commit, repository, ref, CI pipeline, and build timestamps. Local artifacts get bound to their SHA-256 digest; cloud artifacts get bound to a canonical identity record from the cloud they land in.

What actually ships in the attestation

The provenance is real SLSA, not a "we hashed something" file with a logo on it. The in-toto envelope carries the predicate; the subject is your image. For a local build that means the artifact digest is sha256:<digest>. For AMIs, GCE images, and the rest of the cloud family, the subject is derived from whatever canonical identity record the target platform hands back. So the attestation follows the image out of the builder into wherever it lives.

Packer offers four signing modes, and the trade-offs will feel familiar if you have ever run Sigstore:

  • none: unsigned JSON. Useful for diffing. Trust nothing.
  • key: local PEM. Fast, and only as good as the machine that holds the key.
  • kms: cloud KMS or Vault. Real key custody. Real audit trail.
  • keyless: Sigstore Fulcio, with optional Rekor transparency log. Short-lived certs from your workload identity, no long-lived key to lose.

The release also flags three SLSA build levels: L1 for "signed provenance exists," L2 when a hosted service does the generation and signing, and L3-compatible when provenance generation is isolated from the build itself. L3-compatible is not L3. Read that twice before you put it in a compliance deck.

The command the ecosystem was missing

Signing is easy. Verification is where projects quietly ship a TODO and move on. Packer 1.16 adds packer verify-attestation, aimed at deployment pipelines and pre-flight scripts, with the flags a paranoid CI job actually needs:

packer verify-attestation \
  -signing-mode=keyless \
  -keyless-oidc-issuer=$OIDC_ISSUER \
  -keyless-identity=$WORKLOAD_IDENTITY \
  -builder-id=$BUILDER_ID \
  -source-uri=$SOURCE_REPO \
  -require-rekor \
  -require-timestamp \
  -artifact=sha256:<digest>
Enter fullscreen mode Exit fullscreen mode

Note -require-rekor and -require-timestamp. Those are the two flags that turn a signature check into an actual policy: a Rekor entry means the signature is publicly logged, and a required timestamp closes the "what if the key was compromised last Tuesday" gap. Without them, verify-attestation becomes a very expensive way to prove that math works.

The HCL2 quality-of-life patch nobody will tweet about

Buried under the provenance news, three HCL2 changes that will land in real templates:

  • continue_on_error = true on a provisioner marks it non-fatal. Finally, a first-class way to run the "nice to have" cleanup step without failing the whole build.
  • optional() lets you set per-attribute defaults inside an object-type variable, instead of dumping the whole object at the caller.
  • rfc3339_parse() and unix_timestamp_parse() give you structured timestamp math without shelling out.

Small, boring, and the kind of thing every Packer author has hand-rolled at least once.

What you should watch

Two things. First: an attestation only means what the verifier says it means. If your deploy pipeline pulls the AMI and skips verify-attestation, you have generated a very well-designed log file. Wire the check in before the image is promoted, not after.

Second: keyless signing is delightful right up until your workload identity issuer changes and every historic attestation now points at an OIDC subject nobody recognizes. Pin -keyless-identity and -builder-id to the values your CI actually uses today, and treat rotating them as a policy event, not a config tweak.

The rest of the ecosystem has been converging on the same primitives: SLSA Provenance v1, in-toto envelopes, Sigstore for keyless signing, Rekor for transparency. Packer joining that stack with a first-party verify command is the part that matters. Provenance you can generate is table stakes. Provenance you can, and do, check is where the trust boundary actually moves.

Signed. Timestamped. Rekor-logged. Now check it.

Top comments (0)