gcp private service connect

terraformでの構成例

まずは動くものを
https://gist.github.com/mhiroe/e4c10cd5731cdfb9f57ae7d9e9d41e21

Aレコードのみの endpointもありますが、構成上区別つけないほうがシンプルになるので、すべてzoneを用意するようにしています
併せて、リゾルバを利用してendpointのipを引いてこれるようにしています

private service connect の使い所

private.googleapis.com や restricted.rooleapis.com など、内部ネットワーク経由の googleapiアクセス手段が用意されているが、これらが利用できない場合がある

• オンプレ(インターネットとの接続なし)とGCPをVPNなどでつなぎこみ、オンプレ環境からGoogleAPIを利用したい場合、間の経路にFireWallが挟まっていると、FireWallで 199.36.153.x のパケットがドロップされる、というような事象が見られた

• 同様に、オンプレ環境から GoogleIdentityによる認証を行いたい場合 accounts.google.com へのアクセスが発生するが、
  private.googleapis.com や restricted.rooleapis.com では エンドポイントが用意されておらず利用できない、ということがあった。

• 上記のようなgoogleapi以外にも、gcpプロジェクトの内向きに APIエンドポイントを置く(インターネットを経由させない) ことが可能になる

psc endpoint が生まれた背景について

1. 情報漏洩を防ぎたいという要望があった (外部からのアクセス、内部からの漏洩) 2 外部からのアクセスは VPC SC で制限できる
2. 内部から外部への漏洩も VPC SC である程度守れるが、たとえば Box へのアップロードは防げない
3. そのため、そもそもインターネットへのアクセスを全部遮断したい
4. しかしそうすると(パブリックアドレスを持つ) Google APIs にもアクセスできなくなってしまう
5. そこで、Google APIs のうち VPC SC に対応してるサービスにだけアクセスできる restricted.google.apis.com 199.36.153.4/30 というエンドポイントを新設 (VPC SC に対応してるサービスに限定した理由は、そうしないとそのサービス経由で漏洩される危険性があるため。たとえば、X というサービスが VPC SC に対応しておらず、かつデータをアップロード/ダウンロードできるサービスの場合、そこを経由してデータの漏洩の可能性が生まれてしまう。) 7.VPC SC は使わないが、Google API に専用線やVPN経由でアクセスしたい(インターネットを経由したくない)、かつ VPC SC に対応してない API も使いたい、という要望が多かったため、private.googleapis.com 199.36.153.8/30 というエンドポイントも追加で作られた
6. 199.36.153.x というグローバル IP アドレスを使いたくない(グローバルな経路をオンプレミスに流したくない)という要望(と、そもそもプライベートなAPIエンドポイントを公開したいという要望)を満たすために、Private Service Connect というサービスが作られた