Google Cloud で外部 IP を持たない VM から Cloud Storage を読みたい、あるいは Cloud SQL に内部 IP で繋ぎたい、と思ったときに出てくる候補がこれです。
- Private Google Access
- Private Service Connect
- private services access
- VPC Service Controls
private、service、access、connect、controls。5つの単語を並べ替えただけの名前で、4つの別々の機能があります。日本語ドキュメントではさらに近づいていて、Private Google Access が「プライベート Google アクセス」、private services access が「プライベート サービス アクセス」です。文中に出てきたときに、どちらの話をしているのか一読では判別できません。
役割は完全に別で、代わりにはなりません。1本の記事で切り分けます。
まず引くべき線
4つを同じ列に並べるのが間違いのもとです。VPC Service Controls だけ種類が違います。
| 何をするものか | |
|---|---|
| Private Google Access | 経路を作る |
| Private Service Connect | 経路を作る |
| private services access | 経路を作る |
| VPC Service Controls | 経路を塞ぐ |
前の3つは、外部 IP を持たない VM からサービスに届かせるための手段です。VPC Service Controls は逆で、届いてしまう範囲を狭めるための境界です。前者を検討しているときに後者を候補に入れる必要はありませんし、その逆もありません。
この線引きは公式ドキュメントの構成にも表れています。プライベートアクセスの選択肢を挙げたページに並んでいるのは、Private Service Connect、Private Google Access、private services access、そして VPC ネットワークピアリングの4つで、VPC Service Controls は入っていません。接続の手段ではないからです。
残り3つを分けるのは、接続先の種類です。公式ドキュメントは Google Cloud のサービスを2種類に分けています。
Google APIs and services that run on Google's production infrastructure.
VPC-hosted services that run on Compute Engine VMs in VPC networks.
（Private access options for services）
前者は *.googleapis.com で叩く API や *.run.app のようなもので、Google の本番インフラの上で動いています。後者は Cloud SQL、Filestore、Memorystore のように、実体が VM で、どこかの VPC ネットワークの中で動いているものです。マネージドサービスと一括りにされがちですが、ネットワーク的な位置がまるで違います。
この2つを踏まえると、全体はこう整理できます。
| 接続先 | 実装 | 接続元 | |
|---|---|---|---|
| Private Google Access | Google の本番インフラ上の API | サブネットの設定。既定のインターネットゲートウェイ経由で外部 IP 宛に出す | 外部 IP を持たない VM |
| Private Service Connect | 両方（API も VPC 上のサービスも） | 自分の VPC に内部 IP のエンドポイントを作る | 外部 IP の有無を問わず。オンプレミスからも |
| private services access | VPC 上のサービス | 提供者の VPC と VPC ピアリングで繋ぐ | 外部 IP の有無を問わない VM |
| VPC Service Controls | （接続手段ではない） | 組織、フォルダ、プロジェクトに境界を張る | 該当なし |
以下、1つずつ見ていきます。
Private Google Access
外部 IP を持たない VM から Google API に届かせる、最も古くからある方法です。
VM instances that only have internal IP addresses (no external IP addresses) can use Private Google Access. They can reach the external IP addresses of Google APIs and services.
（Private Google Access）
引用の後半が、この機能の分かりにくいところです。届く先は Google API の外部 IP アドレスです。名前に private と付いていても、プライベートな IP 空間に閉じた通信路を作るわけではありません。VM が持っていない外部 IP の代わりに、Google 側が経路を通してくれる仕組みだと考えるのが実態に近いです。
設定はサブネット単位で、VPC 単位でもプロジェクト単位でもありません。同じネットワークの中に、有効なサブネットと無効なサブネットが混在します。有効化を忘れたサブネットに VM を置くと、そこだけ通信できません。
もう1つ注意すべき点は、外部 IP を持つ VM には何の影響もないことです。
Private Google Access has no effect on instances that have external IP addresses.
外部 IP を持つ VM は元から Google API に到達できるので、この設定は関係しません。セキュリティを強化する設定ではなく、外部 IP を外すための前提条件だと捉えるほうが正確です。
対応していないものもあります。rep.googleapis.com で終わるリージョン別、マルチリージョン別のエンドポイントは Private Google Access では届きません。この場合は別の方法を取ることになります。
オンプレミスから使うときの2つのドメイン
Private Google Access には、オンプレミスのホスト向けの形もあります。Cloud VPN や Cloud Interconnect の先から Google API を叩くための経路で、専用のドメインと VIP を使います。
| ドメイン | IPv4 レンジ | 対象 |
|---|---|---|
private.googleapis.com |
199.36.153.8/30 |
VPC Service Controls への対応を問わず、ほとんどの Google API |
restricted.googleapis.com |
199.36.153.4/30 |
VPC Service Controls が対応している API のみ。非対応の API へのアクセスは遮断される |
どちらも Google Workspace の Web アプリ（Gmail や Google ドキュメント）には使えません。
この2つは、選択肢というより方針の表明です。restricted.googleapis.com を選ぶと、VPC Service Controls に対応していない API には最初から到達できなくなります。境界の外に持ち出せる経路を物理的に減らしたいなら、こちらを選びます。
DNS は自分で用意します。*.googleapis.com の CNAME を選んだドメインに向け、そのドメインの A レコードに4つのアドレス（private.googleapis.com なら 199.36.153.8 から 199.36.153.11）を設定する、という手順が公式に載っています。
Private Service Connect
比較的新しく、そして守備範囲が最も広いのがこれです。自分の VPC ネットワークの中に内部 IP を持つ出入り口を作り、そこを通してサービスに届かせます。
Google API にも VPC 上のサービスにも使えて、形も3種類あります。
- エンドポイント。転送ルールを作って内部 IP を1つ払い出す。L4 の接続性だけが必要ならこれ
- バックエンド。ネットワークエンドポイントグループ経由でロードバランサの後ろに置く。独自ドメインと証明書を前段に立てたい、リージョン間のフェイルオーバーを自分で制御したい、という場合に使う
- インターフェース。向きが逆で、サービス提供者側からコンシューマの VPC に接続を張るためのもの
Google API に使う場合、Private Google Access との違いは3つあります。自分の内部 IP を使えること、経路を自分で制御できること、必要なだけ作れることです。公式もこの機能を Private Google Access と似ていると前置きしたうえで、その差を説明しています。
This functionality is similar to Private Google Access, except that you can use your own internal IP addresses for endpoints. Private Service Connect lets you more directly control routing and create as many endpoints as necessary for your network.
（Private Service Connect）
エンドポイントを作るときは、API のバンドルを選びます。ここで Private Google Access のドメインと綺麗に対応します。
These bundles provide access to the same APIs that are available through the Private Google Access VIPs—all-apis is equivalent to private.googleapis.com and vpc-sc is equivalent to restricted.googleapis.com.
（Access Google APIs through endpoints）
all-apis が private.googleapis.com に、vpc-sc が restricted.googleapis.com に相当します。名前は全く違いますが、選んでいるものは同じです。この対応が分かると、2つの機能の関係が一気に見通せます。
なお、Google API 向けのエンドポイントに払い出される内部 IP はグローバル内部 IPv4 アドレスなので、VPC のどのリージョンからでも、また Cloud VPN や Cloud Interconnect で繋いだオンプレミスからも使えます。一方で VPC ピアリング経由のアクセスには対応していません（公式の対応表でも、Cloud Interconnect と Cloud VPN は対応、VPC ネットワーク ピアリングは非対応と示されています）。グローバル内部 IPv4 アドレスはピアリングで交換されないためです。ピアリングで繋いだ隣の VPC のために作ったエンドポイントは使えないので、そちらにも作ることになります。
private services access
Cloud SQL や Filestore、Memorystore に内部 IP で繋ぐときに使われてきた方式です。実装が独特で、そこが制約に直結します。
This private connection is established using a VPC Network Peering connection.
（Private services access）
サービス提供者（Google または third party）の VPC ネットワークと、自分の VPC を VPC ピアリングで繋ぎます。手順はこうです。
- 自分の VPC で IP アドレス範囲を割り当てる。この範囲はサービス提供者に予約され、サブネットにも静的ルートの宛先にも使えなくなる
- その範囲を指定して、プライベート接続を作る
- サービス提供者が専用のプロジェクトと VPC ネットワークを作り、割り当て範囲の中から
/29から/24程度のサブネットを切る。この範囲は自分では選べないし変更もできない - サービスインスタンスにそのサブネットの IP が割り当てられ、ピアリング経由で経路が取り込まれる
自分の IP 空間の一部を提供者に貸し出す形です。範囲が小さいと後から増やせずに詰まりますし、範囲が大きいと自分のサブネットに使える空間が減ります。
制約はピアリングの制約がそのまま出ます。
Because VPC Network Peering isn't transitive, a private connection isn't available to peered VPC networks.
ピアリングは推移しません。自分の VPC にピアリングしている別の VPC からは、この Cloud SQL に届きません。ハブアンドスポークの真ん中に private services access を置く、という設計はここで破綻します。共有 VPC か Network Connectivity Center を使うか、Private Service Connect に寄せるかの選択になります。
さらに、1つのサービスインスタンスにプライベート接続を張れるコンシューマ VPC は1つだけです。
オンプレミスから使う場合にも落とし穴があります。プライベート接続で交換されるのはサブネットルートだけなので、提供者のネットワークはオンプレミス宛の経路を知りません。かといってデフォルトルート（0.0.0.0/0）を広報しても効きません。提供者のネットワークが自前のデフォルトルートを持っていて、そちらが優先されるためです。より具体的な宛先のカスタムルートを定義して広報する、というのが公式の指示です。
こうした制約の積み重なりもあってか、Private Service Connect への移行が進んでいます。サブネットの用途一覧に PEER_MIGRATION という値があり、共有 VPC のサービスを Private Service Connect に移行するためのものだと説明されています。新規に組むなら、対象のサービスが Private Service Connect に対応しているかを先に確認するほうがいいと考えています。
VPC Service Controls
ここまでの3つとは目的が反対です。経路を作るのではなく、境界を張ってデータの持ち出しを防ぎます。
境界の中のリソースに対して、外の（公開されているかもしれない）リソースへのアクセスを禁じる、gcloud storage cp や bq mk のようなサービス操作でのコピーを止める、といった制御を行います。
IAM との関係が分かりにくいところですが、公式は明確に別の層だと書いています。
While IAM enables granular identity-based access control, VPC Service Controls enables broader context-based perimeter security, including controlling data egress across the perimeter. We recommend using both VPC Service Controls and IAM for defense in depth.
（Overview of VPC Service Controls）
IAM は identity で判断し、VPC Service Controls は文脈（送信元の IP アドレスや VPC ネットワーク、デバイスの情報など）で判断します。層が分かれているので、盗まれたサービスアカウントの鍵で正規の権限を使われても、境界の外からのアクセスなら止まります。IAM の設定を間違えて公開状態になっていた場合も同様です。IAM だけでは埋まらない穴があるから両方使う、という位置づけです。
制限付き VIP（restricted.googleapis.com）との組み合わせが推奨されるのもここに繋がります。境界を張っても、境界に対応していない API 経由でデータが出ていく経路が残っていると意味が薄れるためです。
そして、公式が明示している限界が1つあります。
VPC Service Controls is not designed to enforce comprehensive controls on metadata movement.
守るのはデータであって、メタデータではありません。ドキュメントの例では、Cloud Storage オブジェクトの中身がデータで、バケット名がメタデータだとされています。バケット名やリソースの属性まで完全に閉じ込めるものではない、という前提で設計する必要があります。
なお、いきなり本番に適用すると通信が広範囲に止まります。ドライランモードで実際のリクエストを観測してから有効化する手順が公式に用意されているので、そちらから始めるのが安全です。
どう選ぶか
判断の順序はこうなります。
- 目的が持ち出しの制限なら VPC Service Controls。ここは他と競合しない
- 接続先が Google の本番インフラ上の API（
*.googleapis.comなど）か、VPC 上で動くサービス（Cloud SQL、Filestore、Memorystore など）かを確認する - Google API が相手で、単に外部 IP なしの VM から叩きたいだけなら Private Google Access。サブネットの設定1つで済む
- 自分の内部 IP を使いたい、経路を細かく制御したい、オンプレミスからも同じ入口を使いたい、という要件があるなら Private Service Connect
- VPC 上のサービスが相手なら、まず Private Service Connect に対応しているかを確認する。対応していなければ private services access
4つは排他ではありません。公式にも、それぞれ独立して動作するので複数を同時に設定できると書かれています。実際、Private Google Access で API に出しつつ、Cloud SQL には private services access で繋ぎ、全体を VPC Service Controls の境界で囲む、という構成は普通にあります。
まとめ
- VPC Service Controls だけが経路を塞ぐ側で、残り3つは経路を作る側。まずここを分ける
- 経路を作る3つは、接続先が Google の本番インフラ上の API か、VPC 上で動くサービスかで分かれる
- Private Google Access はサブネット単位の設定で、届く先は Google API の外部 IP。外部 IP を持つ VM には影響しない
- オンプレミス向けの
private.googleapis.comとrestricted.googleapis.comは、VPC Service Controls 非対応の API を通すか遮断するかの選択 - Private Service Connect は自分の内部 IP でサービスに繋ぐ方式。API バンドルの
all-apisとvpc-scは、それぞれ上記2つのドメインと同じものを指している - private services access は VPC ピアリングで実装されているので、推移しないという制約がそのまま効く。1インスタンスに繋げるコンシューマ VPC は1つ
- VPC Service Controls は IAM とは別の層で文脈を見る。守るのはデータで、メタデータは対象外
名前が似ているのは、どれも同じ問題（インターネットを経由せずに繋ぐ）に対する答えだからです。ただし答え方は別で、後から乗り換えるときのコストも違います。最初に接続先の種類を確認しておくと、選択肢は2つ以下に絞れます。