Cloud Identityで構築するCompute Engine 共有VPC

本格的にGCPを使い始め、複数のプロジェクトを管理するようになると、インターネット越しでなく、内部IPアドレスを使用してプロジェクト間のCompute Engine(以降、GCE)インスタンス同士を通信させたい、という要件が生まれて来るのではないでしょうか？

通常、個々のプロジェクト内に作成された各々のVPC Networkは、プロジェクトごとに独立しているのですが、「共有VPC」機能を使うことで複数プロジェクトをまたぐVPCを構築可能です。
別のやり方として、プロジェクト間でVPNを構築することも可能ですが、共有VPCはシンプルに、「同一のVPC Networkを延長する」イメージで利用できます。
本記事では、大きく分けて「Cloud Identityアカウントの作成」と「共有VPCの構成」を解説します。
前者は、共有VPCに必要となる「組織」を設定できる「Cloud Identityアカウントの作成」を解説します。
後者は、実際に共有VPCを構成し、複数のproject間の内部IPアドレスに基く疎通確認を実施します。

共有VPCが提供するもの

ざっくり言いますと、共有VPCとは、「同一の『Cloud 組織』(後述)に属する複数のプロジェクト」にまたがるVPC networkを構成することができる機能です。
GCEインスタンスを作成する際、共有設定したVPC ネットワークを指定することで、プロジェクトの境界を越えた内部IPアドレスサブネットワークを構成することができます。
公式ドキュメント: 共有VPCの概要
個別のVPC Network同士を連結するVPC Network Peeringを使用することでも、プロジェクトまたぎのVPC Network通信を構成することが可能ですが、この場合、個々のVPC Networkごとのリソース管理、サブネット設計が必要となります。

ホスト プロジェクトとサービス プロジェクト

共有VPCは、2種類のGCPプロジェクトから成り立ちます。

1. ホスト プロジェクト
2. サービス プロジェクト

図にすると、以下のようなイメージです。

※172.16.0.0/16 サブネットワークをホスト プロジェクトで作成し、これをサービス プロジェクトに見せているイメージです。

1.ホスト プロジェクト

• VPC Networkを保有し、提供する側(ホスト)となるプロジェクトです。
• firewallルール、ルートといったリソースはこちらが管理します。

2.サービス プロジェクト

• VPC Networkを「使わせてもらう側」のプロジェクトです。
• ホスト プロジェクトのリソースを利用することはできますが、リソースそのものは見えず、変更もできません。
• 1つのサービス プロジェクトが接続できるホスト プロジェクトは1つのみです。

※日本語版公式ドキュメントの構成イメージ画像がリンク切れしているため、英語版の相当部分をご覧ください。

共有VPCの構築に必要な「Cloud 組織」

共有VPCの概要には「Cloud 組織」が必要とありますが…さて、「Cloud 組織」って、何なんでしょう？
「GCP リソース階層」のドキュメントによると、Cloud 組織とは、GCPのリソースを管理するための階層構造で、これを利用するにはG Suiteアカウント、ないしCloud Identityアカウントの取得が必要となります。
G Suiteは、Googleが販売しているグループウェア+生産性ツール(つまりMS-Officeのような、いわゆるOffice Suiteのこと)です。今回はCloud 組織を利用するにあたり、 無償のCloud Identity アカウント(free edition)を取得する方法で説明します。既に G Suiteを利用している方は管理者に相談してG Suite を利用することも検討してみてください。

Cloud組織を無料で構築できるCloud Identity

GCPだけを利用できるGoogleアカウントと認証の仕組み、その所属組織を無料で提供するのがCloud Identityです。

Cloud Identityの取得は簡単

Cloud Identityの取得に必要なものリスト

• ドメイン名をホストしているDNS権威サーバの管理権限
  • ゾーン名「example.com」「sub.example.com」等のゾーン管理を委任されているネームサーバ
• 管理権限のあるGCP project

組織の識別名として、インターネットドメイン名を指定する必要があります。
また、そのドメイン名を所有していることをGoogleに対して示すため、DNSレコードを追加できることが必要です。

Cloud Identityで指定するドメインについての注意点

不正利用防止のため、Googleは「信頼性の低いドメイン」に対して、新規のCloud Identity組織登録を制限することがあります。その場合、登録時に以下のような画面が表示されます。

Freenom等の無償ドメイン名取得サービス、ieServer等のDDNSサブドメイン無償貸出サービスで取得したドメインでCloud Identityを登録しようとした場合、上記画像の画面が表示され、失敗します。
確実な方法としては、「ドメイン名の登録後、ある程度の期間に渡ってWebサイト運用実績のあるドメイン名」を指定することでしょう。
なお、サブドメインは異なるドメイン名として扱われるため、たとえば「example.com」でG Suiteを使っている場合、「sub.example.com」「grandson.sub.example.com」はそれぞれ別のG Suite組織として登録が可能です。

Cloud Identityアカウントの発行

組織の登録

Cloud Identityの組織登録手続きは、GCP projectの「IAMと管理」>「ID」メニューから開始します。

「お申し込み」リンクから、以降、ウィザード形式で設問に沿って情報を入力していきます。

ウィザード(1) では「お客様について」「お客様の事業について」、それぞれメールが受信可能なメールアドレス、組織名、地域を指定します。
ここで指定するメールアドレスは、作成される組織のドメイン名とは無関係に指定できます。

ウィザード(2)では、組織のドメイン名として指定したいドメイン名を入力します。
ここで指定するドメイン名に対応するDNSゾーンの管理権が必要です。
ドメイン名の所有権確認は、登録が完了した後のコンソールで指定することになります。
ここでは、「apps-gcp-test.cloud-ace.jp」という、「cloud-ace.jp」ドメイン名のサブドメインを指定しています。

Cloud 組織の管理者となるアカウント名、パスワードを指定します。
組織の登録に成功したのち、このユーザ名を指定してGCP Consoleにログインすることになります。
「同意して登録」を押し、登録エラー画面とならなければ登録に成功しています。
最初に指定したメールアドレスに、以降の手続を案内するメールが届きます。

ドメイン名の所有権確認

「(指定したドメイン名) 向けの Cloud Identity のご案内」という件名のメールが届くので、メールに掲載されているリンクを開き、登録時に指定した新しいアカウントでログインします。
新組織の「IAMと管理 > ID」が選択された画面が開きます。
画面の指示に従って、ドメイン名の所有権確認を実施します。
所有権確認のフローについては、G Suite版のヘルプをご覧ください。

作成された組織の選択方法について

プロジェクト選択ツール上部・左側のドロップダウンに、「組織なし」と「(追加したドメイン名)」が表示されます。
この選択ツールで、ビルのアイコン(組織)、フォルダのアイコン(フォルダ)、三角形ドットのアイコン(各プロジェクト)を切り替え、各々の設定を変更することができます。

いかがでしたでしょうか。
ドメイン名を保有していること、というハードルこそあれ、案外あっけなく登録できたのではないかと思います。

共有VPCを使ったプロジェクト間通信の実践

ここからは実際に共有VPCを構成し、両プロジェクト下のインスタンス同士の疎通確認まで実施します。
本稿は、公式ドキュメント「共有 VPC のプロビジョニング」に基いています。

おさらい ～共有VPCの構成要素～

• 共有VPCは、同一組織内に作成されたプロジェクト間(ホスト1:サービスN)でVPC Networkの共有を実現します。
• 共有されるVPC Networkの管理主体はホスト プロジェクトにあります。
  • VPC Network間のルーティング、firewall ruleはホスト プロジェクトで管理されます。
  • ホスト プロジェクトとは、共有対象に設定したVPC Networkを保有しているプロジェクトを指します。

共有VPC 構築のステップ概要

1. 組織レベルの権限「共有VPC管理者(Compute Shared VPC管理者)」権限を、作業者のアカウントに付与します。
   →作業者にプロジェクト作成権限が無ければ、あわせて付与します。
2. ホスト プロジェクト、サービス プロジェクトを作成します。
3. ホスト プロジェクトで共有対象とするVPC Networkを作成します。
4. ホスト プロジェクトの「共有VPC」メニューから、共有先に指定するサービス プロジェクト、共有対象とするVPC Networkを指定します。

共有VPCの構築

「共有VPC管理者」の権限付与(於 組織IAM)

Cloud Identityによって組織を作成したことで、組織レベルのIAM編集が可能になります。
Cloud Console上部のプロジェクトセレクターから「組織」(ビルのアイコンで示されるFQDN名のリソース)を選択することで、組織レベルの権限が編集可能となります。
ここでは、共有VPCを作成させたいメンバーに対し、「共有VPC管理者」のroleを付与します。

作成した組織を選択します。

普段、プロジェクト名が表示されているヘッダ部分に、組織名とビルのアイコンが表示されている状態となります。
この状態で、ハンバーガーメニュー(三)から「IAMと管理」を開くことで、「組織のIAM権限」を編集することができます。

今回は、メンバー「kamenashi@cloud-ace.jp」に「Compute Shared VPC管理者(共有VPC管理者)」の権限を付与します。
組織に追加したメンバー右端のエンピツアイコンを選択します。

「別の役割を追加」を選択します。

「Compute Engine」>「Compute Shared VPC 管理者」を選択します。

もし付与されていない場合、同様に「Resource Manager」>「プロジェクト作成者」も付与しておきます。

新組織上でのプロジェクトの作成

前述の通り、操作対象として組織が選択されている状態で、「IAMと管理」>「リソースを管理」から「プロジェクトを作成」します。

プロジェクト名は、ホスト プロジェクトとサービス プロジェクトの役割がひと目でわかるように付与するとよいでしょう。

今回は下図のようにホスト プロジェクト、サービス プロジェクトを作成しました。

各々のプロジェクトを選択、ハンバーガーメニュー>Compute Engineを選択し、Compute Engine APIを有効化しておきます。

共有元のVPC Networkの作成

Compute Engineが利用可能となりましたら、共有元 VPC Networkを作成します。
ホスト プロジェクトを選択します。

ハンバーガーメニュー>「VPC ネットワーク」>「VPC ネットワーク」より、「VPC ネットワークを作成」します。
この段階では、通常のVPC Networkと変わりありません。次項で共有設定をすることにより、共有VPC Networkとして扱えるようになります。

• ネットワークの名前: apps-gcp-shared-network-0
• サブネット作成モード: カスタム
• サブネットワークの名前: apps-gcp-shared-subnet-tokyo-0
• リージョン: 任意(ここではasia-northeast1を選択しています)
• IPアドレス範囲: 任意(ここでは172.16.0.0/16を選択しています)

他項目はデフォルトで、「作成」します。

firewall ruleの作成

カスタムモードで作成したVPC Networkには、defaultネットワークとは異なり、基本的なruleが設定されていません。
リモートログイン、およびインスタンス間の疎通確認のため、ホスト プロジェクトの「VPC Network」>「ファイアウォールルール」で、以下2点のルールを作成しておきます。
優先度は今回影響しないため、どちらもデフォルトの1000で問題ありません。

VPC Networkの共有設定

いよいよ、ホスト プロジェクトに作成したVPC Networkを共有させます。
「VPC ネットワーク」>「共有VPC」>「共有VPCを設定」 を選択します。

共有VPCの有効化に必要なステップが表示されます。
「保存して続行」することで、現在操作対象としているプロジェクトが、ホスト プロジェクトに指定されます。

1分程度経過し、準備が整うと、右ペインに共有対象の選択画面が表示されます。
「すべてのサブネットを共有する」こともできますが、今回は「個々のサブネット」、対象は先程作成した「apps-gcp-shared-subnet-tokyo-0」のみを指定します。
「続行」を選択します。

• 「サービス プロジェクトの接続」で、接続させたいサービス プロジェクトを選択します。
  • 今回は、先程作成した「apps-gcp-shared-vpc-service」プロジェクトのみ指定します。
• 「役割別のユーザーの選択」で指定した権限を「サービスプロジェクトに対して持っている」ユーザーに対して、自動的に「共有VPC対象に指定したネットワークを使用する権限」(Compute ネットワーク ユーザー)が付与されます。

構成が完了すると、以下の画面に遷移します。
図中の赤矢印部リンク(共有者)を選択すると、「接続したサービス プロジェクトに対し、前項で指定した権限を持っているユーザー」が追加されていることがわかります。

これで、2プロジェクト間の共有設定は完了です。
いよいよ、共有VPC ネットワークを使用するインスタンスを作成してネットワークの疎通状況を確認してみましょう。

疎通確認インスタンスの作成

サービス プロジェクト側インスタンス

サービス プロジェクト側Compute Engine(以降GCE)インスタンスを作成する場合、非・共有VPC環境とは異なる選択肢が出現します。
サービス プロジェクトを選択します。

「Compute Engine」>「VM インスタンス」>「作成」と選択、次を指定します。

1. インスタンス名: apps-gcp-service-pj-instance
2. ゾーン: 共有VPC Networkを作成したリージョンに含まれるゾーン(ここではasia-northeast1-aを選択)
3. マシンタイプ: 任意
4. ブートディスク:任意(ここではdebian-9を選択)
5. 「管理、ディスク、ネットワーク、SSH認証鍵」メニューを展開
   • 「ネットワーキング」タブを選択
   • 「ネットワーク インターフェイス」> 「default」をポイントし削除(ゴミ箱アイコン)
   • 「+ ネットワーク インターフェイスを追加」→次の画像をご覧ください。

サービス プロジェクトでは、「このプロジェクトのネットワーク/共有ネットワーク」を選択できるようになります。
一方、ホスト プロジェクトで作成する場合、ホスト プロジェクトにとってこのサブネットは「自分自身の保有するネットワーク」であるため、この選択肢は表示されません。
「共有ネットワーク」を選択、「共有サブネットワーク」を指定し、「完了」でネットワーク インターフェイスダイアログを閉じます。

「作成」ボタンで、インスタンスの作成を確定します。

ホスト プロジェクト側インスタンス

前述の通り、ホスト プロジェクト側インスタンスで指定するパラメータは、単独プロジェクトでsubnetworkを指定する場合と同様です。
ホスト プロジェクトを選択します。

「Compute Engine」>「VM インスタンス」>「作成」と選択、次を指定します。

1. インスタンス名: apps-gcp-host-pj-instance
2. ゾーン: 共有VPC Networkを作成したリージョンに含まれるゾーン(ここではasia-northeast1-bを選択)
3. マシンタイプ: 任意
4. ブートディスク:任意(ここではdebian-9を選択)
5. 「管理、ディスク、ネットワーク、SSH認証鍵」メニューを展開
   • 「ネットワーキング」タブを選択
   • 「ネットワーク インターフェイス」> 「default」をポイントし削除(ゴミ箱アイコン)
   • 「+ ネットワーク インターフェイスを追加」

共有VPCを使用しない場合と同様の、ネットワーク選択フォームが表示されます。
作成した共有VPC ネットワークである「apps-gcp-shared-network-0」、「apps-gcp-shared-subnet-tokyo-0」を指定し、「完了」、インスタンス作成を確定します。

疎通確認

いよいよ、両プロジェクトの準備が整いました。
対象のインスタンス達は、同一のVPC ネットワークに接続しているため、内部DNSを利用した名前解決が可能です。
つまり、お互いの内部IPアドレスを、以下のホスト名で解決できます。

hostName.c.[PROJECT_ID].internal

pingを送信するホスト名は、以下の対応関係になります。

各インスタンスへコンソールからSSH接続し、お互いにpingが通ることを確認します。

▼サービス → ホスト

▼ホスト → サービス

プロジェクトを跨いだ、内部IPアドレスでの通信が実現できました。

おわりに

いかがでしたでしょうか。組織リソースのIAM設定を除いて、特に難しい点は無かったのではないかと思います。
Cloud Identityを利用することで、G Suiteを契約することなく共有VPCを構成してみることが可能となり、テンポよく検証していただけるかと思います。
もちろん、既にG Suiteをご契約いただいている方は、そのアカウントを用いて、同様に共有VPCを構成できます。
この機会に共有VPCを是非、お試しください。