Packer v1.16.0 boosts machine image security with SLSA provenance attestations, ensuring integrity through detailed cryptographic build records.
With the announcement of Packer v1.16.0, there's a significant enhancement in the tool's ability to ensure the integrity of machine images. This release introduces support for generating, signing, and verifying evidence of the origins of images built with Packer, known as SLSA provenance attestations. Considering that machine images are the backbone of various workloads, ensuring they haven't been compromised becomes paramount. Previously, troubleshooting issues related to these images involved sifting through potentially lost build logs. Now, Packer provides a cryptographic record of every build, adding an essential layer of security without necessitating additional provenance tooling.
This version also comes with several enhancements in HCL2, simplifying the process of creating templates.
In this overview, we'll explore the new provenance post-processor, the packer verify-attestation command, SLSA build levels, and some smaller updates aimed at improving usability.
The Importance of Provenance for Machine Images
The SLSA framework (Supply-chain Levels for Software Artifacts) sets a structured approach to validate how software artifacts are created. While application packages and containers have been the primary focus of SLSA tools, machine images have seen far less scrutiny in supply-chain security processes.
So, what exactly does provenance attestation entail? It is a signed, machine-readable statement detailing the origin of an artifact. This includes capturing the Git commit the build originated from, the repository it came from, the CI pipeline that initiated it, and the crucial timestamps of these events. For artifacts generated locally, attestation binds to the SHA-256 digest of the artifact file. In cases where artifacts are cloud-based and lack local files, Packer uses identities derived from a canonical identity record, which includes a builder ID and artifact ID. When applicable, it may also include the registry state of the artifact.
All attestations created by Packer are formatted as in-toto statements with an SLSA Provenance v1 predicate, making them compatible with existing supply-chain security verification tools.
Introducing the Provenance Post-Processor
Incorporating provenance into your builds is straightforward with just a few lines of HCL:
build {
source "amazon-ebs" "my-image" { ... }
post-processor "provenance" {
signing_mode = "keyless"
upload_tlog = true
keyless_identity = var.keyless_identity
keyless_oidc_issuer = var.keyless_oidc_issuer
output_dir = "attestations/"
}
}
Following a successful build, Packer generates a signed attestation envelope and saves it as a plain JSON file in the attestations/ directory. This record can subsequently be stored in locations such as S3, a container registry, or alongside the respective artifact itself. For local artifacts, the attestation includes the artifact's name and its SHA-256 digest; for cloud artifacts, it logs the canonical artifact identity digest alongside other metadata.
Multiple Signing Options
To accommodate varying team setups, Packer offers four signing modes for provenance, ensuring that adopting this feature doesn't require a complete overhaul of existing key management practices:
| Mode | How Signing Works | Best For |
| none | Unsigned JSON statement | Getting started; storing in a trusted internal system |
| key | Local PEM private key | Air-gapped environments; teams with an existing PKI |
| kms | Cloud KMS or HashiCorp Vault | Production workloads with centralized key management |
| keyless | Sigstore Fulcio with optional Rekor | GitHub Actions and CI pipelines with no long-lived key |
For the kms mode, the signing provider is auto-selected based on the URI, be it AWS KMS, GCP Cloud KMS, Azure Key Vault, or HashiCorp Vault.
Understanding SLSA Build Levels
SLSA's structured approach involves defining levels of trust rather than a binary pass or fail. Here's how Packer aligns with these levels:
Build L1: Signed provenance exists - Adding the provenance post-processor will create a record identifying the artifact via its digest and detailing its production process. At this level, signing is optional: signing_mode = “none” results in an unsigned JSON statement.
Build L2: A hosted service generates and signs the provenance - This involves running Packer on platforms like GitHub Actions, using the keyless mode, where the CI job's OIDC identity serves as the signer, eliminating the need for static credentials. The attestation can then be uploaded to the Rekor log for auditable transparency.
Build L3-compatible: Provenance generation is separate from the build - Here, the build job only publishes the artifact digest, and a distinct signing job handles attestation duties in isolation from the building processes. This setup ensures greater security against tampering.
Validating Attestations with packer verify-attestation
Attestations aren't much good if they're not verified prior to an image's deployment. The new packer verify-attestation command is tailored for integration into deployment pipelines or pre-flight checks:
packer verify-attestation \
-signing-mode keyless \
-keyless-oidc-issuer https://token.actions.githubusercontent.com\
-keyless-identity https://github.com/my-org/my-repo/.github/workflows/build.yml@refs/heads/main\
-builder-id https://github.com/my-org/my-repo\
-source-uri git+https://github.com/my-org/my-repo \
-require-rekor \
-require-timestamp \
-bundle attestations/my-image.qcow2.provenance.sigstore.json \
-artifact my-image.qcow2 \
attestations/my-image.qcow2.provenance.json
If any checks fail, the command will prevent the deployment, providing a safety net against using unverified images. You can tailor verification intensity according to your needs—at the very least, check the signing identity and artifact digest.
This enhances a range of practices: deploying gated images only from trusted pipelines, investigating incidents when vulnerabilities arise, supporting compliance audits, and verifying that trusted images originate from approved builds.
Additional Enhancements in v1.16.0
Provisioner Error Management
A new feature, continue_on_error, allows for marking a provisioner as non-fatal, enabling builds to proceed even if certain steps fail. This is particularly beneficial for optional scripts, diagnostics, or telemetry that should not impede the delivery of the image.
provisioner "shell" {
inline = ["run-diagnostics.sh"]
continue_on_error = true
}
Provisioners without this flag maintain their default behavior.
Optional Fields in Object Variables
Packer now allows the use of the optional() modifier for object-type variables, enabling more flexibility in shared variable schemes without requiring every user to update their code.
variable "image_config" {
type = object({
name = string
region = optional(string, "us-east-1")
encrypt = optional(bool, true)
})
}
New Timestamp Functions
New timestamp functions, such as rfc3339_parse() and unix_timestamp_parse(), facilitate parsing timestamps for image names and tags, cutting the need for external shell scripts.
How to Get Started
Consider this: Packer now delivers signed, verifiable build records through the provenance post-processor.
Pursue confidence knowing your image supply chain is both auditable and defensible.
To leverage these capabilities, upgrade to v1.16.0 and integrate the provenance post-processor into your next build. Existing templates remain intact, so no changes are needed to keep things running smoothly.
Here are some essential resources to assist you:
Discussion
Sign in to join the discussion.