Google Cloud Platform（GCP）では、Compute Engine APIを有効化すると、無効化しない限り新規プロジェクトごとにデフォルトのVPCネットワークが作成されます。
カスタムVPCやサブネットを自前で用意する必要がないため、GCPを手軽に使い始められます。一方で、デフォルトネットワークでは自動生成されるサブネットがすべて10.128.0.0/9 CIDRブロック内の事前定義されたIPv4範囲を使うという問題があります。
この結果、ネットワーク範囲が重複してしまい、プロジェクト間のプライベート内部通信ができません。この制約はVPCピアリングとCloud VPNのいずれにも当てはまります。
本記事では、Private Service Connectを使い、ネットワークが重複するVM/GKEクラスタ上のサービスへプライベートにアクセスする方法を解説します。同一GCP組織内でも、別組織にまたがる場合でも適用できます。
リファレンスアーキテクチャ
目指すPrivate Service Connectの構成
Project Bはサービスプロデューサー側のプロジェクトで、マネージドインスタンスグループ上にサンプルのnginxサービスをデプロイします。
Project Aはサービスコンシューマー側のプロジェクトで、Project B上のサービスへプライベートにアクセスする必要があります。両プロジェクトのインスタンスには外部IPは付与しません。
- リソースのGCPリージョンは_us-west4_
- Project A・Project Bともに_compute.googleapis.com_ APIを有効化
- 外部IPなしのインスタンスがパッケージを取得できるよう、Cloud NATを利用
サンプルサービスとテストインスタンスのデプロイ
以下のコマンド内の変数は環境に合わせて書き換えてください。
- Project Bでインスタンステンプレートを作成します。
gcloud compute instance-templates create nginx-service-instance-template \--machine-type=e2-medium \--network-interface=network=default,no-address \--metadata=startup-script=\ \#\!\ /bin/bash
- Project Bでマネージドインスタンスグループを作成します。
gcloud beta compute instance-groups managed create nginx-service-instance-group \--base-instance-name=nginx-service \--size=1 \--template=nginx-service-instance-template \--zone=us-west4-a \--list-managed-instances-results=PAGELESS \--no-force-update-on-repair \--project=$PROJECT_B
作成に成功すると、マネージドインスタンスグループが指定のゾーンでインスタンスを起動します。
そのインスタンスにSSH接続し、nginxサービスのステータスを確認してください。
- Project Aで接続テスト用のインスタンスを作成します。
gcloud compute instances create instance-1 \ --zone=us-west4-b \ --machine-type=e2-medium \ --network-interface=stack-type=IPV4_ONLY,subnet=default,no-address \ --maintenance-policy=MIGRATE \ --provisioning-model=STANDARD \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --create-disk=auto-delete=yes,boot=yes,device-name=instance-2,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=projects/project-a-385206/zones/us-west4-b/diskTypes/pd-balanced \ --no-shielded-secure-boot \ --shielded-vtpm \ --shielded-integrity-monitoring \ --labels=ec-src=vm_add-gcloud \ --reservation-affinity=any \ --project=$PROJECT_A
Project AとProject Bのネットワーク間には内部接続がないため、Project AのインスタンスからProject B上のサービスへはアクセスできません。
また、デフォルトネットワークのIP範囲が重複しているため、VPCピアリングも利用できません。
内部ロードバランサのセットアップ
Private Service Connectでサービスアタッチメント経由でサービスを公開するには、内部ロードバランサが必要です。ここではProject Bに内部TCPロードバランサを作成します。
- ポート80でVMへのHTTP接続性を確認するリージョナルHTTPヘルスチェックを新規作成します。
gcloud compute health-checks create http nginx-service-health-check \ --region=us-west4 \ --port=80 \ --project=$PROJECT_B
- HTTPトラフィック用のバックエンドサービスを作成します。
gcloud compute backend-services create nginx-service-internal-lb-backend \ --load-balancing-scheme=internal \ --protocol=tcp \ --region=us-west4 \ --health-checks=nginx-service-health-check \ --health-checks-region=us-west4 \ --project=$PROJECT_B
- nginxサービスのインスタンスグループをバックエンドサービスに追加します。
gcloud compute backend-services add-backend nginx-service-internal-lb-backend \ --region=us-west4 \ --instance-group=nginx-service-instance-group \ --instance-group-zone=us-west4-a \ --project=$PROJECT_B
- バックエンドサービス向けの転送ルールを作成します。
gcloud compute forwarding-rules create nginx-service-internal-fr \ --region=us-west4 \ --load-balancing-scheme=internal \ --network=default \ --subnet=default \ --ip-protocol=TCP \ --ports=80 \ --backend-service=nginx-service-internal-lb-backend \ --backend-service-region=us-west4 \ --project=$PROJECT_B
- ロードバランサのヘルスチェックを許可するファイアウォールルールを設定します。
gcloud compute firewall-rules create allow-internal-lb-health-check \--direction=INGRESS \--priority=1000 \--network=default \--action=ALLOW \--rules=tcp:80 \--source-ranges=35.191.0.0/16,130.211.0.0/22--project=$PROJECT_B
プロデューサー側プロジェクトでのサービス公開
サービスプロデューサー側であるProject Bでサービスを公開し、別のVPCネットワーク上のコンシューマーがプライベートかつ安全に接続・アクセスできるようにします。
- Private Service Connect用のサブネットを確保します。デフォルトネットワークと重複しない範囲を指定してください。
gcloud compute networks subnets create private-service-connect \--network default \--region us-west4 \--range 10.0.1.0/24 \--purpose=PRIVATE_SERVICE_CONNECT \--project=$PROJECT_B
- 明示的な承認付きで、nginxサービスをProject Aに公開します。
gcloud compute service-attachments create nginx-service \ --region=us-west4 \ --producer-forwarding-rule=nginx-service-internal-fr \ --connection-preference=ACCEPT_MANUAL \ --nat-subnets=private-service-connect \ --consumer-accept-list=$PROJECT_A=10 \ --project=$PROJECT_B
公開サービスにアクセスできるコンシューマーは、自動承認・手動承認のいずれかで制御できます。詳しくはPrivate Service Connectでサービスを公開するをご覧ください。
- Private Service Connectから対象インスタンスへのアクセスを許可するファイアウォールルールを設定します。
gcloud compute firewall-rules create allow-private-service-connect \--direction=INGRESS \--priority=1000 \--network=default \--action=ALLOW \--rules=tcp:80 \--source-ranges=10.0.1.0/24--project=$PROJECT_B
コンシューマー側プロジェクトでのエンドポイント設定
コンシューマー側プロジェクトのエンドポイントは、Private Service Connectの転送ルールを介して、プロデューサー側VPCネットワーク上のサービスに接続します。
エンドポイントを作成すると、任意の名前空間または既定の名前空間「goog-psc-default」のもとで、自動的にService Directoryに登録されます。
複数リージョンからエンドポイントを利用したい場合は、グローバルアクセスを有効にしてください。なお、グローバルアクセスはプレビュー段階の機能です。
- エンドポイントに割り当てる内部IPアドレスを確保します。
gcloud compute addresses create private-service-connect-endpoint \ --region=us-west4 \ --subnet=default \ --project=$PROJECT_A
- エンドポイントとProject B側のサービスアタッチメントを結ぶ転送ルールを作成します。
PSC_SERVICE_ATTACHMENT=$(gcloud compute service-attachments describe nginx-service \ --region=us-west4 \ --project=$PROJECT_B \ --format="value(selfLink.scope(projects))")
gcloud compute forwarding-rules create nginx-service \ --region=us-west4 \ --network=default \ --address=private-service-connect-endpoint \ --target-service-attachment="projects/$PSC_SERVICE_ATTACHMENT" \ --project=$PROJECT_A
コンシューマー側プロジェクトからの接続確認
これでProject A・Project BにPrivate Service Connectの構成要素が揃いました。Project A側のエンドポイントIPからProject Bのnginxサービスにアクセスしてみましょう。
テスト結果から、ネットワーク範囲が重複していてもPrivate Service Connectエンドポイント経由でインスタンス間のプライベート通信が成立することが確認できます。
本記事では、Private Service Connectを活用して、ネットワーク範囲が重複する環境でもサービスを安全に公開・利用する方法を紹介しました。
トラフィックは終始Google Cloud内に留まり、コンシューマーとプロデューサー間のサービス指向アクセスを、アクセス方法まで細かく制御しながら実現できます。
Private Service Connectの詳細は、製品ページをご覧ください。
\n'yum\ install\ epel-release
- Project Bでマネージドインスタンスグループを作成します。
作成に成功すると、マネージドインスタンスグループが指定のゾーンでインスタンスを起動します。
そのインスタンスにSSH接続し、nginxサービスのステータスを確認してください。
- Project Aで接続テスト用のインスタンスを作成します。
Project AとProject Bのネットワーク間には内部接続がないため、Project AのインスタンスからProject B上のサービスへはアクセスできません。
また、デフォルトネットワークのIP範囲が重複しているため、VPCピアリングも利用できません。
内部ロードバランサのセットアップ
Private Service Connectでサービスアタッチメント経由でサービスを公開するには、内部ロードバランサが必要です。ここではProject Bに内部TCPロードバランサを作成します。
- ポート80でVMへのHTTP接続性を確認するリージョナルHTTPヘルスチェックを新規作成します。
- HTTPトラフィック用のバックエンドサービスを作成します。
- nginxサービスのインスタンスグループをバックエンドサービスに追加します。
- バックエンドサービス向けの転送ルールを作成します。
- ロードバランサのヘルスチェックを許可するファイアウォールルールを設定します。
プロデューサー側プロジェクトでのサービス公開
サービスプロデューサー側であるProject Bでサービスを公開し、別のVPCネットワーク上のコンシューマーがプライベートかつ安全に接続・アクセスできるようにします。
- Private Service Connect用のサブネットを確保します。デフォルトネットワークと重複しない範囲を指定してください。
- 明示的な承認付きで、nginxサービスをProject Aに公開します。
公開サービスにアクセスできるコンシューマーは、自動承認・手動承認のいずれかで制御できます。詳しくはPrivate Service Connectでサービスを公開するをご覧ください。
- Private Service Connectから対象インスタンスへのアクセスを許可するファイアウォールルールを設定します。
コンシューマー側プロジェクトでのエンドポイント設定
コンシューマー側プロジェクトのエンドポイントは、Private Service Connectの転送ルールを介して、プロデューサー側VPCネットワーク上のサービスに接続します。
エンドポイントを作成すると、任意の名前空間または既定の名前空間「goog-psc-default」のもとで、自動的にService Directoryに登録されます。
複数リージョンからエンドポイントを利用したい場合は、グローバルアクセスを有効にしてください。なお、グローバルアクセスはプレビュー段階の機能です。
- エンドポイントに割り当てる内部IPアドレスを確保します。
- エンドポイントとProject B側のサービスアタッチメントを結ぶ転送ルールを作成します。
コンシューマー側プロジェクトからの接続確認
これでProject A・Project BにPrivate Service Connectの構成要素が揃いました。Project A側のエンドポイントIPからProject Bのnginxサービスにアクセスしてみましょう。
テスト結果から、ネットワーク範囲が重複していてもPrivate Service Connectエンドポイント経由でインスタンス間のプライベート通信が成立することが確認できます。
本記事では、Private Service Connectを活用して、ネットワーク範囲が重複する環境でもサービスを安全に公開・利用する方法を紹介しました。
トラフィックは終始Google Cloud内に留まり、コンシューマーとプロデューサー間のサービス指向アクセスを、アクセス方法まで細かく制御しながら実現できます。
Private Service Connectの詳細は、製品ページをご覧ください。
\n'yum\ -y\ install\ nginx
- Project Bでマネージドインスタンスグループを作成します。
作成に成功すると、マネージドインスタンスグループが指定のゾーンでインスタンスを起動します。
そのインスタンスにSSH接続し、nginxサービスのステータスを確認してください。
- Project Aで接続テスト用のインスタンスを作成します。
Project AとProject Bのネットワーク間には内部接続がないため、Project AのインスタンスからProject B上のサービスへはアクセスできません。
また、デフォルトネットワークのIP範囲が重複しているため、VPCピアリングも利用できません。
内部ロードバランサのセットアップ
Private Service Connectでサービスアタッチメント経由でサービスを公開するには、内部ロードバランサが必要です。ここではProject Bに内部TCPロードバランサを作成します。
- ポート80でVMへのHTTP接続性を確認するリージョナルHTTPヘルスチェックを新規作成します。
- HTTPトラフィック用のバックエンドサービスを作成します。
- nginxサービスのインスタンスグループをバックエンドサービスに追加します。
- バックエンドサービス向けの転送ルールを作成します。
- ロードバランサのヘルスチェックを許可するファイアウォールルールを設定します。
プロデューサー側プロジェクトでのサービス公開
サービスプロデューサー側であるProject Bでサービスを公開し、別のVPCネットワーク上のコンシューマーがプライベートかつ安全に接続・アクセスできるようにします。
- Private Service Connect用のサブネットを確保します。デフォルトネットワークと重複しない範囲を指定してください。
- 明示的な承認付きで、nginxサービスをProject Aに公開します。
公開サービスにアクセスできるコンシューマーは、自動承認・手動承認のいずれかで制御できます。詳しくはPrivate Service Connectでサービスを公開するをご覧ください。
- Private Service Connectから対象インスタンスへのアクセスを許可するファイアウォールルールを設定します。
コンシューマー側プロジェクトでのエンドポイント設定
コンシューマー側プロジェクトのエンドポイントは、Private Service Connectの転送ルールを介して、プロデューサー側VPCネットワーク上のサービスに接続します。
エンドポイントを作成すると、任意の名前空間または既定の名前空間「goog-psc-default」のもとで、自動的にService Directoryに登録されます。
複数リージョンからエンドポイントを利用したい場合は、グローバルアクセスを有効にしてください。なお、グローバルアクセスはプレビュー段階の機能です。
- エンドポイントに割り当てる内部IPアドレスを確保します。
- エンドポイントとProject B側のサービスアタッチメントを結ぶ転送ルールを作成します。
コンシューマー側プロジェクトからの接続確認
これでProject A・Project BにPrivate Service Connectの構成要素が揃いました。Project A側のエンドポイントIPからProject Bのnginxサービスにアクセスしてみましょう。
テスト結果から、ネットワーク範囲が重複していてもPrivate Service Connectエンドポイント経由でインスタンス間のプライベート通信が成立することが確認できます。
本記事では、Private Service Connectを活用して、ネットワーク範囲が重複する環境でもサービスを安全に公開・利用する方法を紹介しました。
トラフィックは終始Google Cloud内に留まり、コンシューマーとプロデューサー間のサービス指向アクセスを、アクセス方法まで細かく制御しながら実現できます。
Private Service Connectの詳細は、製品ページをご覧ください。
\n'systemctl\ start\ nginx \--maintenance-policy=MIGRATE \--provisioning-model=STANDARD \--scopes=https://www.googleapis.com/auth/cloud-platform \--create-disk=auto-delete=yes,boot=yes,device-name=nginx-service-instance-template,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=pd-balanced \--no-shielded-secure-boot \--shielded-vtpm \--shielded-integrity-monitoring \--reservation-affinity=any \--project=$PROJECT_B
- Project Bでマネージドインスタンスグループを作成します。
作成に成功すると、マネージドインスタンスグループが指定のゾーンでインスタンスを起動します。
そのインスタンスにSSH接続し、nginxサービスのステータスを確認してください。
- Project Aで接続テスト用のインスタンスを作成します。
Project AとProject Bのネットワーク間には内部接続がないため、Project AのインスタンスからProject B上のサービスへはアクセスできません。
また、デフォルトネットワークのIP範囲が重複しているため、VPCピアリングも利用できません。
内部ロードバランサのセットアップ
Private Service Connectでサービスアタッチメント経由でサービスを公開するには、内部ロードバランサが必要です。ここではProject Bに内部TCPロードバランサを作成します。
- ポート80でVMへのHTTP接続性を確認するリージョナルHTTPヘルスチェックを新規作成します。
- HTTPトラフィック用のバックエンドサービスを作成します。
- nginxサービスのインスタンスグループをバックエンドサービスに追加します。
- バックエンドサービス向けの転送ルールを作成します。
- ロードバランサのヘルスチェックを許可するファイアウォールルールを設定します。
プロデューサー側プロジェクトでのサービス公開
サービスプロデューサー側であるProject Bでサービスを公開し、別のVPCネットワーク上のコンシューマーがプライベートかつ安全に接続・アクセスできるようにします。
- Private Service Connect用のサブネットを確保します。デフォルトネットワークと重複しない範囲を指定してください。
- 明示的な承認付きで、nginxサービスをProject Aに公開します。
公開サービスにアクセスできるコンシューマーは、自動承認・手動承認のいずれかで制御できます。詳しくはPrivate Service Connectでサービスを公開するをご覧ください。
- Private Service Connectから対象インスタンスへのアクセスを許可するファイアウォールルールを設定します。
コンシューマー側プロジェクトでのエンドポイント設定
コンシューマー側プロジェクトのエンドポイントは、Private Service Connectの転送ルールを介して、プロデューサー側VPCネットワーク上のサービスに接続します。
エンドポイントを作成すると、任意の名前空間または既定の名前空間「goog-psc-default」のもとで、自動的にService Directoryに登録されます。
複数リージョンからエンドポイントを利用したい場合は、グローバルアクセスを有効にしてください。なお、グローバルアクセスはプレビュー段階の機能です。
- エンドポイントに割り当てる内部IPアドレスを確保します。
- エンドポイントとProject B側のサービスアタッチメントを結ぶ転送ルールを作成します。
コンシューマー側プロジェクトからの接続確認
これでProject A・Project BにPrivate Service Connectの構成要素が揃いました。Project A側のエンドポイントIPからProject Bのnginxサービスにアクセスしてみましょう。
テスト結果から、ネットワーク範囲が重複していてもPrivate Service Connectエンドポイント経由でインスタンス間のプライベート通信が成立することが確認できます。
本記事では、Private Service Connectを活用して、ネットワーク範囲が重複する環境でもサービスを安全に公開・利用する方法を紹介しました。
トラフィックは終始Google Cloud内に留まり、コンシューマーとプロデューサー間のサービス指向アクセスを、アクセス方法まで細かく制御しながら実現できます。
Private Service Connectの詳細は、製品ページをご覧ください。