Binary Authorization

解決する課題

「どこの誰が作ったか分からないコンテナイメージ」が本番に流れ込むのを防ぎたい、というのが核心です。コンテナは中身が見えにくく、レジストリに push されたものは何でもデプロイできてしまうため、改ざんや未検査のイメージが本番へ届くリスクがあります。

• 検査やビルドのパイプラインを通っていない素性不明のイメージのデプロイを止めたい
• 開発者が手元でビルドした野良イメージが本番クラスタに入るのを防ぎたい
• 「特定の CI でビルドされ、脆弱性スキャンに合格したものだけ」というデプロイの前提条件を技術的に強制したい
• サプライチェーン攻撃に備え、デプロイ時点（admission）での検証という最後の関門を設けたい

主要概念と用語

• ポリシー（Policy）: どのイメージのデプロイを許可するかを定義するプロジェクト単位のルール。デフォルトルールとクラスタ固有ルールを持つ
• 証明者（Attestor）: 構成証明（後述）の署名を検証する主体。検証に使う公開鍵を保持し、ポリシーから参照される
• 構成証明（Attestation）: 「このイメージはこの工程を通過した」という事実への署名付きの証明書。イメージのダイジェスト（digest）に対して作成される
• 適用モード（Enforcement Mode）: 違反時にデプロイをブロックするか、**監査ログのみ記録して通過させる（dry-run）**かの設定
• 継続的検証（Continuous Validation, CV）: デプロイ後も稼働中のイメージがポリシーに適合し続けているかを定期的に検査し、逸脱をログに記録する仕組み
• イメージダイジェスト: sha256:... 形式の不変な識別子。可変なタグ（latest 等）ではなくダイジェストで対象を特定する
• Cloud KMS との連携: 構成証明の署名鍵を Cloud KMS で管理し、署名・検証に利用できる

仕様・制限・クォータ

• デプロイ時の関門（Admission Controller）として動作: イメージの実行可否を、Pod 起動やリビジョン作成の直前に判定する
• 対応プラットフォーム: GKE、GKE Enterprise、Cloud Run、および一部のサーバーレスランタイムでサポートされる。判定対象は基本的にコンテナイメージ
• ダイジェスト指定が前提: 構成証明はイメージダイジェストに対して結びつく。タグ参照のみのデプロイは検証が成立しにくいため、ダイジェスト固定が推奨される
• ホワイトリスト（許可リスト）: 特定レジストリパスのイメージをポリシー検証なしで許可する例外指定が可能。Google 提供のシステムイメージは既定で除外扱いとなる
• 適用モードは2系統: 違反をブロックする強制と、監査ログのみのドライランを使い分けられる
• クォータ: API リクエストや構成証明の作成・検証にはレート上限があり、最新の具体値は公式ドキュメントで確認する（ここでは定性的に述べるに留める）

内部の仕組み

Binary Authorization は、コンテナのデプロイ要求が来た瞬間に割り込むアドミッションコントローラとして機能します。流れはおおむね次の通りです。

• まず CI/CD パイプラインで、ビルドや脆弱性スキャンを通過したイメージのダイジェストに対して**構成証明（署名）**を作成する
• デプロイ時、Binary Authorization は対象イメージのダイジェストに紐づく構成証明を集め、ポリシーが要求する証明者の公開鍵で署名を検証する
• 必要な証明者の署名がすべて揃っていればデプロイを許可し、欠けていれば適用モードに従ってブロック（強制）または通過＋ログ記録（ドライラン）する
• デプロイ後も**継続的検証（CV）**が稼働中イメージを定期的に再評価し、ポリシー逸脱を検出して監査ログへ出力する

署名鍵は Cloud KMS と連携でき、署名する側（CI）と検証する側（証明者）で鍵の公開・秘密を分離します。これにより「誰が構成証明を作れるか」を権限として統制できます。

設計パターン / ベストプラクティス

• まずドライラン（監査のみ）で開始し、既存ワークロードがどれだけ違反するかをログで観測してから強制に切り替える
• CI/CD に構成証明の作成を組み込む。ビルド成功・脆弱性スキャン合格などの工程ごとに別々の証明者を用意し、複数署名を要求する
• 証明者の署名鍵は Cloud KMS で管理し、署名権限を CI のサービスアカウントだけに最小権限で付与する
• 例外は許可リストで明示的に最小化し、ブレークグラス（緊急時の一時迂回）は監査ログを必ず残す運用にする
• デプロイは常にダイジェスト固定とし、IaC やマニフェストにタグ参照を残さない
• 組織全体へ広げる場合は組織ポリシーと組み合わせ、プロジェクトごとの設定漏れを防ぐ

運用・監視

• 違反やブレークグラスの利用は Cloud Audit Logs に記録される。強制前にドライランのログを精査し、誤検知や正規ワークロードの取りこぼしを洗い出す
• 継続的検証（CV）のログを監視し、デプロイ後にポリシーから逸脱したイメージ（鍵失効・証明者削除など）を検知する
• デプロイがブロックされた場合は、対象イメージのダイジェストに対する構成証明の有無と、ポリシーが要求する証明者の鍵が有効かを確認する
• 証明者の鍵をローテーションする際は、旧鍵で作られた既存構成証明の検証可否を考慮し、移行期間を設ける
• ブレークグラスは恒常運用にせず、利用のたびにアラートを上げて事後レビューする

コスト

Binary Authorization 自体の利用は、付随する各サービスの費用が中心です。構成証明の保管・検証に使う Artifact Registry / Container Analysis、署名鍵を置く Cloud KMS、ログを保持する Cloud Logging などが主なコスト要素になります。

セキュリティ

• 署名鍵の秘密鍵を厳格に保護する。Cloud KMS に置き、署名できるのは CI のサービスアカウントだけ、という最小権限を徹底する
• 証明者の公開鍵が正しいものかを管理し、鍵のすり替えで偽の構成証明が通らないようにする
• ブレークグラスは抜け道になり得るため、利用を例外として扱い、必ずアラートと事後監査を伴わせる
• ポリシーの管理権限（誰がポリシーや証明者を変更できるか）を IAM で限定し、関門そのものの無効化を防ぐ
• 構成証明の作成を CI に閉じ込め、開発者が手元から任意に署名できない構成にする

Well-Architected の観点

• セキュリティ: ソフトウェアサプライチェーンの「最後の関門」として、デプロイ時にイメージの素性を強制検証する。最小権限の署名鍵管理と監査ログが要
• 信頼の起点をビルドパイプラインに置き、人手による野良デプロイを排除することで、本番環境の予測可能性と統制を高める
• 例外（許可リスト・ブレークグラス）を最小化し可視化することで、統制の抜け穴を作らない

試験で問われるポイント

関連サービス・比較

Binary Authorization は単体ではなく、ビルド・スキャン・署名・実行の各サービスと連携して機能します。AWS では単一のサービスではなく、ECR のイメージ署名と AWS Signer の組み合わせが近い役割を担います。

ハンズオン / CLI例

# 現在のポリシーをファイルに書き出す
gcloud container binauthz policy export > policy.yaml

# 編集したポリシーを適用する（YAML内で適用モードや証明者を指定）
gcloud container binauthz policy import policy.yaml

# 証明者を作成する（Container Analysis のノートに紐づける）
gcloud container binauthz attestors create build-attestor \
  --attestation-authority-note build-note \
  --attestation-authority-note-project PROJECT_ID

# 証明者に Cloud KMS の公開鍵を登録して検証に使う
gcloud container binauthz attestors public-keys add \
  --attestor build-attestor \
  --keyversion 1 \
  --keyversion-key-name build-signing-key \
  --keyversion-keyring binauthz-keyring \
  --keyversion-location asia-northeast1

# イメージのダイジェストに対して構成証明を作成（CI から実行する想定）
gcloud container binauthz attestations sign-and-create \
  --artifact-url asia-northeast1-docker.pkg.dev/PROJECT_ID/repo/myapp@sha256:DIGEST \
  --attestor build-attestor \
  --keyversion 1 \
  --keyversion-key-name build-signing-key \
  --keyversion-keyring binauthz-keyring \
  --keyversion-location asia-northeast1