HashiCorpはPacker v1.16.0をリリースした。これにより、Packerが構築するすべてのイメージに対して、SLSAProvenanceアテステーションの生成、署名、検証をネイティブにサポートする。今回のリリースは、マシンイメージがどのように作成されたかを示す、安全で改ざん耐性のある記録をチームに提供する。追加のサプライチェーンツールを必要とせずに実現できる点も特徴だ。これは、これまでSLSAスタイルのアテステーションでほとんど見過ごされてきたインフラ領域のギャップに対応するものとなる。
このリリースが対象とする課題は明確でありながら重要だ。マシンイメージは、その上で稼働するあらゆるワークロードの基盤となる。イメージが改ざんされたり、正当性を検証できなかったりすると、その問題はそのイメージから作成されるすべてのインスタンスへと静かに気付かれないまま広がる可能性がある。今回のリリース以前は、イメージの出所を特定するために古いビルドログをたどる必要があった。Packerには、特定の成果物がどのコミット、パイプライン、あるいは実行主体（identity）によって作成されたのかを示す仕組みがなかった。
主な追加機能は、新しいprovenanceポストプロセッサだ。この機能は、SLSA Provenance v1プレディケートを含むin-totoステートメントを生成する。このフォーマットはベンダーに依存せず、既存のサプライチェーンセキュリティツールと互換性がある。アテステーションには、Gitコミット、リポジトリ、参照先（ref）、ビルドをトリガーしたCIパイプライン、ビルド日時などの情報が記録される。ローカル成果物はSHA-256ダイジェストに紐付けられ、ローカルファイルを持たないクラウド成果物については、ビルダーIDや成果物IDを含む正規の識別レコードに関連付けられる。Packerは、さまざまな鍵管理要件に対応する4種類の署名モードを提供する。内部利用向けの署名なしJSON出力に加え、分離環境向けのローカルPEM鍵を利用できる。また、集中管理された鍵管理にはクラウドKMSやVaultを使用できる。さらに、Sigstore Fulcioによるキーレス署名にも対応しており、CIパイプライン内で署名し、透明性確保のためにRekorへアップロードも可能だ。
Packerは、SLSAが定義するビルド保証レベルの階層に、自身の出力を直接対応付けている。L1の達成にはprovenanceポストプロセッサを使用するだけで十分で、署名は必須ではない。L2は、PackerをCIプラットフォーム上で実行し、キーレス署名を利用することで実現できる。この場合、CIジョブのOIDCアイデンティティが署名者として機能する。さらに、Rekorへのアップロードによって監査可能な透明性ログを提供する。HashiCorpは、この構成向けのGitHub Actionsリファレンスワークフローも公開している。L3互換のパターンでは、Provenance生成をビルドジョブから完全に分離し、slsa-framework/slsa-github-generatorを利用した別の署名ジョブを使用する。ただし、HashiCorpは、このワークフローだけで完全なL3準拠が保証されるわけではないと説明している。L3への準拠は、プラットフォームのハードニングやビルド環境の分離といった追加の管理策にも依存するためだ。このワークフローはそうしたベストプラクティスを示すものではあるが、それ自体が準拠を保証するものではない。
HashiCorpは、このコマンドをデプロイ可否の判定や、CVEを関連するコミットや稼働中インスタンスにひも付ける用途に活用することを想定している。また、SOC 2やFedRAMPの監査においては、証明そのものではなく、補助的な証跡として利用できる。
このリリースには、HCL2に関する比較的小規模な改善も含まれている。致命的ではないプロビジョナーで処理を継続できるcontinue_on_errorメタ引数が追加された。また、オブジェクト型変数における属性ごとのデフォルト値設定でoptional()をサポートする。さらに、タイムスタンプの処理向けに、新たなテンプレート関数 rfc3339_parse()とunix_timestamp_parse()が追加された。
新機能はいずれもオプトイン方式で提供されるため、既存のPackerテンプレートはv1.16.0へのアップグレードに際して変更する必要はない。Provenance機能を利用したいチームは、既存のビルドブロックにprovenanceポストプロセッサを追加するだけでよい。L2またはL3互換の運用パターンを採用する場合は、あわせてGitHub Actionsのリファレンスワークフローを組み込む必要がある。これらのワークフローは、HashiCorpがPackerリポジトリ内のexamples/ciディレクトリで提供している。
Packerのアプローチは、コンテナ領域で実績のある手法をマシンイメージにも適用するものだ。具体的には、in-totoステートメント、SLSA Provenanceプレディケート、Sigstoreによるキーレス署名、そしてRekorの透明性ログを活用している。これらの要素はこれまでマシンイメージのレイヤーでは十分に利用されていなかったが、今回のリリースによって実質的に取り込まれた形となる。Packerは、AMI、QCOW2、VHDといった成果物向けのサプライチェーンセキュリティ機能を強化する一方で、新たな暗号技術を導入するわけではない。むしろ、DockerのbuildxやGitHubのartifact attestationsで利用されている仕組みを、マシンイメージでも容易に利用できるようにしたものだ。署名と検証の厳格なプロセス自体は従来と同じであり、チームは独自に複雑なパイプラインを構築する必要がなくなる。
この違いは、特にAWSが提供する既存の機能と比較した場合に重要になる。AWSのAMI Watermarksは、イメージの識別情報や系譜メタデータを追跡する機能を提供するが、ビルドの来歴を暗号学的に保証するものではない。一方、NitroTPMベースのアテステーションは、実行中のインスタンスが起動時に基準となる測定値と一致していることを証明するが、そのイメージがどのように、どこで構築されたのかまでは示さない。AMIのガバナンスにAWSネイティブのツールを利用しているチームは、PackerのProvenanceアテステーションを追加することを検討する価値がある。両者は異なる目的を持つため、相互に代替できるものではない。SLSAによるビルドレベルの保証と、起動時の整合性検証は、それぞれデプロイメントプロセスの異なる重要な側面を担う。FedRAMPやSOC 2の監査証跡を整備しようとする組織では、両方の仕組みが必要になる可能性が高い。