そのイメージは本当に共通のCIで作られたのでしょうか。GitHub Artifact Attestationsで証明できます。ただし解説の多くはcosignと公開ログが前提で、privateリポジトリでは署名基盤が変わります。署名はGitHub運用のSigstoreインスタンスが行い、Rekorを通りません。失うのは第三者による監査で、個々の検証は成立します。
AWSアカウントを分けた4環境のKubernetes基盤に、この前提で来歴検証を実装します。ビルドを共通Reusable Workflowへ寄せると、実行元を示すjob_workflow_refがその一本に固定されます。署名証明書とIAM信頼ポリシーの両方がこの値を参照するため、共通CIを通らないビルドはレジストリへpushできません。統制の本体は権限設計で、署名はその裏づけです。
CIの統制と成果物の来歴証明を設計する方に、IAM条件の書き方、ビルド時・環境昇格時・Pod起動時の三段検証、SHA pinを一箇所だけやめた判断を、その根拠ごとお話しします。
株式会社ログラス
SRE
株式会社ログラスのクラウド基盤チームに所属。
SREやKubernetesの経験を活かし、現在はマルチプロダクト向けのプラットフォーム開発を推進しています。