SECTION 2 ★最重要

セクション 2：
CI/CD パイプライン

PCDE で 最頻出（~25%）のセクション。Cloud Build → Artifact Registry → Cloud Deploy の GCP ネイティブパイプライン、Canary / Blue-Green / Rolling / Traffic Split / Feature Flags の戦略選定、Cloud KMS / Secret Manager / Parameter / Certificate Manager / Workload Identity Federation による設定とシークレット管理、Artifact Analysis / Binary Authorization / SLSA L1-L4 / Software Delivery Shield によるサプライチェーン保護まで体系的に押さえます。

★ 最重要セクション 📊 出題 ~25% 🔐 サプライチェーン保護 📘🔧🎯 全レベル対応

出題 ~25%★ 📘 基礎 🔧 応用 🎯 要点

🔑 TL;DR — このセクションの要約 CI = Cloud Build、保管 = Artifact Registry、CD = Cloud Deploy が GCP ネイティブ三種の神器。Cloud Deploy の階層は Delivery Pipeline → Target → Release → Rollout → Phase。デプロイ戦略は 即時切戻し=Blue/Green、段階的=Canary、デフォルト=Rolling、Cloud Run=Traffic Splitting、A/B=Feature Flags。シークレットは Secret Manager（機密）/ Parameter Manager（非機密）/ Certificate Manager（TLS）/ Cloud KMS（鍵）。サプライチェーンは Artifact Analysis（CVE）→ Binary Authorization（署名検証）→ Continuous Validation（継続検証）、これらを統合するのが Software Delivery Shield。SA キーは禁止、WIF 必須。

🎯 学習目標

🏗️ CI/CD パイプライン全体像（Google Cloud 版）

2.1 パイプライン設計（Designing pipelines）

CI / CD / CD の定義

用語	正式名	意味
CI	Continuous Integration	コード変更を頻繁にマージし、自動テスト・ビルド
CD	Continuous Delivery	本番デプロイ可能な状態まで自動化（リリース判断は手動）
CD	Continuous Deployment	本番デプロイまで完全自動化

PCDE では一般に CI = Cloud Build、CD = Cloud Deploy という対応。

DORA / Four Keys（高パフォーマンス目安）

Deployment Frequency

デプロイ頻度。高パフォ目安: 1 日複数回

Lead Time for Changes

コミット → 本番。高パフォ目安: 1 時間未満

Change Failure Rate

変更失敗率。高パフォ目安: 0-15%

MTTR / Time to Restore

復旧時間。高パフォ目安: 1 時間未満

Cloud Build — cloudbuild.yaml の構造

steps: - name: 'node:20' id: 'install' entrypoint: 'npm' args: ['ci'] - name: 'node:20' id: 'test' entrypoint: 'npm' args: ['test'] waitFor: ['install'] - name: 'gcr.io/cloud-builders/docker' id: 'build' args: ['build', '-t', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/myrepo/myapp:$SHORT_SHA', '.'] waitFor: ['test'] - name: 'gcr.io/cloud-builders/docker' args: ['push', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/myrepo/myapp:$SHORT_SHA'] images: - 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/myrepo/myapp:$SHORT_SHA' options: machineType: 'E2_HIGHCPU_8' logging: CLOUD_LOGGING_ONLY timeout: '1800s'

Cloud Build 主要フィールド

フィールド	内容
`steps[]`	ビルドステップ。各ステップは Docker コンテナとして実行
`name`	使用するビルダーイメージ
`waitFor`	依存ステップ ID（`-` で並列実行）
`secretEnv`	Secret Manager から注入する環境変数
`images[]`	ビルド成果物の Docker イメージ宣言（自動 push）
`substitutions`	置換変数（ユーザー定義は `_` 始まり）
`timeout`	全体タイムアウト（デフォルト 60 分、最大 24 時間）
`options.machineType`	マシンタイプ（高速化したい時に変更）

Cloud Build トリガー種別

トリガー	条件	用途
Push to branch	特定ブランチへの push	`main` 押下で本番ビルド
Push new tag	タグ push	リリースタグでビルド
Pull request	PR 作成・更新	PR レビュー時にテスト
Manual	手動実行	緊急時
Pub/Sub	Pub/Sub メッセージ	CVE 検出→自動再ビルド
Webhook	HTTP リクエスト	外部システムから
Scheduled	Cloud Scheduler 経由	定期実行（nightly build）

Artifact Registry サポートフォーマット

Docker / OCI

Docker イメージ、OCI 互換

Maven

Java（pom.xml）

npm

Node.js

Python

PyPI 互換（pip）

Helm

Kubernetes パッケージ

Apt / Yum

Debian/Ubuntu / RHEL

Go modules

Kubeflow

Kubeflow パイプライン

+ Cleanup Policies

古いイメージ自動削除

🔧 Cloud Build vs Jenkins vs GitHub Actions 選定

シナリオ	推奨
GCP のみ / 完全マネージド希望	Cloud Build
マルチクラウド・複雑なパイプライン	Jenkins
GitHub ホスティング前提	GitHub Actions（WIF 連携）
GitLab ホスティング前提	GitLab CI
規制業界・オンプレ要件	Jenkins（自己ホスト）or Cloud Build Private Pool

🔧 Cloud Build Private Pool の必要性

🚨 重要VPC 内の Cloud SQL やプライベート GKE クラスタにビルドからアクセスするには Private Pool 必須。デフォルトプールは外部実行のため接続不可。

gcloud builds worker-pools create my-pool \ --region=asia-northeast1 \ --peered-network=projects/HOST_PROJECT/global/networks/shared-vpc \ --worker-machine-type=e2-medium # cloudbuild.yaml で使用 options: pool: name: 'projects/my-project/locations/asia-northeast1/workerPools/my-pool'

🔧 トリガー設計のパターン

ブランチ / イベント	トリガー	デプロイ先
`feature/*` push	PR トリガー	テスト実行のみ
`main` push	push トリガー	dev 環境
`release-*` push	push トリガー	staging 環境
`v*` タグ	tag トリガー	prod 環境
毎日 00:00	scheduled	regression test

🔧 PR トリガーの `comment-control`

値	内容
`COMMENTS_DISABLED`	全 PR で自動実行
`COMMENTS_ENABLED`	コラボは自動、外部は `/gcbrun` 必須
`COMMENTS_ENABLED_FOR_EXTERNAL_CONTRIBUTORS_ONLY`	外部のみコメント必須

🔧 Pub/Sub トリガーの典型例

# CVE 検出 → 自動再ビルド gcloud builds triggers create pubsub \ --name=cve-detected \ --topic=projects/my-project/topics/cve-alerts \ --build-config=cloudbuild-rebuild.yaml \ --substitutions='_IMAGE=$(body.message.data.image)'

🎯 Cloud Build 重要数値

項目	値
デフォルトタイムアウト	60 分
最大タイムアウト	24 時間
無料枠	1 日 120 ビルド分（e2-medium 相当）
デフォルトマシン	1 vCPU / 4 GB
最大マシン	`E2_HIGHCPU_32`（32 vCPU / 32 GB）
並列ステップ	`waitFor: ['-']` で並列実行
ユーザー定義置換変数	`_` から開始（例: `_ENV`）

🎯 Artifact Registry 即答

キーワード	答え
マルチフォーマット	Artifact Registry（Docker/Maven/npm/Python/Helm/Apt/Yum/Go）
タグ上書き禁止	`--immutable-tags`
外部リポジトリのキャッシュ	Remote Repository
複数リポジトリを単一エンドポイント	Virtual Repository
古いイメージ自動削除	Cleanup Policies
IAM: push 権限	`roles/artifactregistry.writer`
IAM: pull 権限	`roles/artifactregistry.reader`

2.2 パイプライン実装とデプロイ戦略

Cloud Deploy 階層（最重要）

Cloud Deploy YAML の例

apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: my-app-pipeline serialPipeline: stages: - targetId: dev profiles: [dev] - targetId: staging profiles: [staging] - targetId: prod profiles: [prod] strategy: canary: runtimeConfig: kubernetes: serviceNetworking: service: my-app-svc deployment: my-app canaryDeployment: percentages: [25, 50] verify: true --- apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod requireApproval: true # 手動承認必須 gke: cluster: projects/my-project/locations/asia-northeast1/clusters/prod

デプロイ戦略 5 種比較

瞬時切戻し、2 倍リソース Canary Stable v1 (95%) v2 (5%) 段階的 (5%→25%→100%)、verify でメトリクス検証 Traffic Split v1 (90%) v2 (10%) 重み付け切替（Cloud Run revision、GKE Gateway） Feature Flag 本番デプロイ済みコードで切替（フラグ ON/OFF）、デプロイとリリース分離 旧版（v1）新版（v2）新環境

5 戦略の比較表

戦略	動作	切戻し	リソース	用途
Rolling Update	順次置換	遅い	1 倍	デフォルト、一般 Web
Blue/Green	新環境構築 → LB 切替	瞬時	2 倍	DB 非互換、即時切戻し必須
Canary	一部に新版	影響限定	1 倍 + α	リスク高、メトリクス検証
Traffic Splitting	重み付け分配	速い	1 倍 + α	Cloud Run、GKE Gateway
Feature Flags	コードで切替	瞬時（フラグ）	1 倍	A/B テスト、段階開放

🔧 Cloud Deploy canary の詳細

strategy: canary: runtimeConfig: kubernetes: serviceNetworking: service: my-app-svc deployment: my-app disablePodOverprovisioning: false canaryDeployment: percentages: [10, 25, 50] # 段階 verify: true # 各 phase で verify predeploy: actions: [pre-check] # cloudbuild.yaml ターゲット postdeploy: actions: [post-check]

🔧 Cloud Deploy IAM の職務分掌

ロール	内容
`roles/clouddeploy.admin`	全権限
`roles/clouddeploy.operator`	パイプライン操作
`roles/clouddeploy.developer`	release 作成のみ
`roles/clouddeploy.releaser`	release 作成・promote
`roles/clouddeploy.approver`	承認のみ（releaser とは別人に）
`roles/clouddeploy.viewer`	閲覧
`roles/clouddeploy.jobRunner`	ジョブ実行用

🔑 職務分掌release を作る人と承認する人を分ける。releaser vs approver を別 IAM に。

🔧 マルチターゲット並列デプロイ

apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: multi-prod multiTarget: targetIds: - prod-asia # asia-northeast1 - prod-us # us-central1 - prod-eu # europe-west1 # → 1 つの release から 3 リージョンへ並列デプロイ

🔧 ハイブリッド / マルチクラウドデプロイ

要件	推奨
単一クラウド GKE	Cloud Deploy 直接
マルチクラスタ・即時性重視	Cloud Deploy + Multi-target
規制・宣言的・監査性重視	Config Sync（GitOps）
マルチクラウド	Cloud Deploy + Anthos
オンプレ GKE	GKE Enterprise / Anthos

🔧 ML パイプライン統合（Vertex AI Pipelines）

項目	内容
ML ワークフロー実行	Vertex AI Pipelines（KFP v2 / TFX）
CI 連携	Cloud Build トリガーで `pipelineJobs.create`
モデル保管	Vertex AI Model Registry
モデルデプロイ	Vertex AI Endpoints
モデルの canary	traffic-split（`v1=90,v2=10`）
監査	Cloud Audit Logs (`aiplatform.googleapis.com`)

# 既存エンドポイントに 10% traffic で新モデルデプロイ gcloud ai endpoints deploy-model my-endpoint \ --region=asia-northeast1 \ --model=projects/my-project/locations/asia-northeast1/models/my-model-v2 \ --traffic-split=v1=90,v2=10

🎯 Cloud Deploy 階層即答

暗記	答え
最上位リソース	Delivery Pipeline
デプロイ先環境	Target
バージョンスナップショット	Release
1 つの target への展開	Rollout
canary の段階単位	Phase
Render エンジン	Skaffold
対応マニフェスト形式	Kubernetes / Kustomize / Helm

🎯 デプロイ戦略選定

要件	戦略
即時切戻し最優先	Blue/Green
段階的・メトリクス検証	Canary
デフォルトの順次置換	Rolling Update
Cloud Run の重み付け	Traffic Splitting
デプロイとリリース分離	Feature Flags
DB スキーマ非互換	Blue/Green（マイグレ設計次第）

🎯 Cloud Deploy 対応ターゲット

ターゲット	対応
GKE Standard / Autopilot	✓
Cloud Run（service / job）	✓
GKE Enterprise / Anthos	✓
GKE on AWS / Azure	✓
App Engine	✗
Cloud Functions	✗

2.3 設定とシークレット管理

シークレット系 4 サービスの使い分け

サービス	用途	例
Cloud KMS	暗号鍵	CMEK、データ暗号化、署名
Secret Manager	機密の値	API key、DB password、秘密鍵
Parameter Manager	非機密の構成値	feature flag、しきい値、URL
Certificate Manager	TLS 証明書	Google-managed / self-managed

Cloud KMS の階層と保護レベル

Project └─ KeyRing（鍵の論理的グループ、リージョン指定） └─ CryptoKey（暗号鍵） └─ CryptoKeyVersion（バージョン、ローテーション履歴）

保護レベル	内容	FIPS
Software	ソフトウェアベース	140-2 L1
HSM	Cloud HSM	140-2 L3
External (EKM)	外部 KMS と連携	提供元依存
External-VPC	プライベート接続経由の EKM	提供元依存

Workload Identity Federation（WIF）— キーレス認証

SA キーなしで 外部 ID プロバイダから GCP リソースにアクセス。GitHub Actions、GitLab CI、AWS、Azure、OIDC 全般に対応。

# GitHub Actions の例 permissions: id-token: write # OIDC token 取得に必要 contents: read jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - id: auth uses: google-github-actions/auth@v2 with: workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/my-pool/providers/my-github' service_account: 'my-app@my-project.iam.gserviceaccount.com' - uses: google-github-actions/setup-gcloud@v2 - run: gcloud builds submit . --config=cloudbuild.yaml

Cloud Audit Logs（CI/CD 関連）

種別	内容	デフォルト	保持
Admin Activity	設定変更・IAM 変更	有効	400 日
Data Access	データ読み書き	無効（要設定）	30 日
System Event	システム自動操作	有効	400 日
Policy Denied	ポリシー違反による拒否	有効	30 日

⚠️ Binary Authorization の拒否ログBinary Auth が デプロイ拒否したとき、ログは Policy Denied に記録される。試験頻出。

🔧 Build-time vs Runtime Secret 注入

項目	Build-time	Runtime
タイミング	ビルド中	実行時
イメージ埋め込み	可能（注意）	しない
回転	再ビルド必要	即時反映
漏洩リスク	レイヤに残る可能性	アクセス制御で保護
推奨度	必要最小限	推奨
例	npm private registry token	DB password、API key

🔧 Build-time の例（Cloud Build）

steps: - name: 'gcr.io/cloud-builders/docker' entrypoint: 'bash' args: - '-c' - | docker build \ --build-arg DB_PASSWORD=$$DB_PASSWORD \ -t myapp . secretEnv: ['DB_PASSWORD'] availableSecrets: secretManager: - versionName: projects/my-project/secrets/db-password/versions/latest env: 'DB_PASSWORD' # 注意: --build-arg は ARG 経由でレイヤに残る可能性 # → multi-stage build で最終イメージから除外する

🔧 Runtime の例（Cloud Run / GKE CSI）

# Cloud Run（環境変数として注入、回転即時反映） gcloud run deploy myapp \ --image=asia-northeast1-docker.pkg.dev/my-project/myrepo/myapp:v1 \ --set-secrets=DB_PASSWORD=db-password:latest \ --region=asia-northeast1 # GKE（CSI Driver でファイルマウント） apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: app-secrets spec: provider: gcp parameters: secrets: | - resourceName: "projects/my-project/secrets/db-password/versions/latest" path: "db-password.txt"

🔧 WIF の詳細セットアップ

# 1. Workload Identity Pool 作成 gcloud iam workload-identity-pools create github-pool \ --location=global \ --display-name="GitHub Pool" # 2. OIDC Provider 追加（条件付き） gcloud iam workload-identity-pools providers create-oidc github-provider \ --workload-identity-pool=github-pool \ --location=global \ --issuer-uri="https://token.actions.githubusercontent.com" \ --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository,attribute.ref=assertion.ref" \ --attribute-condition="assertion.repository_owner == 'myorg'" # 3. SA に Workload Identity User 付与（特定リポ・特定ブランチに限定） gcloud iam service-accounts add-iam-policy-binding deploy-sa@my-project.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/myorg/myapp"

🔧 環境別 IAM ポリシーマトリクス

項目	dev	staging	prod
デプロイ承認	不要	不要	必須
Binary Authorization	dry-run	enforced	enforced + 複数 attestor
CVE 許容	LOW まで	MEDIUM まで	HIGH 以下のみ
デプロイブランチ	全	`release-*`	`main` のみ（WIF condition）
SA キー	テスト用許可	禁止	完全禁止（WIF 必須）
アクセス可能 secret	`dev-*`	`staging-*`	`prod-*`

🎯 シークレット系即答

キーワード	答え
暗号鍵管理（HSM・CMEK）	Cloud KMS
API key / DB password 保管	Secret Manager
構成パラメータ（非機密）	Parameter Manager
TLS 証明書管理	Certificate Manager
FIPS 140-2 Level 3	Cloud HSM
外部 HSM 連携	Cloud EKM
GitHub Actions から SA キーなし認証	Workload Identity Federation

🎯 Secret Manager IAM ロール

ロール	内容
`roles/secretmanager.admin`	全権限
`roles/secretmanager.secretAccessor`	アクセスのみ
`roles/secretmanager.secretVersionManager`	バージョン管理
`roles/secretmanager.viewer`	メタデータ閲覧

🎯 Cloud Audit Logs 即答

場面	ログ種別
設定変更の監査	Admin Activity
データの読み書き監査	Data Access（要有効化）
Binary Auth の拒否ログ	Policy Denied
システム自動操作	System Event

2.4 パイプラインのサプライチェーン保護

3 つの主役：Artifact Analysis / Binary Authorization / Continuous Validation

Artifact Analysis（旧 Container Analysis）

機能	内容
Vulnerability scanning	CVE 検出（自動 / On-Demand）
SBOM 生成	Software Bill of Materials（SPDX / CycloneDX）
On-Demand Scanning	CI 内で push 前に手動スキャン
Continuous Validation	デプロイ後も継続スキャン（Binary Auth 連動）

Severity（重大度）

レベル	説明
`CRITICAL`	即座に修正必須
`HIGH`	早期修正
`MEDIUM`	計画的修正
`LOW`	影響軽微
`MINIMAL`	情報のみ

Binary Authorization の用語

用語	意味
Attestor	「誰が検証するか」（PGP 公開鍵を持つ）
Attestation	「このイメージは検証済み」のメタデータ（署名）
Policy	デプロイ可否ルール（プロジェクト単位で 1 つ）
Breakglass	緊急バイパス（Pod annotation `alpha.image-policy.k8s.io/break-glass: "true"`）
Dry-run	違反でも警告のみ・デプロイ許可（`DRYRUN_AUDIT_LOG_ONLY`）

🔧 Binary Authorization Policy 例

defaultAdmissionRule: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/my-project/attestors/qa-attestor clusterAdmissionRules: asia-northeast1.prod-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/my-project/attestors/qa-attestor - projects/my-project/attestors/security-attestor - projects/my-project/attestors/prod-approver admissionWhitelistPatterns: - namePattern: gcr.io/google-containers/* - namePattern: k8s.gcr.io/* globalPolicyEvaluationMode: ENABLE # Google ベースイメージは自動許可

🔧 Attestor 作成フロー

# 1. PGP 鍵ペア生成 gpg --quick-generate-key qa-attestor@my-project.iam.gserviceaccount.com # 2. Container Analysis Note 作成 gcloud container analysis notes create qa-attestor-note --description="QA Attestor" # 3. Attestor 作成 gcloud container binauthz attestors create qa-attestor \ --attestation-authority-note=qa-attestor-note \ --attestation-authority-note-project=my-project # 4. 公開鍵を attestor に紐付け gcloud container binauthz attestors public-keys add \ --attestor=qa-attestor --pgp-public-key-file=key.pub

🔧 Cloud Build 内で Attestation 作成

steps: - name: 'gcr.io/cloud-builders/gcloud' id: 'sign-image' entrypoint: 'bash' args: - '-c' - | IMAGE_DIGEST=$(gcloud artifacts docker images describe \ asia-northeast1-docker.pkg.dev/$PROJECT_ID/myrepo/myapp:$SHORT_SHA \ --format='value(image_summary.digest)') gcloud container binauthz attestations sign-and-create \ --artifact-url="asia-northeast1-docker.pkg.dev/$PROJECT_ID/myrepo/myapp@$IMAGE_DIGEST" \ --attestor=qa-attestor \ --keyversion=projects/$PROJECT_ID/locations/global/keyRings/binauthz/cryptoKeys/qa/cryptoKeyVersions/1

🔧 Dry-run モードと Continuous Validation

💡 段階導入本番ポリシー導入前は DRYRUN_AUDIT_LOG_ONLY で違反のみ記録、デプロイは許可。本格運用後に ENFORCED_BLOCK_AND_AUDIT_LOG へ切り替え。

# Continuous Validation 有効化 gcloud container binauthz continuous-validation update --enable # → デプロイ後も定期的に policy 違反 / attestation 期限 / CVE 新規発生を検証

🎯 Binary Auth vs Artifact Analysis vs CV

サービス	役割	タイミング
Artifact Analysis	脆弱性検出（CVE / SBOM）	push 時に自動・On-Demand
Binary Authorization	デプロイ可否判定（署名検証）	デプロイ時
Continuous Validation	デプロイ後の継続検証	定期実行

🎯 Binary Authorization 対応プラットフォーム

プラットフォーム	対応
GKE Standard / Autopilot	✓
Cloud Run	✓
GKE Enterprise / Anthos	✓
App Engine	✗
Cloud Functions	✗

📜 SLSA Framework — L1 から L4 まで

Supply-chain Levels for Software Artifacts。Google 主導 → Linux Foundation。サプライチェーン成熟度の業界標準フレームワーク。

要件	L1	L2	L3	L4
ビルド自動化	✓	✓	✓	✓
provenance	あり	署名付き	改ざん不可	+ reproducible
build service	-	ホスト型	強化	強化
ephemeral / isolated	-	-	✓	✓
hermetic build	-	-	-	✓
2 人レビュー	-	-	-	✓
reproducible	-	-	-	best effort

🔑 SLSA キーワード

provenance: ビルドの来歴情報（誰が・いつ・何を）
hermetic build: 外部ネットワーク禁止・依存ローカル化
reproducible build: 同じ入力で常に同じ出力
ephemeral environment: ビルドごとに使い捨て環境

🛡️ Software Delivery Shield 全体図

サプライチェーン全体のセキュリティを統合。既存サービス（Cloud Build / Artifact Registry / Artifact Analysis / Binary Authorization / Assured OSS / GKE Security Posture）をエンドツーエンドで連携。

Assured Open Source Software（Assured OSS）

項目	内容
対象	Java / Python の主要 OSS パッケージ
検証内容	CVE スキャン、ファジング、SLSA 準拠
提供形態	Artifact Registry 経由
用途	規制業界・サプライチェーン保護必須案件

🚨 よくあるトラブル即答（症状別）

症状	主な原因	解決
Cloud Build がプライベート GKE / Cloud SQL に届かない	Private Pool 未使用	Worker Pool 作成 → `options.pool.name` 指定
Artifact Registry に push 失敗	SA に `artifactregistry.writer` 未付与	IAM 追加
デプロイ拒否（Policy Denied ログ）	Binary Auth の attestation なし	Cloud Build 内で `sign-and-create`
canary verify 失敗	smoke test / メトリクスしきい値	verify ジョブを修正
rollout PENDING_APPROVAL のまま	`clouddeploy.approver` 未付与	approver ロール追加
WIF 認証失敗	attribute-condition / principalSet ミスマッチ	OIDC claim 確認
Cloud Run secret 読めない	runtime SA に `secretmanager.secretAccessor` 未付与	IAM 追加
GKE Pod 起動失敗	secret / configmap 不在、image pull error	`kubectl describe pod`

📊 ロールバック手段

場面	手段
Cloud Deploy 経由デプロイ	`gcloud deploy targets rollback`
Cloud Run	revision の traffic 100% を旧版に
GKE Deployment	`kubectl rollout undo deployment/<name>`
Helm	`helm rollback <release> <revision>`
MIG	rolling update を逆方向（古い template）
Feature Flag	フラグ OFF（秒単位）

🎯 要点と暗記 — 一問一答

Q1. Cloud Deploy の階層を上から下まで言える？

A. Delivery Pipeline → Target → Release → Rollout → Phase。Phase ごとに predeploy / deploy / verify / postdeploy hook が走る。

Q2. 即時切戻しが最優先のデプロイ戦略は？

A. Blue/Green。新環境を完全構築 → LB 切替で瞬時。リソースは 2 倍必要。

Q3. メトリクスで段階的に検証しながら本番リリースしたい

A. Canary（Cloud Deploy の strategy.canary + verify: true）。percentages: [10, 25, 50] で段階制御。

Q4. VPC 内の Cloud SQL やプライベート GKE にビルドからアクセスしたい

A. Cloud Build Private Pool（Worker Pool）。VPC ピアリングで内部リソース接続可能。

Q5. GitHub Actions から SA キーなしで GCP にデプロイしたい

A. Workload Identity Federation。permissions.id-token: write + google-github-actions/auth@v2。attribute-condition でリポ・ブランチ限定。

Q6. デプロイ前にコンテナイメージの署名を検証したい

A. Binary Authorization。attestor + policy + attestation。本番導入前は DRYRUN_AUDIT_LOG_ONLY で段階的に。

Q7. ビルド〜デプロイのサプライチェーンを統合保護したい

A. Software Delivery Shield。Cloud Workstations / Cloud Build / Artifact Registry / Artifact Analysis / Binary Authorization / Continuous Validation / Assured OSS / GKE Security Posture を統合。

Q8. SLSA L3 を Google Cloud で達成する手段は？

A. Cloud Build Private Pool + hermetic build。ephemeral / isolated 環境 + 改ざん不可 provenance（Cloud Build 標準で署名付き）。

Q9. DB password を Cloud Run に Runtime で注入したい

A. gcloud run deploy --set-secrets=DB_PASSWORD=db-password:latest。Secret Manager に保管 → runtime SA に secretmanager.secretAccessor 付与。回転即時反映。

Q10. ML モデルの canary リリースは？

A. Vertex AI Endpoints + traffic-split。--traffic-split=v1=90,v2=10 で 10% トラフィックを新モデルに。

💡 必殺フレーズ集（試験当日用・★最重要）

状況	即答
「即時切戻し」	Blue/Green
「段階的」「メトリクスで検証」	Canary
「プライベート GKE / Cloud SQL アクセス」	Cloud Build Private Pool
「SA キーを使わずに GitHub Actions から」	WIF
「サプライチェーン業界標準」	SLSA
「Google 検証済み OSS」	Assured OSS
「外部リポジトリのキャッシュ」	Remote Repository
「複数リポジトリを単一エンドポイント」	Virtual Repository
「機密でない構成値」	Parameter Manager（Secret Manager ではない）
「TLS 証明書を Google が自動更新」	Certificate Manager（Google-managed）
「FIPS 140-2 Level 3」	Cloud HSM
「マルチリージョン並列デプロイ」	Cloud Deploy Multi-target
「GitOps」「Git が信頼源」	Config Sync
「承認者と作成者を分離」	`clouddeploy.releaser` vs `clouddeploy.approver`
「Binary Auth の拒否を確認」	Cloud Audit Logs Policy Denied
「デプロイ後も継続検証」	Continuous Validation
「hermetic build」	SLSA L3 以上
「2 人レビュー + reproducible」	SLSA L4
「ビルド〜デプロイ統合セキュリティ」	Software Delivery Shield
「コンテナ脆弱性スキャン」	Artifact Analysis
「デプロイ前のイメージ署名検証」	Binary Authorization
「古いイメージ自動削除」	Artifact Registry Cleanup Policies
「Cloud Run でモデル canary」	Vertex AI Endpoints traffic-split

🔑 5 分で復習する箇条書きまとめ

CI = Cloud Build、CD = Cloud Deploy、保管 = Artifact Registry
Cloud Deploy 階層: Delivery Pipeline → Target → Release → Rollout → Phase
Render エンジン: Skaffold（Kustomize / Helm 連携）
デプロイ戦略: 即時切戻し=Blue/Green、段階的=Canary、デフォルト=Rolling、Cloud Run=Traffic Split、A/B=Feature Flags
Artifact Registry: マルチフォーマット、--immutable-tags、Remote / Virtual / Cleanup Policies
Binary Authorization: attestor / attestation / policy / breakglass / dry-run / Continuous Validation
SLSA: L1=自動化、L2=署名付き provenance、L3=hermetic（Cloud Build 標準）、L4=2 人レビュー + reproducible
SDS: Workstations / Build / Registry / Analysis / BinAuth / CV / Assured OSS / Security Posture
Secret 注入: デフォルト Runtime、Build-time は multi-stage で最終イメージから除外
WIF: SA キー禁止、GitHub Actions は id-token: write、attribute-condition で限定
環境別 IAM: prod は 承認必須 + WIF + 複数 attestor
Cloud Audit Logs: Admin / Data Access / System Event / Policy Denied（Binary Auth 拒否）
Cloud Build Private Pool = プライベート GKE / Cloud SQL アクセスに必須
Vertex AI Endpoints は traffic-split で ML モデルの canary

🧭 次のステップ

← セクション 1：組織と基盤セクション 3：SRE プラクティス → 📝 問題演習を解く 📖 用語集

セクション 2：CI/CD パイプライン

🎯 学習目標

🏗️ CI/CD パイプライン全体像（Google Cloud 版）

2.1 パイプライン設計（Designing pipelines）

CI / CD / CD の定義

DORA / Four Keys（高パフォーマンス目安）

Deployment Frequency

Lead Time for Changes

Change Failure Rate

MTTR / Time to Restore

Cloud Build — cloudbuild.yaml の構造

Cloud Build 主要フィールド

Cloud Build トリガー種別

Artifact Registry サポートフォーマット

🔧 Cloud Build vs Jenkins vs GitHub Actions 選定

🔧 Cloud Build Private Pool の必要性

🔧 トリガー設計のパターン

🔧 PR トリガーの comment-control

🔧 Pub/Sub トリガーの典型例

🎯 Cloud Build 重要数値

🎯 Artifact Registry 即答

2.2 パイプライン実装とデプロイ戦略

Cloud Deploy 階層（最重要）

Cloud Deploy YAML の例

デプロイ戦略 5 種比較

5 戦略の比較表

🔧 Cloud Deploy canary の詳細

🔧 Cloud Deploy IAM の職務分掌

🔧 マルチターゲット並列デプロイ

🔧 ハイブリッド / マルチクラウドデプロイ

🔧 ML パイプライン統合（Vertex AI Pipelines）

🎯 Cloud Deploy 階層 即答

🎯 デプロイ戦略選定

🎯 Cloud Deploy 対応ターゲット

2.3 設定とシークレット管理

シークレット系 4 サービスの使い分け

Cloud KMS の階層と保護レベル

Workload Identity Federation（WIF）— キーレス認証

Cloud Audit Logs（CI/CD 関連）

🔧 Build-time vs Runtime Secret 注入

🔧 Build-time の例（Cloud Build）

🔧 Runtime の例（Cloud Run / GKE CSI）

🔧 WIF の詳細セットアップ

🔧 環境別 IAM ポリシーマトリクス

🎯 シークレット系 即答

🎯 Secret Manager IAM ロール

🎯 Cloud Audit Logs 即答

2.4 パイプラインのサプライチェーン保護

3 つの主役：Artifact Analysis / Binary Authorization / Continuous Validation

Artifact Analysis（旧 Container Analysis）

Severity（重大度）

Binary Authorization の用語

🔧 Binary Authorization Policy 例

🔧 Attestor 作成フロー

🔧 Cloud Build 内で Attestation 作成

🔧 Dry-run モードと Continuous Validation

🎯 Binary Auth vs Artifact Analysis vs CV

🎯 Binary Authorization 対応プラットフォーム

📜 SLSA Framework — L1 から L4 まで

🛡️ Software Delivery Shield 全体図

Assured Open Source Software（Assured OSS）

🚨 よくあるトラブル即答（症状別）

📊 ロールバック手段

🎯 要点と暗記 — 一問一答

💡 必殺フレーズ集（試験当日用・★最重要）

🧭 次のステップ

セクション 2：
CI/CD パイプライン

🔧 PR トリガーの `comment-control`

🎯 Cloud Deploy 階層即答

🎯 シークレット系即答