なぜこの機能ができたのか

Cloud Buildを利用する場合に筆者の頭をこれまで散々悩ませてきたのは、「VPC外部からアクセスさせないリソースでもCloud Buildからはアクセスさせたい」ケースでした。
どうしてもこれを実現させようとすると、GitLabをVPC内部に起動してGitLabCIから操作しましょう、みたいな話をしたこともありますが、Cloud Buildでそれができるようになったようですので試してみましょう。
ドキュメントはこちらです。

private poolを作る

早速private-poolを作ってみました。
プロジェクト番号やVPC ネットワークの指定を空白にすると、

ピアリングのためのIPアドレス範囲を予約する

つづいて、 GCPが提供するservicenetworkingへのピアリングのためにIPアドレス範囲を予約して接続する必要がありますが、これはMemoryStoreやFilestoreなどを利用したことがあるなら既に作成されているはずなので省略できます。
筆者の検証環境でも既に作成済みですが、手順を紹介します。

まずはVPCネットワークにピアリング用のIPアドレス範囲を予約します。
google-managed-services-private-poolという名前で作成しました。

このアドレス範囲を利用して、次のように接続を設定します。

この記事では 10.83.208.0/20 のアドレス範囲でservicenetworkingと接続されているものとします。
servicenetworking内にあるprivate poolが、このIPアドレス範囲からVPCネットワークにトラフィックを送信できるという理解をしてください。

VPCとの接続を確認する

VPCネットワーク内部にwebサーバを起動して、private poolのCloud Buildから到達できることを確認します。
webサーバの作成は省略しますが、10.100.0.2に起動しています。
次のようなCloud Build定義ファイルを用意します。

steps:
- name: 'byrnedo/alpine-curl'
  args: ['http://10.100.0.2']
options:
  pool:
    name: 'projects/<YOUR_PROJECT_ID>/locations/asia-northeast1/workerPools/private-pool'

options.poolでCloud Buildを実行したいprivate poolを指定しています。
curlが使えるコンテナをDocker Hubから探して指定しています。

FirewallルールでHTTPリクエストが許可されていることを確認して実行すると、次のようにアクセスログが出力されました。

10.83.208.7 - - [31/Jul/2021:04:53:23 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.66.0" "-"

10.83.208.7 というのは、servicenetworkingのために予約したIPアドレス範囲と一致しているので、想定通りに設定できていそうです。

Master Authorized Networkを設定したGKEでの利用

今までのCloud Buildでは、Master Authorized Networkを設定したKubernetesクラスタへデプロイを行うことができませんでした。
GKEのMaster Nodeは自身のVPCネットワーク内に存在しているわけではありませんので、Cloud Buildのprivate poolを作成し、それを利用するだけではMaster Nodeに到達できません。
このケースでprivate poolを利用する方法が公式ドキュメントにまとめられているので、紹介して終わりにします。