Cloud Build の概要

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

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

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

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

ビルド構成を作成して、実行するタスクを 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 を使用するか、GCP Console の 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.17 を実行しています。

Cloud Build のインターフェース

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

Google Cloud Console では、[ビルド履歴] ページで 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 Console にはセキュリティ分析情報パネルがあり、複数のセキュリティ指標の概要を確認できます。このパネルを使用して、ビルドプロセスのリスクを特定して軽減できます。

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

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

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

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

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

  • ソフトウェア デリバリー シールド

    Cloud Build は Software Delivery Shield ソリューションの一部です。ソフトウェア デリバリー シールドは、フルマネージドのエンドツーエンド ソフトウェア サプライ チェーン セキュリティ ソリューションです。ソフトウェアの構築とデプロイに使用するデベロッパー ワークフローとツール、ソフトウェアの依存関係、CI/CD システム（Google Kubernetes Engine や Cloud Run など）のセキュリティ対策の改善に役立ちます。ソフトウェア デリバリー シールドのその他のコンポーネントで Cloud Build を使用して、ソフトウェア サプライ チェーンのセキュリティ体制を改善する方法については、ソフトウェア デリバリー シールドの概要をご覧ください。

次のステップ