はじめに
近年、ソフトウェアサプライチェーン攻撃（SolarWinds事件、Codecov事件など）が増加し、「コンテナイメージが本当に信頼できるパイプラインで作られたものか」を検証することが、エンタープライズシステム運用において重要な課題となっています。
私自身、製造業・SCM領域の基幹システム開発において、Google Cloud をはじめとするクラウド基盤の導入・運用を支援してきた経験を踏まえ、今回は Google Cloud の Binary Authorization について、その仕組みと実際のハンズオン手順を整理してみたいと思います。
なお、Google Cloud を活用したシステム開発については、Udemy にて関連コースをリリースしておりますので、ご興味のある方はご覧ください。
1. Binary Authorization とは
Binary Authorization は、Google Cloud が提供する 「コンテナイメージのデプロイ時セキュリティ制御サービス」 です。Cloud Run、GKE、Anthos などへのデプロイ前に、「そのコンテナイメージが信頼できるソースから来たものか」をポリシーに基づいて検証し、不正なイメージのデプロイをブロックする仕組みを提供します。
主な目的は以下の通りです。
- サプライチェーンの完全性確保：承認されていない（=社内のCIパイプラインを通っていない）イメージのデプロイを防止する。
- ガバナンスの強化：本番環境にデプロイされるイメージを、ポリシーで一元的に管理する。
- 来歴（Provenance）の検証：イメージが「いつ・誰が・どのビルダーで」作成されたかを暗号学的に検証する。
仕組みとしては、信頼できるビルドシステム（例：Cloud Build）が、ビルド完了時にイメージに対して Attestation（証明書） を付与します。デプロイ時に Binary Authorization はこの Attestation の存在と署名を検証し、ポリシーに合致しなければデプロイをブロックします。
人間のオペレーションミスや悪意あるイメージ差し替えをシステム的に防止できる点が、Binary Authorization のメリットです。
2. ハンズオン：Cloud Build + Binary Authorization
ここからは、実際に Cloud Build でビルドしたイメージを、Binary Authorization のポリシー制御下で Cloud Run にデプロイする流れを示します。
2-1. 事前準備（初回のみ）
リージョンとプロジェクトIDを変数化し、必要なAPIを有効化します（東京リージョンを想定しています）。
REGION=asia-northeast1
PROJECT_ID=$(gcloud config get-value project)
gcloud services enable \
cloudbuild.googleapis.com \
artifactregistry.googleapis.com \
run.googleapis.com \
binaryauthorization.googleapis.com \
clouddeploy.googleapis.com
2-2. Artifact Registry リポジトリの作成
ビルドしたコンテナイメージの格納先となる Artifact Registry を作成します。
gcloud artifacts repositories create app-repo \
--repository-format=docker \
--location=$REGION
2-3. サンプルアプリの作成（依存なし・Cloud Run 対応）
検証用に、Python 標準ライブラリのみで動作する最小限の HTTP サーバを用意します。CAT コマンドで直接 CloudShell 上に作成します。
mkdir -p ~/cicd-lab && cd ~/cicd-lab
cat > ~/cicd-lab/main.py <<'EOF'
import os
from http.server import BaseHTTPRequestHandler, HTTPServer
class H(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(200)
self.send_header("Content-Type", "text/plain; charset=utf-8")
self.end_headers()
self.wfile.write(b"Hello from the CI/CD lab!\n")
HTTPServer(("", int(os.environ.get("PORT", "8080"))), H).serve_forever()
EOF
cat > ~/cicd-lab/Dockerfile <<'EOF'
FROM python:3.12-slim
WORKDIR /app
COPY main.py .
CMD ["python", "main.py"]
EOF
2-4. Cloud Build によるビルド
イメージ名を変数化し、--tag オプションでビルドからプッシュまでを一括実行します。
IMAGE=$REGION-docker.pkg.dev/$PROJECT_ID/app-repo/hello
cd ~/cicd-lab
gcloud builds submit --tag $IMAGE:v1 .
# 格納されたイメージを確認
gcloud artifacts docker images list $REGION-docker.pkg.dev/$PROJECT_ID/app-repo
2-5. cloudbuild.yaml によるビルドのパラメータ化
実運用では、ビルド構成を cloudbuild.yaml に切り出し、変数（substitutions）で制御するのが一般的です。
cat > ~/cicd-lab/cloudbuild.yaml <<'EOF'
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', '${_IMAGE}:${_TAG}', '.']
images:
- '${_IMAGE}:${_TAG}'
substitutions:
_IMAGE: 'IMAGE_PLACEHOLDER'
_TAG: 'v2'
options:
logging: CLOUD_LOGGING_ONLY
EOF
# _IMAGE 変数を実値で上書きして実行
gcloud builds submit --config cloudbuild.yaml \
--substitutions=_IMAGE=$IMAGE,_TAG=v2 .
# 履歴の確認
gcloud builds list --limit=5
2-6. ビルド来歴（Provenance）の確認
Cloud Build は、ビルドしたイメージに対して自動的に来歴情報を生成します。これが Binary Authorization の検証材料となります。
DIGEST=$(gcloud artifacts docker images describe $IMAGE:v1 \
--format="value(image_summary.digest)")
gcloud artifacts docker images describe $IMAGE@$DIGEST \
--show-provenance --format=json
2-7. Binary Authorization ポリシーの設定
現在のポリシーをエクスポートしたうえで、「Cloud Build によって作成されたイメージ（built-by-cloud-build Attestor による証明があるもの）のみデプロイを許可する」ポリシーを定義します。
gcloud container binauthz policy export > /tmp/policy.yaml
cat << EOF > /tmp/policy.yaml
defaultAdmissionRule:
evaluationMode: REQUIRE_ATTESTATION
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
requireAttestationsBy:
- projects/PROJECT_ID/attestors/built-by-cloud-build
name: projects/PROJECT_ID/policy
EOF
# PROJECT_ID を自身の環境に合わせて置換し、ポリシーを適用
sed -i "s/PROJECT_ID/$PROJECT_ID/g" /tmp/policy.yaml
gcloud container binauthz policy import /tmp/policy.yaml
各設定項目の意味は以下の通りです。
-
evaluationMode: REQUIRE_ATTESTATION：Attestation の存在を必須とする。 -
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG：違反イメージのデプロイをブロックし、監査ログを残す。 -
requireAttestationsBy：信頼する Attestor（証明者）を指定。built-by-cloud-buildは Google が提供するマネージドな Attestor で、Cloud Build 由来であることを保証する。
2-8. Cloud Run へのデプロイ（成功確認）
Cloud Build で作成したイメージは built-by-cloud-build の Attestation を持つため、ポリシーをパスしてデプロイが成功します。
gcloud run deploy binauthz-demo \
--image=$IMAGE:v1 \
--region=$REGION \
--binary-authorization=default \
--allow-unauthenticated
--binary-authorization=default を指定することで、デプロイ時に Binary Authorization のポリシー検証が有効になります。逆に、ローカル PC で docker build したような Attestation を持たないイメージをデプロイしようとすると、この段階でブロックされます。
3. おわりに
Binary Authorization は、単なる「セキュリティ機能」というより、 「ソフトウェアサプライチェーンに対するガバナンスをコード化するための仕組み」 と捉えるのが本質的だと考えています。
特に、法人向けの基幹システムやミッションクリティカルなシステムにおいては、「誰が・いつ・どのパイプラインで作ったイメージが本番環境にデプロイされたのか」を説明できることが極めて重要です。Binary Authorization は、この説明責任（アカウンタビリティ）をシステム的に担保するための強力な武器となります。
Cloud Build と組み合わせれば、ほぼ追加の設定なしで「承認済みパイプライン経由のイメージのみデプロイ可能」という状態を構築できますので、Google Cloud で本番システムを運用される方は、ぜひ一度検証されることをお勧めします。
プロフィール
[Maruchin Tech]
AWS、Google Cloud、製造業・SCM DXを専門とするUdemy講師・技術顧問。
新卒で日産自動車に入社。その後アクセンチュア、NTTデータを経て独立。
大手製造業の基幹システム刷新やDXプロジェクトにおいて、要件定義からアーキテクチャ設計までをリード。
現在は「現場で本当に使える技術と視点」をテーマに、エンジニア教育に従事。