Cloud Build の概要

Cloud Build は、Google Cloud でビルドを実行するサービスです。

Cloud Build は、さまざまなリポジトリやクラウド ストレージ スペースからソースコードをインポートし、仕様に合わせてビルドを実行し、Docker コンテナや Java アーカイブなどのアーティファクトを生成できます。

Cloud Build を使用してソフトウェア サプライ チェーンを保護することもできます。Cloud Build の機能は、ソフトウェア アーティファクトのためのサプライ チェーン レベル（SLSA）のレベル 3 の要件を満たしています。ビルドプロセスを保護する方法については、ビルドを保護するをご覧ください。

ビルド構成とビルドステップ

ビルド構成を作成して、実行するタスクを Cloud Build に指示できます。依存関係をフェッチして、単体テスト、静的分析、結合テストを実行し、docker、gradle、maven、bazel、gulp などのビルドツールでアーティファクトを作成するようにビルドを構成できます。

Cloud Build は、一連のビルドステップとしてビルドを実行します。各ビルドステップは、Docker コンテナで実行されます。ビルドステップの実行は、スクリプトでコマンドを実行する場合と似ています。

Cloud Build や Cloud Build コミュニティで提供されているビルドステップを使用することも、独自のカスタム ビルドステップを作成することもできます。

各ビルドステップは、ローカルの Docker ネットワーク cloudbuild に接続しているコンテナで実行されます。これにより、ビルドステップが相互に通信を行い、データを共有できます。cloudbuild ネットワークの詳細については、Cloud Build ネットワークをご覧ください。

Cloud Build では、Ubuntu や Gradle などの標準の Docker Hub イメージを使用できます。

ビルドの開始

Google Cloud CLI や Cloud Build API を使用して Cloud Build で手動でビルドを開始できます。また、Cloud Build のビルドトリガーを使用して、コードの変更に応じて新しいビルドを開始する継続的インテグレーション / 継続的デリバリー（CI / CD）ワークフローを自動化することもできます。

Cloud Source Repositories、GitHub、Bitbucket など、多数のコード リポジトリとビルドトリガーを統合できます。

ビルド結果の表示

ビルドの結果を表示するには、gcloud CLI または Cloud Build API を使用するか、Google Cloud コンソールの Cloud Build セクションで [ビルド履歴] ページを使用します。このページには、Cloud Build が実行したすべてのビルドについての詳細とログが表示されます。手順については、ビルド結果の表示をご覧ください。

ビルドの仕組み

次の手順では、一般的な Cloud Build ビルドのライフサイクルについて説明します。

  1. アプリケーション コードと必要なアセットを準備します。
  2. Cloud Build の命令が含まれる YAML または JSON 形式のビルド構成ファイルを作成します。
  3. Cloud Build にビルドを送信します。
  4. Cloud Build は提供されたビルド構成に基づいてビルドを実行します。
  5. 該当する場合、ビルドされたアーティファクトは Artifact Registry に push されます。

Docker

Cloud Build は、Docker を使用してビルドを実行します。ビルドステップごとに、Cloud Build は docker run のインスタンスとして Docker コンテナを実行します。現在、Cloud Build は Docker エンジン バージョン 20.10.24 を実行しています。

Cloud Build のインターフェース

Cloud Build は、Google Cloud コンソール、gcloud コマンドライン ツール、Cloud Build の REST API で使用できます。

Google Cloud コンソールでは、[ビルド履歴] ページで Cloud Build のビルド結果を確認できます。また、ビルドトリガーでビルドを自動化できます。

gcloud CLI は、ビルドを作成して管理するために使用できます。ビルドの送信、ビルドの一覧表示、ビルドのキャンセルなどのタスクを実施するコマンドを実行できます。

Cloud Build REST API を使用するとビルドをリクエストできます。

他の Cloud Platform API と同様、OAuth2 を使用してアクセスを承認する必要があります。アクセスの承認後、API を使用して新規ビルドの開始、ビルドのステータスや詳細の表示、プロジェクト別のビルドのリスト表示、現在処理中のビルドのキャンセルなどが行えるようになります。

詳細については、API ドキュメントをご覧ください。

デフォルト プールとプライベート プール

デフォルトでは、Cloud Build でビルドを実行すると、ビルドは公共のインターネットにアクセスできる安全なホスト環境で実行されます。各ビルドは独自のワーカー上で実行され、他のワークロードから分離されます。マシンタイプのサイズを大きくする、ディスク容量を増やすなど、複数の方法でビルドをカスタマイズできます。デフォルトのプールには、環境（特にプライベート ネットワーク アクセス）をカスタマイズできる範囲に制限があります。

プライベート プールは、プライベート ネットワーク内のリソースへのアクセスなど、ビルド環境のカスタマイズを強化するワーカーのプライベート専用プールです。デフォルト プールと同様に、プライベート プールも Cloud Build によってホスト、フルマネージドされ、ゼロまでスケールアップまたはスケールダウンできます。インフラストラクチャの設定、アップグレード、スケーリングは不要です。プライベート プールはお客様固有のリソースであるため、さまざまな方法で構成できます。

プライベート プールの詳細と、デフォルト プールとプライベート プールの機能の違いについては、プライベート プールの概要をご覧ください。

ビルド セキュリティ

Cloud Build には、ビルドを保護するために以下のようなさまざまな機能があります。

  • ビルドの自動化

    自動ビルドまたはスクリプト化されたビルドは、ソースコードを取得するステップやコードをビルドするステップを含む、ビルド スクリプトまたはビルド構成内のすべてのビルドステップを定義します。手動で実行するコマンドは、ビルドを実行するコマンドのみです。 Cloud Build は、ビルド構成ファイルを使用して、Cloud Build にビルドステップを提供します。

    自動ビルドによって、ビルドステップの整合性が維持されます。ただし、一貫性のある信頼できる環境でビルドを実行することも重要です。

    ローカルビルドはデバッグ目的には便利ですが、ローカルビルドからソフトウェアをリリースすると、ビルドプロセスに多くのセキュリティ上の懸念、不整合、非効率性が生じる可能性があります。

    • ローカルビルドを許可すると、悪意のある攻撃者がビルドプロセスを変更できるようになります。
    • デベロッパーのローカル環境やデベロッパー プラクティスの不整合により、ビルドの再現やビルドの問題の診断が困難になります。

    SLSA フレームワークの要件において、自動ビルドは SLSA レベル 1 の要件であり、ビルドの開発環境ではなくビルドサービスを使用することが SLSA レベル 2 の要件です。

  • ビルドの来歴

    ビルドの来歴は、ビルドに関する検証可能なデータの集まりです。

    来歴のメタデータには、ビルドされたイメージのダイジェスト、入力ソースの場所、ビルド ツールチェーン、ビルドステップ、ビルド時間などの詳細情報が含まれます。

    ビルドの来歴を生成すると、次のことができます。

    • 信頼できるソースの場所から信頼できるビルドシステムによってビルドされたアーティファクトが作成されたことを検証します。
    • 信頼できないソースの場所またはビルドシステムから挿入されたコードを特定します。

    アラートとポリシー メカニズムを使用して、ビルドの来歴データをプロアクティブに使用できます。たとえば、検証済みのソースからビルドされたコードのデプロイのみを許可するポリシーを作成できます。

    Cloud Build は、SLSA レベル 3 の保証を提供するコンテナ イメージのビルドの来歴を生成します。詳細については、ビルドの来歴の表示をご覧ください。

  • エフェメラル ビルド環境

    エフェメラル環境は、単一のビルド呼び出しで存続することを目的とした一時的な環境です。ビルド後、環境がワイプまたは削除されます。 エフェメラル ビルドでは、ビルドサービスとビルドステップがコンテナや VM などのエフェメラル環境で実行されます。ビルドサービスは、既存のビルド環境を再利用するのではなく、ビルドごとに新しい環境をプロビジョニングし、ビルドプロセスの完了後に破棄します。

    エフェメラル環境では、ビルドプロセスを妨げる可能性のある以前のビルドの残存ファイルや環境設定がないため、クリーンなビルドが保証されます。エフェメラルでない環境では、攻撃者が悪意のあるファイルやコンテンツを挿入する機会が生じます。また、エフェメラル環境では、メンテナンス オーバーヘッドが削減され、ビルド環境の不整合が軽減されます。

    Cloud Build は、ビルドごとに新しい仮想マシン環境を設定し、ビルド後に破棄します。

  • デプロイ ポリシー

    Cloud Build と Binary Authorization を統合して、ビルド証明書を確認し、Cloud Build によって生成されていないイメージのデプロイをブロックできます。このプロセスにより、不正なソフトウェアをデプロイするリスクを軽減できます。

  • 顧客管理の暗号鍵

    Cloud Build は、デフォルトで顧客管理の暗号鍵（CMEK）のコンプライアンスをサポートしています。ユーザーが特別に構成する必要はありません。Cloud Build は、ビルドごとに生成されたエフェメラルキーでビルド時間の永続ディスク（PD）を暗号化することで、CMEK コンプライアンスを実現します。ビルドごとに固有の鍵が生成されます。

    ビルドが完了すると、すぐにキーはメモリから消去され、破棄されます。鍵の記録はどこにも保存されず、Google のエンジニアやサポートスタッフはアクセスできず、復元もできません。このようなキーを使用して保護されたデータには、永続的にアクセスできなくなります。詳細については、Cloud Build における CMEK コンプライアンスをご覧ください。

  • セキュリティ分析情報パネル

    Cloud Build には、Google Cloud コンソールの [セキュリティ分析情報] パネルがあり、複数のセキュリティ指標の概要が表示されます。このパネルを使用して、ビルドプロセスのリスクを特定して軽減できます。

    このパネルには、次の情報が表示されます。

    • ソフトウェア アーティファクトのためのサプライチェーン レベル（SLSA）: SLSA 仕様に従って、ソフトウェア ビルドプロセスの成熟度を示します。

    • 脆弱性: アーティファクトで見つかった脆弱性の概要と、Artifact Analysis によってスキャンされたイメージの名前。イメージ名をクリックすると、脆弱性の詳細が表示されます。たとえば、このスクリーンショットでは java-guestbook-backend をクリックします。

    • ビルドの詳細: ビルダーやログのリンクなど、ビルドの詳細。

    • ビルドの来歴: ビルドの来歴。

Cloud Build を他の Google Cloud プロダクトや機能とともに使用してソフトウェア サプライ チェーンを保護する方法については、ソフトウェア サプライ チェーンのセキュリティをご覧ください。

次のステップ