Day 2(11月19日) 16:30 - 17:00 C(Boardroom)
公募
Security 中級者
そのイメージ、どのCIが作った?Artifact Attestationsで来歴を固定する
そのイメージは本当に共通の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を一箇所だけやめた判断を、その根拠ごとお話しします。