Private Service Connect機能解説。Google Cloud APIにプライベート接続

記事タイトルとURLをコピーする

G-genの杉村です。当記事では Google Cloud API にプライベートネットワーク経由でアクセスするための機能である Private Service Connect について解説します。

概要

Private Service Connect とは

Private Service Connect とは、 External IP (Public IP) を持たない VM やオンプレミスのクライアントからプライベートネットワーク経由で Google Cloud の API 群や、Google Cloud でホストする独自サービスへアクセスできるようにするための仕組みです。

この機能では VPC 内に IP アドレスを持つエンドポイントが作成され、このエンドポイント経由で Google Cloud API や独自サービスにアクセスできるようになります。

当記事では、Private Service Connect で Google Cloud API にアクセスする方法について紹介します。

Google Cloud ドキュメントより引用

Google Cloud API とは

前提知識の確認として Google Cloud の API とは何かについておさらいします。

Google Cloud サービスに対する閲覧・更新・追加・削除などは ほとんど全てが Web API により操作され ます。これは AWS など他のパブリッククラウドでも同様です。

これについては以下の記事の「API コールとは?」の項で詳細に説明していますので、ぜひご参照ください。

セキュリティ上の理由から、これらの API へのアクセスをプライベートなネットワーク内で行いたいというケースも出てきます。

" 限定公開の Google アクセス "機能を使うと External IP を持っていない VM やオンプレミスのノードから、様々な Google API 群にアクセスできるようになります。

しかし "限定公開の Google アクセス" 機能だと 199.36.153.4/30 や 199.36.153.8/30 といった RFC 1918 (※) ではない IP アドレスを使う必要がある ため、 Cloud Interconnect や Cloud VPN 経由でオンプレミス環境から利用する際などに、ルーティングが複雑化するなど少し不便な場合がありました。
(※ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 の範囲内にあるいわゆるプライベート IP アドレス)

限定公開の Google アクセス機能については、以下の解説記事をご参照ください。

blog.g-gen.co.jp

一方で当記事で解説する Private Service Connect 機能を利用すれば、 VPC 内に IP アドレスを持つエンドポイントを作成し、このエンドポイント経由で Google API にアクセスできます。

このエンドポイントには任意の IP アドレスを割り当てることができ、 RFC 1918 で定義された IP アドレスでも、そうでなくても構いません。

機能のポイント

Private Service Connect 機能のポイントは以下の通りです。

  • Private Service Connect エンドポイント (Private IP アドレスが割り当てられる) を作成し、オンプレミスのノードや VPC 内の VM はそのエンドポイント経由で Google API へアクセスできる
  • エンドポイント作成時に以下の種類から選択する
    • 1.all-apis
    • 2.vpc-sc
  • エンドポイントには時間ごとに 料金 が発生 (月およそ820円程度)

イメージ

Private Service Connect でマネージドサービスを公開する

本投稿では詳しく紹介しませんが、もう一つの Private Service Connect の機能として、他の Google Cloud 環境に自環境でホストするサービスを公開する機能があります (マネージドサービスの公開)。これは AWS PrivateLink に類似した機能です。

以下の記事でご紹介していますので、ご参照ください。

blog.g-gen.co.jp

なぜ Private Service Connect を導入するか

Google Cloud API はインターネット経由でアクセスする必要があるため、これをセキュアでないと考える方も多いと思います。しかし、 API コールは HTTPS (TLS) で暗号化 されます。そのため、鍵情報の漏洩がなければ、パケットが盗聴されても内容は解読されません。

Google から TLS 証明書の鍵情報が漏洩し、さらにパケットが盗聴・復号されて情報が漏洩する可能性は、低いと言ってよいでしょう。

そのため Private Service Connect や限定公開の Google アクセスを用いる主たる理由は「 (NAT など含め) インターネットに接していないノードを Google API へアクセスできるようにするため」であると言えます。

このことから、もともとインターネットへ出ていけるノードであれば、あえて Private Service Connect や限定公開の Google アクセスを利用するように構成変更する必要性は薄いです。

Private Service Connect vs Private Google Access

機能の違い

Private Service Connect に似た機能として 限定公開の Google アクセス (Private Google Access) があります。

Private Service Connect を設定する際には「限定公開の Google アクセス」機能を有効化する必要がありますので、 Private Service Connect 機能は 限定公開の Google アクセス 機能の拡張版と考えることもできます。

これら2つの機能は、できることはほぼ同じですが、以下のような違いがあります。

  • 限定公開の Google アクセス機能では API エンドポイントとして利用する仮想 IP として 199.36.153.4/30199.36.153.8/30 といった RFC 1918 定義外の IP アドレスを使う必要がある
  • 限定公開の Google アクセス機能では デフォルトのドメイン名を使う場合に限り DNS の追加設定が不要で手軽に利用できる
    • しかしこのパターンでは 0.0.0.0/0 へのルートと Egress ファイアウォールを開ける必要がある
  • 限定公開の Google アクセス機能では料金が発生しない

どちらを使えばよいのか?

Private Service Connect vs 限定公開の Google アクセス ということになりますが、どのように判断したらよいでしょうか。

結論として以下となります。

  1. 以下の全てに当てはまる場合は Private Service Connect を選択する
    • オンプレミスからのプライベートネットワーク経由での Google API 利用がある
    • 限定公開の Google アクセスで使われる 199.36.153.4/30 または 199.36.153.8/30 を使うにあたり、経路交換や経路制御で不都合がある
      • 例: オンプレミス側のクライアントによって異なる通信先 VPC や使用する回線を変えるため複数のエンドポイントを使用したい
      • 例: RFC 1918 以外の IP アドレスが広報されてくることが望ましくない
  2. それ以外の場合は 限定公開の Google アクセス を選択する (無料のため)

利用する IP アドレスとして 199.36.153.4/30 または 199.36.153.8/30 が許容できる場合は、無償で利用できる限定公開の Google アクセスを選択するのがよいでしょう。

限定公開の Google アクセス機能については、当ブログの 解説記事 で紹介していますので、ぜひご参照ください。

設計ポイント・考慮点

エンドポイントの種類

エンドポイントの種類によって、アクセス可能な Google API が異なります。

all-apis の場合、 Google Cloud のほとんどのサービスや Google Map, Google 広告など多くのサービスへ接続することができます。

vpc-sc の場合、接続できるのは VPC Service Controls でサポートされているサービスだけです。

VPC Service Controls を使用しておらず将来的に使用する予定も全く無い場合は前者を選択します。

一方で VPC Service Controls を使用している / 使用する予定がある場合で、かつ VPC Service Controls がサポートしていないサービスへのアクセスが不要な場合は後者を利用するとよいでしょう。

エンドポイントの IP アドレス

Private Service Connect エンドポイント作成時には、1つの Private IP アドレスを割り当てます。

RFC 1918 アドレス (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) でもそうでなくても構いませんが、 IPv6 アドレスは使えません。

エンドポイントの IP アドレスは、 サブネットの IP アドレスとは重複できません

また、 VPC とネットワークピアリングや Cloud Interconnect, Cloud VPN 等で接続されているネットワークと重複してもいけません。

将来的な VPC サブネットの拡張などを考慮して、 重複が起きない、かつ IP リソースの無駄使いにならない ような IP アドレスを指定しましょう。

また、もしオンプレミス環境から Cloud Interconnect や Cloud VPN 経由で Private Service Connect エンドポイントを使いたい場合は、 Google Cloud から広報するルートの集約性を考慮して、 VPC サブネットの IP アドレス帯と隣り合った IP アドレスにするのが望ましいでしょう。

DNS 設定

Cloud Storage の Web API のエンドポイントは https://storage.googleapis.com/ であり BigQuery の API エンドポイントは https://bigquery.googleapis.com/ です。

通常は、これらの IP アドレスを名前解決すると、パブリック IP が返ってきます。

storage.googleapis.comの名前解決の結果

これでは Private Service Connect エンドポイントを作ったとしても、 gcloud コマンドや gsutil コマンドといったクライアントはこれらのパブリック IP を目指してパケットを投げてしまいます。

そこで、以下のいずれかの方法で、クライアントが Private Service Connect エンドポイントを向くようにしてあげます。

  1. クライアント (SDK) 側の設定で Private Service Connect エンドポイントを参照するよう設定する
  2. DNS 設定で一律に Private Service Connect エンドポイントを向くように設定する

1.は、クライアント (gcloud や Cloud SDK) 側で向き先のエンドポイントを変える方法です。Private Service Connect エンドポイントを作成すると <サービス名>.<エンドポイント名>.p.googleapis.com という DNS ゾーンが作成されます。gcloud や Python SDK 側のコマンドで向き先エンドポイント URL を明示的にこれらに指定することができます。こちらでは DNS 設定を変更することなく Private Service Connect エンドポイントを使うことができます。

手順は 公式ドキュメント を御覧ください。

2.は、VM が参照する DNS のほうで *.googleapis.com に対する CNAME レコードを作成し、それを Private Service Connect エンドポイントの IP アドレスへ解決させることで、クライアント側の設定を変えることなく Private Service Connect エンドポイントを参照させる方法です。こちらは クライアント側の設定やプログラムのコードを変更することなく Private Service Connect エンドポイントを使うことができます。

本記事では特に 2 の方法を紹介します。

設定手順

設定手順の概要

Private Service Connect の設定手順のおおまかな流れを以下に記載します。

  1. 必要な API を有効化
  2. Private Service Connect エンドポイントを作成 (コンソールリンク)
  3. 対象のサブネットで 限定公開の Google アクセスを有効化 (コンソールリンク)
  4. VPC ファイアウォールで エンドポイント IP アドレスへの 443/TCP の 下り (Egress) 通信が拒否されていない ことを確認 (デフォルト状態では許可) (コンソールリンク)
  5. Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 (コンソールリンク)
  6. 同ゾーンに以下を追加
    • DNS名: googleapis.com
    • タイプ: A
    • IPv4アドレス: (エンドポイントの IP アドレス)
  7. 同ゾーンに以下を追加
    • DNS名: *.googleapis.com
    • タイプ: CNAME
    • 正規名: googleapis.com

詳細な手順

本投稿の意義は概念の説明であるため、概要だけを記載しました。
より詳細な設定手順は、以下の公式ドキュメントをご参照ください。

cloud.google.com

DNS 設定の意味を解説

最後の DNS 設定について少し解説します。

例えば VM の中で gsutil コマンドを実行して Cloud Storage へのアクセスが発生したとしましょう。
gsutil コマンドは Web API コールをするために storage.googleapis.com へ HTTPS でアクセスしようとします。
すると VM はデフォルトでは Cloud DNS を参照していますから、限定公開ゾーンを優先的に使って名前解決をします。

クライアントの動作の流れを見てみましょう。

  1. VM が storage.googleapis.com を名前解決するため Cloud DNS へ DNS クエリする
  2. これは *.googleapis.com に一致しているので CNAME で googleapis.com へ解決される
  3. googleapis.com は A レコードで エンドポイントの IP アドレス に解決され VM へ返答
  4. gsutil コマンドはエンドポイントの IP アドレスへ Web API コールを実行

参考まで、 Cloud DNS でのレコード追加済みの画面と、実際に VM の中から名前解決を試みた結果を御覧ください。

Cloud DNSでレコードが設定されている

VMからCloud Storageを名前解決するとエンドポイントURLが返る

オンプレミスから利用する

Cloud Interconnect や Cloud DNS で接続されたオンプレミス環境から Private Service Connect エンドポイントを利用するには、以下の設定が必要です。

  • Private Service Connect エンドポイントの IP アドレスをオンプレミス側に広報する
  • オンプレミスノードが参照する DNS にフォワーダー設定を追加して、 Google API の名前解決を Cloud DNS に転送する

1つ目は Cloud Router の カスタムルート アドバタイズ を使うことで実現可能です。
2つ目は Cloud DNS の 受信サーバー ポリシー で実現可能です。

2つ目については、オンプレミスのクライアントが Private Service Connect エンドポイントに向けば良いので、オンプレミスノードが参照する DNS に直接 Cloud DNS と同じレコードを追加してもよいでしょう。
(ただし二重管理となってしまうため、理由がない限り望ましくありません。)

設定手順は 公式ドキュメント をご参照ください。

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。