はじめのProfessional Cloud Developer認定取得講座⑫Binary Authorization × Cloud Build 実装ガイド、Cloud Tasks・Pub/Sub・Eventarcの使い分け、CSEK（顧客指定暗号鍵）HTTP 400/403 エラー完全解決ガイドを説明します！

クラウド

Professional Cloud Developer 試験では、単にアプリケーションを開発するだけでなく、「安全に」「スケーラブルに」「運用しやすく」構築できるかが重要な評価ポイントになります。

特に近年は、CI/CD におけるセキュリティ強化、イベント駆動アーキテクチャ、暗号鍵管理といった実践的なクラウドネイティブ設計が強く求められています。

本記事では、Binary Authorization × Cloud Build による安全なデプロイ制御、Cloud Tasks・Pub/Sub・Eventarc の適切な使い分け、そして CSEK のトラブルシューティングについて解説します。これらはいずれも、Google Cloud を利用した本番運用で頻出する重要テーマです。


また、試験対策だけでなく、実際のシステム設計やSRE・DevSecOpsの現場でも役立つ知識を整理しています。Google Cloud における「安全性・非同期処理・暗号化運用」の理解を深めたい方は、ぜひ参考にしてください。

今回も音声ファイルも挿入していますので、ブログの内容を音声でご確認いただけます。通勤中などにご利用いただければと思います。

是非、最後までご覧いただけると嬉しいです。

Binary Authorization × Cloud Build 実装ガイド

CI/CD の自動化が進む一方で、「本当にテスト済みの安全なコンテナだけが本番へデプロイされているのか？」という課題は、多くの組織で重要なテーマになっています。特に GKE のような高速なデプロイ基盤では、誤ったイメージや未検証のアーティファクトが混入した際の影響は非常に大きくなります。
そこで注目されているのが、Binary Authorization と Cloud Build を組み合わせた「署名ベース」のデプロイ制御です。回帰テストを通過したイメージだけに証跡（Attestation）を付与し、その署名が存在する場合のみ本番デプロイを許可することで、サプライチェーンセキュリティを大幅に強化できます。
本記事では、Attestor・証跡・ポリシーの基本から、Cloud Build と連携した自動署名パイプラインの実装方法、さらに安全な運用を実現するベストプラクティスまでを体系的に解説します。

1. Binary Authorizationの核となる概念

この仕組みを理解するために、3つの主要な要素を押さえましょう。

  • ポリシー (Policy)：デプロイを許可するための「ルール」です。「特定の署名（証跡）がある場合のみ許可する」といった設定を行います。
  • 認証者 (Attestor)：イメージの品質を保証する「権限」を持つエンティティです。今回のケースでは「回帰テストシステム」が認証者となります。
  • 証跡 (Attestation)：特定のイメージがテストをパスしたことを証明する「デジタル署名」です。Artifact Analysisのノートにメタデータとして保存されます。

2. 回帰テスト連動型デプロイの構築ステップ

回帰テストに合格したイメージだけをデプロイ可能にするための最短ルートを解説します。

ステップ1：GKEクラスターとAPIの準備

GKEクラスターでBinary Authorizationを有効にします。

＜gcloudコマンド＞

gcloud container clusters create [CLUSTER_NAME] \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone [ZONE]
⚠️ フラグの変更
現在の正しいフラグは --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE です。旧来の --enable-binauthz は現行バージョンでは使用できません。

また、プロジェクトで以下のAPIを有効化しておきます。

＜gcloudコマンド＞

gcloud services enable \
    binaryauthorization.googleapis.com \
    containeranalysis.googleapis.com
⚠️ 重要
Binary Authorizationを有効化しただけではクラスターは保護されません。デフォルトではすべてのイメージのデプロイが許可されており、保護を機能させるにはポリシーを明示的に設定・適用する必要があります。

ステップ2：認証者（Attestor）の作成

「回帰テスト合格」を証明するための認証者を作成します。

  1. Artifact Analysisノートの作成：証跡を保存するための器を作ります。
  2. KMSキーペアの作成：署名に使用する非対称鍵ペアをCloud KMSで作成します（アルゴリズム例：ec-sign-p256-sha256）。
  3. 認証者の登録：Cloud KMSの公開鍵を紐付けた認証者をBinary Authorizationに登録します。

＜gcloudコマンド＞

gcloud container binauthz attestors create [ATTESTOR_NAME] \
    --attestation-authority-note=[NOTE_ID] \
    --attestation-authority-note-project=[PROJECT_ID]

gcloud container binauthz attestors public-keys add \
    --attestor=[ATTESTOR_NAME] \
    --keyversion-project=[KMS_PROJECT_ID] \
    --keyversion-location=[KMS_LOCATION] \
    --keyversion-keyring=[KMS_KEYRING] \
    --keyversion-key=[KMS_KEY] \
    --keyversion=[KMS_KEY_VERSION]

ステップ3：Cloud Build パイプラインの実装

Cloud Buildのパイプラインを構築する前に、Cloud BuildのサービスアカウントにArtifact Analysisノートへのアタッチ権限（roles/containeranalysis.notes.attacher）を付与する必要があります。

＜gcloudコマンド＞

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member=serviceAccount:[PROJECT_NUMBER]@cloudbuild.gserviceaccount.com \
    --role=roles/containeranalysis.notes.attacher

その上で、以下の自動ワークフローをCloud Buildに組み込みます。

  1. ビルド & プッシュ：アプリケーションイメージを作成し、Artifact Registryへプッシュ。
  2. 回帰テストの実行：pytest や go test などで回帰テストを実行。
  3. 証跡の作成（条件付き）：テストが成功した場合のみ、Cloud KMSの鍵を使用してイメージのダイジェストに署名し、証跡を作成します。

＜gcloudコマンド＞

gcloud container binauthz attestations sign-and-create \
    --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" \
    --attestor=[ATTESTOR_NAME] \
    --attestor-project=[PROJECT_ID] \
    --keyversion-project=[KMS_PROJECT_ID] \
    --keyversion-location=[KMS_LOCATION] \
    --keyversion-keyring=[KMS_KEYRING] \
    --keyversion-key=[KMS_KEY] \
    --keyversion=[KMS_KEY_VERSION]
💡 ダイジェスト指定が必須
Binary Authorizationは証跡の参照にイメージのダイジェストを使用するため、デプロイ時は latest などのタグではなく sha256:... 形式のダイジェストでイメージを指定する必要があります。タグによるデプロイでは証跡の照合が機能しません。

ステップ4：ポリシーの設定

最後に、Binary Authorizationのポリシーを「デフォルトで拒否」に設定し、特定の「回帰テスト認証者」による署名がある場合のみデプロイを許可するように構成します。

＜YAMLファイル＞

# policy.yaml
name: projects/[PROJECT_ID]/policy
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
    - projects/[PROJECT_ID]/attestors/[ATTESTOR_NAME]

3. なぜこの方法が「最適」なのか

1. ヒューマンエラーの完全な排除

開発者が誤ってローカルでビルドした未テストのイメージを kubectl apply しようとしても、GKEのAdmission Controllerが署名の欠落を検知し、デプロイを即座にブロックします。

2. 権限の分離

デプロイを実行する権限（ユーザーやCIツール）と、イメージを「認証」する権限（KMS鍵へのアクセス権）を分離できます。仮にCIツールの実行権限が盗まれても、テストをパスしていないイメージが本番に混入することを防げます。

3. 透明性の確保

Artifact Analysisを確認すれば、「どのイメージが、いつ、どの鍵で署名されたか」という履歴がすべて残るため、監査対応も容易になります。

Binary Authorization × Cloud Build 実装ガイドのまとめ

Binary Authorization を導入することで、「どのイメージをデプロイするか」だけでなく、「誰が品質を保証したか」まで含めた厳格なデプロイ制御を実現できます。特に Cloud Build と組み合わせることで、回帰テスト成功時のみ自動署名を付与する安全な CI/CD パイプラインを構築可能です。
また、Attestor と KMS 鍵を利用することで、認証権限とデプロイ権限を分離でき、未検証イメージの混入を防止できます。さらに、ダイジェストベースのデプロイや Artifact Analysis による監査ログ管理により、透明性と追跡性も向上します。
単なる「デプロイ制限」ではなく、テスト結果を本番デプロイ条件として強制できる点こそが Binary Authorization の最大の価値です。これらを実践することで、安全性・再現性・監査性を兼ね備えたモダンなGKE運用基盤を実現できます。

Cloud Tasks・Pub/Sub・Eventarcの使い分け

大規模な予約システムでは、「ユーザーを待たせない高速な応答」と「バックエンドでの確実な処理」を両立することが重要です。
しかし、決済処理や在庫更新、通知送信などを同期的に実行すると、レスポンス遅延や競合によるダブルブッキングの原因になります。そこで重要になるのが、Cloud Tasks・Pub/Sub・Eventarc を適切に使い分けたイベント駆動アーキテクチャです。Cloud Tasks は期限付きタスクやリトライ制御、Pub/Sub は複数システムへのイベント配信、Eventarc はインフラレベルのイベント連携に強みがあります。これらを組み合わせることで、即時性・可用性・拡張性を兼ね備えたシステムを構築できます。
本記事では、予約システムを例に、それぞれの役割の違いと最適な設計パターンを実践的に解説します。

1. ユーザーを待たせない「即時確定」の仕組み

ユーザーが席を選択した際、アプリケーションがすべての処理（在庫更新、決済、メール送信）を終えてからレスポンスを返していては、タイムアウトや競合が発生します。

推奨されるフロー

  1. アトミックな在庫更新：データベース（FirestoreやCloud Spannerなど）で、対象の席を「予約中（Reserved）」に即座に更新します。
  2. 成功レスポンスの返却：在庫の更新に成功した時点で、ユーザーに「席を確保しました。15分以内に決済を完了してください」というメッセージを返します。
  3. イベントの発火：後続の処理（決済確認、通知など）を非同期で行うため、メッセージをキューに投げます。

2. Pub/Sub と Cloud Tasks：どちらを使うべきか？

予約プロセスには、「不特定多数への通知」と「特定のタスクの実行」という2つの側面があります。Google Cloudでは、用途に応じてこれらを使い分けます。

Cloud Pub/Sub：多方面への情報拡散

Pub/Subは「1対多」のメッセージングに最適です。

  • 用途：「席が予約された」というイベントを、分析チームのダッシュボード、在庫追跡システム、ログ保存用サービスなど、複数の宛先に同時に伝えたい場合に使用します。
  • メリット：メッセージの送信元（パブリッシャー）は、受け取り側（サブスクライバー）が誰であるかを知る必要がなく、システムが疎結合になります。

Cloud Tasks：確実なタスク実行とスケジュール管理

Cloud Tasksは「1対1」のタスク管理に特化しています。

  • 用途：予約システムで最も重要な「15分以内に決済されなければ席を解放する」といった、特定の時間に実行される処理に最適です。
  • メリット
    • スケジュール実行：「今から15分後」に実行するタスクを登録できます。
    • リトライ制御：送信先がダウンしていても、成功するまで指数バックオフでリトライしてくれます。
    • レート制限：バックエンドの処理能力に合わせて、リクエストの流量を調整できます。

3. 実践：予約プロセスを支えるコンポーネント構成

① 予約成立時の「Eventarc」活用

Firestoreのドキュメント更新（予約データの書き込み）をトリガーに、自動的に後続の処理（Cloud RunやWorkflowsなど）を呼び出したい場合は、EventarcとFirestoreを組み合わせたイベント駆動アーキテクチャが便利です。コード内に「メッセージを投げる」処理を書かなくても、インフラレベルでイベントをフックしてくれます。 

⚠️ 注意：GCSはデータベースではありません
EventarcはCloud Storage（GCS）のファイル操作（アップロードなど）もトリガーにできますが、GCSはオブジェクトストレージサービスであり、データベースではありません。予約データの管理にはFirestoreやCloud Spannerなどのデータベースを使用し、そのドキュメント変更をEventarcのトリガーとするのが正しいパターンです。

② 決済タイムアウトの実装（Cloud Tasksの真骨頂）

予約完了のAPI内で、Cloud Tasksのキューに「15分後のキャンセルチェックタスク」を追加します。

  • ユーザーが15分以内に決済を完了すれば、そのタスクを削除するか、タスク実行時にDBをチェックして「決済済みなら何もしない」ようにします。
  • 決済がなければ、タスクが走り、席を「空き」状態に戻します。

比較表

機能Cloud Pub/SubCloud Tasks
通信モデル1対多 (Fan-out)1対1 (Point-to-point)
実行タイミングほぼリアルタイム特定の時間指定が可能
管理主体メッセージ（データ）タスク（作業）
リトライ自動（デッドレタートピックで制御可能）詳細なリトライポリシーの設定が可能

4. 監視と信頼性の担保

予約というミッションクリティカルな処理では、メッセージが詰まっていないかを監視することが不可欠です。

  • Cloud Tasks のモニタリング：キュー内のタスク数やエラー率をダッシュボードで確認し、異常があれば通知を送るように設定します。
  • デッドレター トピック：Pub/Subでどうしても処理できなかったメッセージを隔離し、後で原因究明できるように設定しておきます。

Cloud Tasks・Pub/Sub・Eventarcの使い分けのまとめ

Cloud Tasks・Pub/Sub・Eventarc は、それぞれ異なる役割を持つ重要なイベント駆動サービスです。
Cloud Tasks は「確実に実行したい処理」や「時間指定タスク」に適しており、決済期限管理のような用途で真価を発揮します。
一方、Pub/Sub は複数システムへのイベント通知に優れており、疎結合なシステム設計を実現できます。
さらに、Eventarc を利用することで、Firestore などのイベントをトリガーにしたサーバーレスな自動連携も可能になります。
予約システムでは、DBによる即時ロックと非同期処理を組み合わせることで、高速なUXと整合性を両立できます。
これらを適切に使い分けることで、急激なアクセス増加にも耐えられる、信頼性の高いクラウドネイティブなシステムを構築できます。

CSEK（顧客指定暗号鍵）HTTP 400/403 エラー完全解決ガイド

Cloud Storage の CSEK（Customer-Supplied Encryption Keys）は、ユーザー自身が暗号鍵を管理できる強力な暗号化方式ですが、その分、鍵やヘッダーの扱いを誤ると HTTP 400 / 403 エラーが発生しやすいという特徴があります。
特に、「正しい鍵を指定しているはずなのにアクセスできない」というケースでは、Base64 エンコードや SHA256 ハッシュの計算ミスが原因になっていることも少なくありません。また、CSEK は Google 側で鍵を保持しないため、アップロード時と異なる鍵を使用すると復旧不能になる点にも注意が必要です。
本記事では、HTTP 400 / 403 エラーの違い、確認すべきヘッダー、デバッグ方法、そして運用上の注意点までを体系的に解説します。さらに、gcloud storage を用いた切り分け手順や、より運用しやすい CMEK との違いについても紹介します。CSEK を安全かつ確実に運用したいエンジニア向けに、実践的なトラブルシューティング方法をまとめました。

1. エラーコード別の原因切り分け

まずは、返却されている 4xx エラーの種類から原因を特定しましょう。

以下のケースではすべて HTTP 400（Bad Request） が返されます。

ケースエラー
CSEKでアップロードしたオブジェクトに、鍵を指定せずにアクセスしようとした400
CSEKでアップロードしたオブジェクトに、誤った鍵でアクセスしようとした400
CSEKなしでアップロードしたオブジェクトに、CSEKを付けてアクセスしようとした400
アルゴリズム・鍵・SHA256ハッシュが無効な形式で指定された400
💡 403 Forbidden について
CSEKの文脈での 403 は、IAMの権限不足（バケットやオブジェクトへのアクセス権がない場合）に対して返されます。「鍵の不一致」は 403 ではなく 400 であることに注意してください。

2. チェックすべき 3 つの必須ヘッダー

CSEKを使用してオブジェクトを読み取る（GET リクエスト）際には、以下の 3 つのヘッダーを正確に送信する必要があります。

ヘッダー名設定すべき値
x-goog-encryption-algorithmAES256（固定）
x-goog-encryption-key顧客の 256 ビット AES 鍵を Base64 でエンコードしたもの
x-goog-encryption-key-sha256顧客鍵の SHA256 ハッシュ値を Base64 でエンコードしたもの

3. 解決のためのチェックリスト

エラーを解消するために、以下の項目を一つずつ確認してください。

① 鍵の「生データ」と「エンコード」の混同

x-goog-encryption-key には、32 バイトのバイナリ鍵を Base64 文字列に変換したものを設定する必要があります。よくあるミスは、Base64 変換後の文字列をさらにハッシュ化したり、逆にハッシュ化してから Base64 にし忘れるケースです。

② SHA256 ハッシュ値の検証

GCS は、渡された key-sha256 ヘッダーを使用して、提供された鍵の整合性チェックを事前に行います。

＜正しい計算手順＞

Base64( SHA256( RawBinaryKey ) )

もしこの値が 1 ビットでも異なれば、GCS はリクエストを拒否します。

③ 鍵の管理ミス（最大の盲点）

ユーザーがアプリケーションに入力した鍵が、アップロード時と全く同じであることを再確認してください。CSEKではGoogleが鍵を永続的に保存することはなく、ユーザーが入力ミスをしている場合、システム側では「正しい鍵」を知る術がないため、データの読み取りは永久にできません。

4. デバッグのヒント：gcloud storage コマンドでの確認

アプリケーションのコードに問題があるのか、あるいは鍵そのものが違うのかを切り分けるために、コマンドラインから直接アクセスを試みるのが最も効率的です。

現在の推奨ツールは gcloud storage コマンドです。--encryption-key フラグで鍵を指定してコピーを試みます。

＜gcloudコマンド＞

gcloud storage cp gs://[バケット名]/[オブジェクト名] . \
    --decryption-keys=[YOUR_BASE64_ENCODED_KEY]

これでダウンロードに成功すれば鍵は合っており、失敗すれば「入力された鍵そのものがアップロード時のものと違う」ことが確定します。

💡 gsutil について
旧来の gsutil コマンドと .boto 設定ファイルによる方法も引き続き使用できますが、現在は gcloud storage コマンドへの移行が推奨されています。

5. CSEKの運用上の注意と代替手段

CSEKは強力なセキュリティを提供しますが、鍵の管理をすべてユーザー側で行う必要があり、紛失した場合のリカバリが一切できないという運用上のリスクがあります。

鍵の自社管理は維持しつつ、より安全な鍵のライフサイクル管理を行いたい場合は、CMEK（顧客管理暗号鍵） と Cloud KMS の組み合わせも検討してください。CMEKはCloud KMSで鍵を管理するため、鍵のローテーションや失効が容易になります。

CSEK（顧客指定暗号鍵）HTTP 400/403 エラー完全解決ガイドのまとめ

CSEK の HTTP 400 / 403 エラーは、多くの場合「鍵の不一致」や「ヘッダー構成ミス」が原因です。
特に、x-goog-encryption-key と x-goog-encryption-key-sha256 の生成方法を正しく理解することが重要になります。
また、CSEK 関連のエラーでは 400 が返され、403 は IAM 権限不足である点を正確に切り分ける必要があります。
問題発生時は、gcloud storage コマンドを利用して、アプリケーション実装と鍵そのものの問題を分離して確認することが有効です。
さらに、CSEK は Google 側で鍵を保持しないため、鍵を紛失するとデータ復旧が不可能になる点にも注意が必要です。より安全かつ運用しやすい構成を求める場合は、Cloud KMS と連携した CMEK の採用も有力な選択肢となります。

まとめ

今回は、下記３点について説明しました。

  1. Binary Authorization × Cloud Build 実装ガイド
  2. Cloud Tasks・Pub/Sub・Eventarcの使い分け
  3. CSEK（顧客指定暗号鍵）HTTP 400/403 エラー完全解決ガイド

Binary Authorization、Cloud Tasks / Pub/Sub / Eventarc、CSEK は、それぞれ異なるレイヤーで Google Cloud の信頼性と安全性を支える重要な仕組みです。

Binary Authorization を活用することで、テスト済みイメージのみを本番へデプロイできる、安全な CI/CD 基盤を構築できます。また、Cloud Tasks・Pub/Sub・Eventarc を適切に使い分けることで、高速なユーザー体験と堅牢な非同期処理を両立したイベント駆動アーキテクチャを実現できます。
さらに、CSEK の正しい運用方法やエラー切り分けを理解することで、暗号化ストレージ運用時のトラブルにも迅速に対応可能になります。

これらの知識は Professional Cloud Developer 試験だけでなく、実際のクラウドシステム設計・運用においても非常に重要です。Google Cloud の各サービスを単体で理解するだけでなく、「どのように組み合わせて安全かつスケーラブルに運用するか」を意識することが、実践的なクラウドアーキテクトへの第一歩となります。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！

スポンサーリンク
タイトルとURLをコピーしました