共有 VPC を使用すると、ホスト プロジェクトの VPC ネットワークから、同じ組織内の別のサービス プロジェクトにサブネットをエクスポートできます。サービス プロジェクトのインスタンスは、ホスト プロジェクトの共有サブネットでネットワーク接続を得ることができます。このページでは、組織にとって必要ないくつかの管理上の準備など、共有 VPC を設定して使用する方法について説明します。
割り当て、上限、適格なリソース
開始する前に、共有 VPC の概要と IAM の概要を十分に理解しておく必要があります。特に、以下の点に注意してください。
共有 VPC に関係する割り当てと制限を把握しておきます。
共有できるリソースと共有できないリソースについて、よく理解しておきます。
ホスト プロジェクトとそれに接続するすべてのサービス プロジェクトで、Compute Engine API と課金が有効になっていることを確認します。
組織の準備
管理者と IAM
組織の準備、共有 VPC ホスト プロジェクトの設定、共有 VPC ネットワークの使用には、少なくとも 3 つの管理 Identity and Access Management(IAM)ロールが必要です。各ロールの詳細と、オプションのロールについては、共有 VPC の概要の管理者と IAM のセクションをご覧ください。
共有 VPC の組織のポリシー
組織のポリシーの制約により、共有 VPC リソースをプロジェクト、フォルダ、組織レベルで保護できます。以下では、各ポリシーについて説明します。
ホスト プロジェクトの誤削除の防止
ホスト プロジェクトを誤って削除してしまうと、それに接続されているすべてのサービス プロジェクトが停止します。共有 VPC ホスト プロジェクトになるようプロジェクトが設定されている場合は、リーエンと呼ばれる特殊なロックがプロジェクトに適用されます。リーエンが設定されていれば、プロジェクトが誤って削除されることがなくなります。リーエンは、共有 VPC から解除されると、ホスト プロジェクトから自動的に削除されます。
orgpolicy.policyAdmin
ロールを持つユーザーは、リーエンの削除を次のロールだけに制限する組織レベルのポリシー制約(constraints/compute.restrictXpnProjectLienRemoval)を定義できます。
- 組織レベルで
roles/owner
またはroles/resourcemanager.lienModifier
を持つユーザー - 組織レベルで
resourcemanager.projects.get
とresourcemanager.projects.updateLiens
権限を含むカスタムロールを持つユーザー
これにより、組織レベルの roles/owner
ロールや組織レベルの resourcemanager.lienModifier
ロールを持たないプロジェクト オーナーが、共有 VPC ホスト プロジェクトを誤って削除することを、効果的に防ぐことができます。resourcemanager.lienModifier
ロールに関連付けられている権限の詳細については、Resource Manager ドキュメントのプロジェクトにリーエンを適用するをご覧ください。
組織のポリシーは組織内のすべてのプロジェクトに適用されるため、リーエンの削除を制限するには、これらの手順を一度行うだけで済みます。
組織管理者、または
orgpolicy.policyAdmin
ロールを持つ IAM メンバーとしてgcloud
への認証を行います。ORG_ADMIN
は、組織管理者の名前に置き換えます。gcloud auth login ORG_ADMIN
次のコマンドの出力を調べて、自分の組織 ID 番号を確認します。
gcloud organizations list
次のコマンドを実行して、組織に
compute.restrictXpnProjectLienRemoval
ポリシーを適用します。ORG_ID
は、前の手順で確認した組織 ID 番号に置き換えます。gcloud beta resource-manager org-policies enable-enforce \ --organization ORG_ID compute.restrictXpnProjectLienRemoval
組織管理者としてアカウントを保護する作業が完了したら、
gcloud
からログアウトします。gcloud auth revoke ORG_ADMIN
ホスト プロジェクトの接続を制限する
デフォルトでは、共有 VPC 管理者は、同じ組織内の任意のホスト プロジェクトに非ホスト プロジェクトを接続できます。組織のポリシー管理者は、非ホスト プロジェクトを接続できるホスト プロジェクトを制限できます。また、フォルダまたは組織内の非ホスト プロジェクトを接続できるホスト プロジェクトも制限できます。詳細については、constraints/compute.restrictSharedVpcHostProjects
の制約をご覧ください。
サービス プロジェクトで使用できるホスト プロジェクトのサブネットを制限する
デフォルトでは、共有 VPC を構成した後、サービス プロジェクトの IAM メンバーは適切な IAM 権限を持つホスト プロジェクトのサブネットを使用できます。組織のポリシー管理者は、個々のユーザー権限を管理するだけでなく、ポリシーを設定して特定のプロジェクトからアクセス可能なサブネットのセットを定義できます。また、フォルダや組織内のプロジェクトからアクセス可能なサブネットのセットも定義できます。詳細については、constraints/compute.restrictSharedVpcSubnetworks
の制約をご覧ください。
共有 VPC 管理者の指名
組織管理者は、1 人以上の IAM メンバーに共有 VPC 管理者とプロジェクト IAM 管理者のロールを付与できます。プロジェクト IAM 管理者ロールは、個々のサブネットだけでなく、すべてのサブネット(今後作成されるものも含む)を共有する権限を共有 VPC 管理者に付与します。この付与により、プロジェクト レベルではなく、組織レベルまたはフォルダレベルでバインディングが作成されます。そのため、IAM メンバーはプロジェクト内だけではなく、組織で定義する必要があります。
Console
組織レベルで共有 VPC 管理者ロールを付与するには
- Google Cloud Console に組織管理者としてログインし、[IAM] ページに移動します。
[IAM] ページに移動 - プロジェクト メニューから組織を選択します。
プロジェクトを選択すると、[ロール] メニューに正しいエントリが表示されなくなります。 - [追加] をクリックします。
- [メンバー] のメールアドレスを入力します。
[ロール] のプルダウン メニューで、[Compute Engine] > [Compute Shared VPC 管理者] を選択します。
[別のロールを追加] をクリックします。
[ロール] プルダウンで、[Resource Manager] > [プロジェクト IAM 管理者] を選択します。
[保存] をクリックします。
フォルダレベルで共有 VPC 管理者ロールを付与するには
- Google Cloud Console に組織管理者としてログインし、[IAM] ページに移動します。
[IAM] ページに移動 - プロジェクト メニューからフォルダを選択します。
プロジェクトや組織を選択すると、正しいオプションが表示されなくなります。 - [メンバー] ページで、[追加] をクリックします。
- [新しいメンバー] のメールアドレスを入力します。
- [ロールを選択] で、[Compute Engine] > [Compute Shared VPC 管理者] を選択します。
- [別のロールを追加] をクリックします。
- [ロール] プルダウンで、[Resource Manager] > [プロジェクト IAM 管理者] を選択します。
- [保存] をクリックします。
gcloud
組織管理者として、
gcloud
で認証します。ORG_ADMIN
は、組織管理者の名前に置き換えます。gcloud auth login ORG_ADMIN
次のコマンドの出力を調べて、自分の組織 ID 番号を確認します。
gcloud organizations list
組織レベルで共有 VPC 管理者ロールを割り当てる場合、次の手順を実施します。
既存の IAM メンバーに共有 VPC 管理者のロールを適用します。
ORG_ID
は、前の手順で確認した組織 ID 番号に置き換え、EMAIL_ADDRESS
は、共有 VPC 管理者のロールを付与するユーザーのメールアドレスに置き換えます。gcloud organizations add-iam-policy-binding ORG_ID \ --member='user:EMAIL_ADDRESS' \ --role="roles/compute.xpnAdmin"
gcloud organizations add-iam-policy-binding ORG_ID \ --member='user:EMAIL_ADDRESS' \ --role="roles/resourcemanager.projectIamAdmin"
フォルダレベルで共有 VPC 管理者のロールを割り当てる場合の手順は次のとおりです。
このコマンドの出力を調べて、フォルダ ID を確認します。
gcloud beta resource-manager folders list --organization=ORG_ID
既存の IAM メンバーに共有 VPC 管理者のロールを適用します。
ORG_ID
は、前の手順で確認した組織 ID 番号に置き換え、EMAIL_ADDRESS
は、共有 VPC 管理者のロールを付与するユーザーのメールアドレスに置き換えます。gcloud beta resource-manager folders add-iam-policy-binding FOLDER_ID \ --member='user:EMAIL_ADDRESS' \ --role="roles/compute.xpnAdmin"
gcloud beta resource-manager folders add-iam-policy-binding FOLDER_ID \ --member='user:EMAIL_ADDRESS' \ --role="roles/resourcemanager.projectIamAdmin"
アカウントを保護するための作業が完了したら、
gcloud
コマンドライン ツールで組織管理者アカウント トークンを取り消します。gcloud auth revoke ORG_ADMIN
API
組織レベルで共有 VPC 管理者ロールを割り当てるには、次の操作を行います。
組織 ID 番号を特定します。
POST https://cloudresourcemanager.googleapis.com/v1/organizations
既存の組織のポリシーの詳細を記述し、記録します。
POST https://cloudresourcemanager.googleapis.com/v1/organizations/ORG_ID:getIamPolicy
ORG_ID
は組織の ID に置き換えます。共有 VPC 管理者ロールを割り当てます。
POST https://cloudresourcemanager.googleapis.com/v1/organizations/ORG_ID:setIamPolicy { "bindings": [ ...copy existing bindings { "members": [ "user:EMAIL_ADDRESS" ], "role": "roles/compute.xpnAdmin" }, { "members": [ "user:EMAIL_ADDRESS" ], "role": "roles/resourcemanager.projectIamAdmin" } ], "etag": "ETAG", "version": 1, ...other exisitng policy details }
プレースホルダを有効な値に置き換えます。
ORG_ID
は、共有 VPC 管理者のロールを付与するユーザーが属する組織の ID です。EMAIL_ADDRESS
はユーザーのメールアドレスです。ETAG
は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
詳細については、
organizations.setIamPolicy
メソッドをご覧ください。
フォルダレベルで共有 VPC 管理者ロールを割り当てるには、次のリクエストを使用します。
組織 ID 番号を特定します。
POST https://cloudresourcemanager.googleapis.com/v1/organizations
フォルダ ID を探します。
GET https://cloudresourcemanager.googleapis.com/v2/folders?parent=organizations/ORG_ID
ORG_ID
は組織の ID に置き換えます。既存のフォルダ ポリシーの詳細を記述して、記録します。
POST https://cloudresourcemanager.googleapis.com/v2/folders/FOLDER_ID:getIamPolicy
FOLDER_ID
は、フォルダの ID に置き換えます。共有 VPC 管理者ロールを割り当てます。
POST https://cloudresourcemanager.googleapis.com/v1/organizations/FOLDER_ID:setIamPolicy { "bindings": [ ...copy existing bindings { "members": [ "user:EMAIL_ADDRESS" ], "role": "roles/compute.xpnAdmin" }, { "members": [ "user:EMAIL_ADDRESS" ], "role": "roles/resourcemanager.projectIamAdmin" } ], "etag": "ETAG", "version": 1, ...other existing policy details }
プレースホルダを有効な値に置き換えます。
FOLDER_ID
は、共有 VPC 管理者のロールを付与するユーザーが属する組織の ID です。EMAIL_ADDRESS
はユーザーのメールアドレスです。ETAG
は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
詳細については、
folders.setIamPolicy
メソッドをご覧ください。
共有 VPC の設定
このセクションのタスクはすべて、共有 VPC 管理者が行う必要があります。
ホスト プロジェクトの有効化
共有 VPC 管理者は組織内で、割り当てと上限に従ってプロジェクトを共有 VPC ホスト プロジェクトとして指定できます。手順は以下のとおりです。組織の resourcemanager.projectCreator
と resourcemanager.projectDeleter
のロールがあれば、共有 VPC 管理者はプロジェクトの作成や削除を行うこともできます。
Console
- Google Cloud Console で [共有 VPC] ページに移動します。
[共有 VPC] ページに移動 - 共有 VPC 管理者としてログインします。
- プロジェクト選択ツールで、共有 VPC ホスト プロジェクトとして有効にするプロジェクトを選択します。
- [共有 VPC を設定] をクリックします。
- 次のページの [ホスト プロジェクトを有効にする] で、[保存して続行] をクリックします。
- [サブネットを選択する] で、次のいずれかを行います。
- ホスト プロジェクトの VPC ネットワーク内の現在と将来のすべてのサブネットを、次の手順で指定するサービス プロジェクトやサービス プロジェクト管理者と共有する必要がある場合、[すべてのサブネットを共有する(プロジェクト レベルの権限)] をクリックします。
- ホスト プロジェクトの VPC ネットワークのサブネットを、サービス プロジェクトやサービス プロジェクト管理者と選択的に共有する必要がある場合、[個々のサブネット(サブネット レベルの権限)] をクリックします。次に、[共有するサブネット] を選択します。
- [続行] をクリックします。
その次の画面が表示されます。 - [プロジェクト名] で、ホスト プロジェクトに接続するサービス プロジェクトを指定します。サービス プロジェクトを接続しても、サービス プロジェクト管理者は定義されません。これは、次の手順で行います。
- [ロール別にユーザーを選択する] セクションで、サービス プロジェクト管理者を追加します。これらのユーザーには、共有サブネットの IAM ロール
compute.networkUser
が付与されます。共有 VPC ホスト プロジェクトのサブネットでリソースを作成できるのは、サービス プロジェクト管理者のみです。 - [保存] をクリックします。
gcloud
共有 VPC 管理者として
gcloud
への認証を行います。SHARED_VPC_ADMIN
は、共有 VPC 管理者の名前に置き換えます。gcloud auth login SHARED_VPC_ADMIN
ホスト プロジェクトにする必要のあるプロジェクトに対して、共有 VPC を有効にします。
HOST_PROJECT_ID
は、プロジェクトの ID に置き換えます。組織レベルで共有 VPC 管理者の役割を持っている場合
gcloud compute shared-vpc enable HOST_PROJECT_ID
フォルダレベルで共有 VPC 管理者のロールを持っている場合
gcloud beta compute shared-vpc enable HOST_PROJECT_ID
組織のホスト プロジェクトとしてプロジェクトがリストされていることを確認します。
ORG_ID
は、組織 ID(gcloud organizations list
で確認)に置き換えます。gcloud compute shared-vpc organizations list-host-projects ORG_ID
ホスト プロジェクトを有効にするだけでよい場合は、
gcloud
からログアウトして、共有 VPC 管理者アカウントの認証情報を保護できます。それ以外の場合、この手順をスキップして、サービス プロジェクトを接続する手順に進みます。gcloud auth revoke SHARED_VPC_ADMIN
API
プロジェクトの共有 VPC を有効にするには、共有 VPC 管理者の権限を持つ認証情報を使用します。
組織レベルで共有 VPC 管理者ロールが割り当てられている場合は、v1 API を使用します。
POST https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/enableXpnHost
フォルダレベルで共有 VPC 管理者ロールが割り当てられている場合は、ベータ API を使用します。
POST https://compute.googleapis.com/compute/beta/projects/HOST_PROJECT_ID/enableXpnHost
HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトにするプロジェクトの ID に置き換えます。詳細については、
projects.enableXpnHost
メソッドをご覧ください。プロジェクトがホスト プロジェクトとして表示されていることを確認します。
POST https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/listXpnHosts
HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID に置き換えます。詳細については、
projects.listXpnHosts
メソッドをご覧ください。
サービス プロジェクトの接続
サービス プロジェクトの管理者が共有 VPC を使用するには、サービス プロジェクトがホスト プロジェクトに接続されている必要があります。共有 VPC 管理者は以下の手順に従って、接続を完了する必要があります。
サービス プロジェクトは 1 つのホスト プロジェクトにのみ接続できますが、ホスト プロジェクトは複数のサービス プロジェクトの接続をサポートしています。詳細については、VPC 割り当てページの共有 VPC に固有の上限をご覧ください。
Console
- 共有 VPC 管理者として Google Cloud Console にログインします。
- Google Cloud Console で [共有 VPC] ページに移動します。
[共有 VPC] ページに移動 - [接続されたプロジェクト] タブをクリックします。
- [接続されたプロジェクト] タブで、[プロジェクトを接続] ボタンをクリックします。
- [プロジェクト名] セクションで、接続するサービス プロジェクトのチェックボックスをオンにします。サービス プロジェクトを接続しても、サービス プロジェクト管理者は定義されません。これは、次の手順で行います。
- [VPC ネットワークの権限] セクションで、
compute.networkUser
ロールを付与するメンバーのロールを選択します。IAM メンバーには、VPC ネットワーク共有モードに基づいて、ホスト プロジェクト全体またはホスト プロジェクト内の特定のサブネットに対するネットワーク ユーザーのロールが付与されます。これらのメンバーは、それぞれのサービス プロジェクトのサービス プロジェクト管理者と呼ばれます。 - [VPC ネットワーク共有モード] セクションで、次のいずれかを選択します。
- ホスト プロジェクトの VPC ネットワーク内の現在と将来のすべてのサブネットを、すべてのサービス プロジェクトやサービス プロジェクト管理者と共有するには、[すべてのサブネットを共有する(プロジェクト レベルの権限)] をクリックします。
- ホスト プロジェクトの VPC ネットワークのサブネットを、サービス プロジェクトやサービス プロジェクト管理者と選択的に共有する必要がある場合、[個々のサブネット(サブネット レベルの権限)] をクリックします。次に、[共有するサブネット] を選択します。
- [保存] をクリックします。
gcloud
まだ共有 VPC 管理者として
gcloud
の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN
は、共有 VPC 管理者の名前に置き換えます。gcloud auth login SHARED_VPC_ADMIN
以前に有効にしたホスト プロジェクトにサービス プロジェクトを接続します。
SERVICE_PROJECT_ID
はサービス プロジェクトのプロジェクト ID に置き換え、HOST_PROJECT_ID
はホスト プロジェクトのプロジェクト ID に置き換えます。組織レベルで共有 VPC 管理者の役割を持っている場合
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID \ --host-project HOST_PROJECT_ID
フォルダレベルで共有 VPC 管理者のロールを持っている場合
gcloud beta compute shared-vpc associated-projects add SERVICE_PROJECT_ID \ --host-project HOST_PROJECT_ID
サービス プロジェクトが接続されていることを確認します。
gcloud compute shared-vpc get-host-project SERVICE_PROJECT_ID
必要に応じて、ホスト プロジェクトに接続されているサービス プロジェクトの一覧を表示できます。
gcloud compute shared-vpc list-associated-resources HOST_PROJECT_ID
サービス プロジェクトを接続するだけでよい場合、
gcloud
からログアウトして、共有 VPC 管理者アカウントの認証情報を保護できます。それ以外の場合、この手順をスキップして、すべてのサブネットまたは一部のサブネットのみに対してサービス プロジェクト管理者を定義します。gcloud auth revoke SHARED_VPC_ADMIN
API
サービス プロジェクトを共有 VPC ホスト プロジェクトに接続します。
組織レベルで共有 VPC 管理者ロールが割り当てられている場合は、v1 API を使用します。
POST https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/enableXpnResource { "xpnResource": { "id": "SERVICE_PROJECT" } }
フォルダレベルで共有 VPC 管理者ロールが割り当てられている場合は、ベータ API を使用します。
POST https://compute.googleapis.com/compute/beta/projects/HOST_PROJECT_ID/enableXpnResource { "xpnResource": { "id": "SERVICE_PROJECT" } }
プレースホルダを有効な値に置き換えます。
HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID です。SERVICE_PROJECT
は、接続するサービス プロジェクトの ID です。
詳細については、
projects.enableXpnResource
メソッドをご覧ください。サービス プロジェクトがホスト プロジェクトに接続していることを確認します。
GET https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/getXpnResources
プレースホルダを有効な値に置き換えます。
HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID です。
詳細については、
projects.getXpnResources
メソッドをご覧ください。
すべてのサブネットのサービス プロジェクト管理者
共有 VPC 管理者は、サービス プロジェクトの IAM メンバーをサービス プロジェクト管理者に割り当て、ホスト プロジェクト内のすべてのサブネットへのアクセスを許可できます。この種のサービス プロジェクト管理者には、ホスト プロジェクト全体に対する compute.networkUser
のロールが付与されます。つまり、現在ホスト プロジェクトに定義されているサブネットだけでなく、今後作成されるサブネットにもアクセスできます。
Console
Cloud Console で、サービス プロジェクトの IAM メンバーをサービス プロジェクト管理者として定義し、ホスト プロジェクトのすべてのサブネットにアクセスできるようにするには、サービス プロジェクトの接続セクションをご覧ください。
gcloud
この手順には、ホスト プロジェクト内のすべてのサブネットに対するアクセス権を持つサービス プロジェクト管理者としてサービス プロジェクトから IAM メンバーを定義する方法が含まれています。この手順を行うには、事前にホスト プロジェクトを有効にして、ホスト プロジェクトにサービス プロジェクトを接続しておく必要があります。
まだ共有 VPC 管理者として
gcloud
の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN
は、共有 VPC 管理者の名前に置き換えます。gcloud auth login SHARED_VPC_ADMIN
サービス プロジェクト内の IAM メンバーをサービス プロジェクト管理者にするポリシー バインディングを作成します。
HOST_PROJECT_ID
は、ホスト プロジェクトのプロジェクト ID に置き換え、SERVICE_PROJECT_ADMIN
は、サービス プロジェクト管理者になるユーザーのメールアドレスに置き換えます。gcloud projects add-iam-policy-binding HOST_PROJECT_ID \ --member "user:SERVICE_PROJECT_ADMIN" \ --role "roles/compute.networkUser"
次のように
--member
引数の形式を変更することで、さまざまな種類のメンバーを指定できます。group:
を使用して、Google グループをメンバーとして指定します(メールアドレスを使用)。domain:
を使用して、Google ドメインをメンバーとして指定します。serviceAccount:
を使用してサービス アカウントを指定します。このユースケースの詳細については、サービス プロジェクト管理者としてのサービス アカウントをご覧ください。
定義する必要のある他の各サービス プロジェクト管理者に対して、前の手順を繰り返します。
サービス プロジェクト管理者の定義が完了している場合は、
gcloud
からログアウトして、共有 VPC 管理者アカウントの認証情報を保護できます。gcloud auth revoke SHARED_VPC_ADMIN
API
既存のプロジェクト ポリシーの詳細を記述し、記録します。既存のポリシーと
etag
値が必要です。POST https://cloudresourcemanager.googleapis.com/v2/projects/HOST_PROJECT_ID:getIamPolicy
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID に置き換えます。サービス プロジェクトの IAM メンバーをサービス プロジェクト管理者に指定するポリシー バインディングを作成します。
POST https://cloudresourcemanager.googleapis.com/v1/projects/HOST_PROJECT_ID:setIamPolicy { "bindings": [ ...copy existing bindings { "members": [ MEMBER, ...additional members ], "role": "roles/compute.networkUser" }, ], "etag": "ETAG", "version": 1, ...other existing policy details }
プレースホルダを有効な値に置き換えます。
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID です。MEMBER
は、ユーザー、グループ、ドメイン、サービス アカウントなどのロールが関連付けられている ID です。詳細については、Resource Manager のドキュメントでmembers
フィールドの説明をご覧ください。ETAG
は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
詳細については、
projects.setIamPolicy
メソッドをご覧ください。
一部のサブネットのサービス プロジェクト管理者
共有 VPC 管理者は、サービス プロジェクトの IAM メンバーをサービス プロジェクト管理者に割り当て、ホスト プロジェクトの一部のサブネットのみにアクセスを許可できます。このオプションを使用すると、ホスト プロジェクト内の一部のサブネットのみに対する compute.networkUser
ロールをサービス プロジェクト管理者に付与することで、管理者をさらに詳細に定義できます。
Console
Cloud Console で、サービス プロジェクトの IAM メンバーをサービス プロジェクト管理者として定義し、ホスト プロジェクトの一部のサブネットにのみアクセスできるようにするには、サービス プロジェクトの接続をご覧ください。
gcloud
この手順には、ホスト プロジェクト内の一部のサブネットのみに対するアクセス権を持つサービス プロジェクト管理者としてサービス プロジェクトから IAM メンバーを定義する方法が含まれています。管理者を定義するには、事前にホスト プロジェクトを有効にして、ホスト プロジェクトにサービス プロジェクトを接続しておく必要があります。
まだ共有 VPC 管理者として
gcloud
の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN
は、共有 VPC 管理者の名前に置き換えます。gcloud auth login SHARED_VPC_ADMIN
サービス プロジェクト管理者がアクセスする必要のあるホスト プロジェクト内のサブネットを選択します。現在の IAM ポリシーを JSON 形式で取得します。
SUBNET_NAME
は、ホスト プロジェクト内のサブネットの名前に置き換え、HOST_PROJECT_ID
は、ホスト プロジェクトのプロジェクト ID に置き換えます。gcloud beta compute networks subnets get-iam-policy SUBNET_NAME \ --region SUBNET_REGION \ --project HOST_PROJECT_ID \ --format json
前の手順で得た JSON 出力をコピーし、任意のファイルに保存します。わかりやすくするため、ここでは
subnet-policy.json
という名前のファイルに出力を保存します。subnet-policy.json
ファイルを変更します。サービス プロジェクト管理者にし、サブネットへのアクセスを許可する IAM メンバーを追加します。各SERVICE_PROJECT_ADMIN
は、サービス プロジェクトの IAM ユーザーのメールアドレスに置き換えます。{ "bindings": [ { "members": [ "user:[SERVICE_PROJECT_ADMIN]", "user:[SERVICE_PROJECT_ADMIN]" ], "role": "roles/compute.networkUser" } ], "etag": "[ETAG_STRING]" }
次のようにして、ポリシーには、さまざまな種類の IAM メンバー(ユーザー以外)を指定できます。
user:
をgroup:
に変更して、Google グループをメンバーとして指定します(メールアドレスを使用)。user:
をdomain:
に変更して、Google ドメインをメンバーとして指定します。serviceAccount:
を使用してサービス アカウントを指定します。このユースケースの詳細については、サービス プロジェクト管理者としてのサービス アカウントをご覧ください。
subnet-policy.json
ファイルの内容を使用して、サブネットのポリシー バインディングを更新します。gcloud beta compute networks subnets set-iam-policy SUBNET_NAME subnet-policy.json \ --region SUBNET_REGION \ --project HOST_PROJECT_ID
サービス プロジェクト管理者の定義が完了している場合は、
gcloud
からログアウトして、共有 VPC 管理者アカウントの認証情報を保護できます。gcloud auth revoke SHARED_VPC_ADMIN
API
既存のサブネット ポリシーの詳細を記述し、記録します。既存のポリシーと
etag
値が必要です。GET https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/regions/SUBNET_REGION/subnetworks/SUBNET_NAME/getIamPolicy
プレースホルダを有効な値に置き換えます。
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID です。SUBNET_NAME
は、共有するサブネットの名前です。SUBNET_REGION
は、サブネットが配置されているリージョンです。
サブネット ポリシーを更新して、ホスト プロジェクトのサブネットに対するアクセス権をサービス プロジェクト管理者に付与します。
POST https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/regions/SUBNET_REGION/subnetworks/SUBNET_NAME/setIamPolicy { "bindings": [ ...copy existing bindings { "members": [ MEMBER, ...additional members ], "role": "roles/compute.networkUser" }, ], "etag": "ETAG", "version": 1, ...other existing policy details }
プレースホルダを有効な値に置き換えます。
ETAG
は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID です。MEMBER
は、ユーザー、グループ、ドメイン、サービス アカウントなどのロールが関連付けられている ID です。詳細については、Resource Manager のドキュメントでmembers
フィールドの説明をご覧ください。SUBNET_NAME
は、共有するサブネットの名前です。SUBNET_REGION
は、サブネットが配置されているリージョンです。
詳細については、
subnetworks.setIamPolicy
メソッドをご覧ください。
サービス プロジェクト管理者としてのサービス アカウント
共有 VPC 管理者は、サービス プロジェクト管理者として、サービス プロジェクトからサービス アカウントを定義することもできます。このセクションでは、サービス プロジェクト管理者として 2 種類のサービス アカウントを定義する方法を説明します。
次の形式のユーザー管理サービス アカウント:
USER_ID
@SERVICE_PROJECT_ID
.iam.gserviceaccount.com次の形式の Google API サービス アカウント:
SERVICE_PROJECT_NUMBER
@cloudservices.gserviceaccount.com
他の IAM メンバーと同様に、サービス プロジェクト管理者(compute.networkUser
)のロールは、ホスト プロジェクトのすべてのサブネットまたは一部のサブネットのみに付与できます。ただし、このセクションではわかりやすくするために、ホスト プロジェクトのすべてのサブネットに対するサービス プロジェクト管理者として、2 種類のサービス アカウントをそれぞれ定義する方法を説明します。
サービス プロジェクト管理者としてのユーザー管理サービス アカウント
ここでは、共有 VPC ホスト プロジェクトのすべてのサブネットに対するサービス プロジェクト管理者としてユーザー管理サービス アカウントを定義する方法について説明します。
Console
- 共有 VPC 管理者として Google Cloud Console にログインします。
- Google Cloud Console で [設定] ページに移動します。
[設定] ページに移動 - プロジェクトを、サービス プロジェクト管理者として定義する必要のあるサービス アカウントを含むサービス プロジェクトに変更します。
- サービス プロジェクトのプロジェクト ID をコピーします。説明をわかりやすくするため、この手順ではサービス プロジェクト ID を
SERVICE_PROJECT_ID
と示しています。 - プロジェクトを共有 VPC ホスト プロジェクトに変更します。
- Google Cloud Console で [IAM] ページに移動します。
[IAM] ページに移動 - [追加] をクリックします。
- [メンバー] フィールドに
SERVICE_ACCOUNT_NAME
@SERVICE_PROJECT_ID
.iam.gserviceaccount.com を追加します。SERVICE_ACCOUNT_NAME
は、サービス アカウントの名前に置き換えます。 - [ロール] メニューから、[Compute Engine] > [Compute ネットワーク ユーザー] を選択します。
- [追加] をクリックします。
gcloud
まだ共有 VPC 管理者として
gcloud
の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN
は、共有 VPC 管理者の名前に置き換えます。gcloud auth login SHARED_VPC_ADMIN
サービス プロジェクトのプロジェクト ID が不明な場合、組織内のすべてのプロジェクトを一覧表示すると確認できます。この一覧には、それぞれのプロジェクト ID が示されています。
gcloud projects list
サービス アカウントをサービス プロジェクト管理者にするポリシー バインディングを作成します。
HOST_PROJECT_ID
は、ホスト プロジェクトのプロジェクト ID に置き換え、SERVICE_ACCOUNT_NAME
は、サービス アカウントの名前に置き換え、SERVICE_PROJECT_ID
は、サービス プロジェクト ID に置き換えます。gcloud projects add-iam-policy-binding HOST_PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_NAME@SERVICE_PROJECT_ID.iam.gserviceaccount.com" \ --role "roles/compute.networkUser"
API
既存のプロジェクト ポリシーの詳細を記述し、記録します。既存のポリシーと
etag
値が必要です。POST https://cloudresourcemanager.googleapis.com/v2/projects/HOST_PROJECT_ID:getIamPolicy
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID に置き換えます。サービス アカウントをサービス プロジェクト管理者として指定するポリシー バインディングを作成します。
POST https://cloudresourcemanager.googleapis.com/v1/projects/HOST_PROJECT_ID:setIamPolicy { "bindings": [ ...copy existing bindings { "members": [ "serviceAccount:SERVICE_ACCOUNT_NAME@SERVICE_PROJECT_ID.iam.gserviceaccount.com", ...include additional service accounts ], "role": "roles/compute.networkUser" }, ], "etag": "ETAG", "version": 1, ...other existing policy details }
プレースホルダを有効な値に置き換えます。
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID です。SERVICE_ACCOUNT_NAME
はサービス アカウントの名前です。SERVICE_PROJECT_ID
は、サービス アカウントを含むサービス プロジェクトの ID です。ETAG
は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
詳細については、
projects.setIamPolicy
メソッドをご覧ください。
サービス プロジェクト管理者としての Google API サービス アカウント
ここでは、共有 VPC ホスト プロジェクトのすべてのサブネットに対するサービス プロジェクト管理者として、Google API サービス アカウントを定義する方法を説明します。共有 VPC で使用されるマネージド インスタンス グループに対して、Google API サービス アカウントをサービス プロジェクト管理者にする必要があります。インスタンスの作成のようなタスクは、この種のサービス アカウントによって実行されるからです。この関係の詳細については、マネージド インスタンス グループと IAM をご覧ください。
Console
- 共有 VPC 管理者として Google Cloud Console にログインします。
- Google Cloud Console で [設定] ページに移動します。
[設定] ページに移動 - プロジェクトを、サービス プロジェクト管理者として定義する必要のあるサービス アカウントを含むサービス プロジェクトに変更します。
- サービス プロジェクトの [プロジェクト番号] をコピーします。説明をわかりやすくするため、この手順ではサービス プロジェクト番号を
SERVICE_PROJECT_NUMBER
と示しています。 - プロジェクトを共有 VPC ホスト プロジェクトに変更します。
- Google Cloud Console で [IAM] ページに移動します。
[IAM] ページに移動 - [追加] をクリックします。
SERVICE_PROJECT_NUMBER
@cloudservices.gserviceaccount.com を [メンバー] フィールドに追加します。- [ロール] メニューから、[Compute Engine] > [Compute ネットワーク ユーザー] を選択します。
- [追加] をクリックします。
gcloud
まだ共有 VPC 管理者として
gcloud
の認証を行っていない場合は、認証を行います。SHARED_VPC_ADMIN
は、共有 VPC 管理者の名前に置き換えます。gcloud auth login SHARED_VPC_ADMIN
サービス プロジェクトのプロジェクト番号を確認します。説明をわかりやすくするため、この手順ではサービス プロジェクト番号を
SERVICE_PROJECT_NUMBER
と示しています。SERVICE_PROJECT_ID
は、サービス プロジェクトのプロジェクト ID に置き換えます。gcloud projects describe SERVICE_PROJECT_ID --format='get(projectNumber)'
サービス プロジェクトのプロジェクト ID が不明な場合、組織内のすべてのプロジェクトを一覧表示すると確認できます。このリストには、それぞれのプロジェクト番号が示されています。
gcloud projects list
サービス アカウントをサービス プロジェクト管理者にするポリシー バインディングを作成します。
HOST_PROJECT_ID
は、ホスト プロジェクトのプロジェクト ID に置き換え、SERVICE_PROJECT_NUMBER
は、サービス プロジェクト番号に置き換えます。gcloud projects add-iam-policy-binding HOST_PROJECT_ID \ --member "serviceAccount:SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com" \ --role "roles/compute.networkUser"
API
既存のプロジェクト ポリシーの詳細を記述し、記録します。既存のポリシーと
etag
値が必要です。POST https://cloudresourcemanager.googleapis.com/v2/projects/HOST_PROJECT_ID:getIamPolicy
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID に置き換えます。プロジェクトのリストを取得して、プロジェクト番号を探します。
GET https://cloudresourcemanager.googleapis.com/v1/projects?filter=projectId="SERVICE_PROJECT_ID"
SERVICE_PROJECT_ID
は、サービス アカウントが配置されているサービス プロジェクトの ID に置き換えます。サービス アカウントをサービス プロジェクト管理者として指定するポリシー バインディングを作成します。
POST https://cloudresourcemanager.googleapis.com/v1/projects/HOST_PROJECT_ID:setIamPolicy { "bindings": [ ...copy existing bindings { "members": [ "serviceAccount:SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com" ], "role": "roles/compute.networkUser" }, ], "etag": "ETAG", "version": 1, ...other existing policy details }
プレースホルダを有効な値に置き換えます。
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID です。SERVICE_PROJECT_NUMBER
は、サービス アカウントを含むサービス プロジェクトの番号です。ETAG
は、既存のポリシーを記述するときに取得した固有の ID です。これにより、複数の更新リクエストが同時に送信された場合の競合を回避します。
詳細については、
projects.setIamPolicy
メソッドをご覧ください。
共有 VPC の使用
共有 VPC 管理者がホスト プロジェクトの有効化、それに対する必要なサービス プロジェクトの接続、ホスト プロジェクト サブネットのすべてまたは一部に対するサービス プロジェクト管理者の定義という各タスクを完了すると、サービス プロジェクト管理者がホスト プロジェクトのサブネットを使用して、サービス プロジェクト内にインスタンス、テンプレート、内部ロードバランサを作成できるようになります。
このセクションのすべてのタスクは、サービス プロジェクト管理者が行う必要があります。
共有 VPC 管理者がサービス プロジェクト管理者に付与できるのは、ホスト プロジェクト全体または一部のサブネットのみに対する compute.networkUser
ロールのみです。サービス プロジェクト管理者は、各サービス プロジェクトを管理するために必要なその他のロールも持つ必要があります。たとえば、サービス プロジェクト管理者をプロジェクト オーナーにすることも、プロジェクトに対して少なくとも compute.instanceAdmin
ロールを持つようにすることもできます。
使用可能なサブネットの一覧表示
サービス プロジェクト管理者は、次の手順に従って、自分に権限が付与されているサブネットを一覧表示できます。
Console
Google Cloud Console で [共有 VPC] ページに移動します。
[共有 VPC] ページに移動
gcloud
まだサービス プロジェクト管理者として
gcloud
の認証を行っていない場合は、認証を行います。SERVICE_PROJECT_ADMIN
は、サービス プロジェクト管理者の名前に置き換えます。gcloud auth login SERVICE_PROJECT_ADMIN
次のコマンドを実行します。
HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトのプロジェクト ID に置き換えます。gcloud compute networks subnets list-usable --project HOST_PROJECT_ID
次の例では、
project-1
ホスト プロジェクトで使用可能なサブネットの一覧を取得します。$ gcloud compute networks subnets list-usable --project project-1 PROJECT REGION NETWORK SUBNET RANGE SECONDARY_RANGES project-1 us-west1 net-1 subnet-1 10.138.0.0/20 project-1 us-central1 net-1 subnet-2 10.128.0.0/20 r-1 192.168.2.0/24 r-2 192.168.3.0/24 project-1 us-east1 net-1 subnet-3 10.142.0.0/20
詳細については、SDK のドキュメントの list-usage コマンドをご覧ください。
API
ホスト プロジェクトで使用可能なサブネットを一覧で表示します。サービス プロジェクト管理者としてリクエストを行います。
GET https://compute.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/aggregated/subnetworks/listUsable
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むホスト プロジェクトの ID に置き換えます。
詳細については、subnetworks.listUsable
メソッドをご覧ください。
静的内部 IP アドレスの予約
サービス プロジェクト管理者は、共有 VPC ネットワークのサブネットに内部 IP アドレスを予約できます。IP アドレス構成オブジェクトはサービス プロジェクト内で作成されますが、その値は選択した共有サブネットで使用可能なアドレス範囲から取得されます。
gcloud
まだサービス プロジェクト管理者として
gcloud
の認証を行っていない場合は、認証を行います。SERVICE_PROJECT_ADMIN
は、サービス プロジェクト管理者の名前に置き換えます。gcloud auth login SERVICE_PROJECT_ADMIN
次のコマンドを実行します。
HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトのプロジェクト ID に置き換えます。gcloud compute addresses create IP_ADDR_NAME \ --project SERVICE_PROJECT_ID \ --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \ --region=REGION
次のように置き換えます。
IP_ADDR_NAME
は、IP アドレス オブジェクトの名前に置き換えます。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID に置き換えます。HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID に置き換えます。REGION
は、共有サブネットが含まれているリージョンに置き換えます。SUBNET
は、共有サブネットの名前に置き換えます。
IP アドレスの作成の詳細は、SDK のドキュメントに記載されています。
API
サービス プロジェクト管理者として静的内部 IP アドレスを予約します。
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/regions/REGION/addresses { "name": "ADDRESS_NAME", "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME", "addressType": "INTERNAL" }
プレースホルダを有効な値に置き換えます。
ADDRESS_NAME
は予約済み内部 IP アドレスの名前です。HOST_PROJECT_ID
は、共有 VPC ネットワークを含むプロジェクトの ID です。REGION
は、予約済み IP アドレスを配置するリージョンと、共有サブネットが存在するリージョンです。SERVICE_PROJECT_ID
は、IP アドレスを予約するサービス プロジェクトの ID です。SUBNET_NAME
は共有サブネットの名前です。
詳細については、addresses.insert
メソッドをご覧ください。
インスタンスの作成
共有 VPC を使用してインスタンスを作成するときは、次の点に注意してください。
インスタンスを作成する標準的なプロセスには、ゾーン、ネットワーク、サブネットの選択が含まれます。選択したサブネットと選択したゾーンの両方が同じリージョン内に存在する必要があります。サービス プロジェクト管理者が共有 VPC ネットワークのサブネットを使用してインスタンスを作成する場合、そのインスタンス用に選択されたゾーンは、選択したサブネットと同じリージョン内に存在する必要があります。
- 予約された静的内部 IP アドレスを持つインスタンスを作成する場合、その静的 IP アドレスが作成された時点で、サブネット(およびリージョン)は選択済みとなっています。ここでは、静的内部 IP アドレスを持つインスタンスを作成する
gcloud
の例について説明します。
- 予約された静的内部 IP アドレスを持つインスタンスを作成する場合、その静的 IP アドレスが作成された時点で、サブネット(およびリージョン)は選択済みとなっています。ここでは、静的内部 IP アドレスを持つインスタンスを作成する
サービス プロジェクト管理者は、権限が付与されているサブネットを使用する場合に限り、インスタンスを作成できます。使用可能なサブネットを確認するには、使用可能なサブネットの一覧表示をご覧ください。
Google Cloud は、共有 VPC ネットワークのサブネットにインスタンスを作成するリクエストを受信すると、リクエストを送信した IAM メンバーがその共有サブネットを使用する権限を持っているかどうかを確認します。チェックが失敗した場合、インスタンスは作成されず、Google Cloud は権限エラーを返します。共有 VPC 管理者に連絡してください。
Console
- Google Cloud Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動 - [作成] をクリックします。
- インスタンスの名前を指定します。
- [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックします。
- [ネットワーキング] をクリックします。
- [ネットワーク インターフェース] で
default
ネットワークをクリックします。 - [共有ネットワーク] ラジオボタンをクリックします。
- インスタンスを作成する共有サブネットを選択します。
- インスタンスに必要な他のパラメータを指定します。
- [作成] をクリックします。
gcloud
共有 VPC ネットワークの共有サブネット内にある内部エフェメラル IP アドレスでインスタンスを作成するには、次のようにします。
gcloud compute instances create INSTANCE_NAME \ --project SERVICE_PROJECT_ID \ --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \ --zone ZONE
次のように置き換えます。
INSTANCE_NAME
は、インスタンスの名前に置き換えます。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID に置き換えます。HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID に置き換えます。REGION
は、共有サブネットが含まれているリージョンに置き換えます。SUBNET
は、共有サブネットの名前に置き換えます。ZONE
は、指定されたリージョン内のゾーンに置き換えます。
共有 VPC ネットワーク内の予約済み静的内部 IP アドレスを使用してインスタンスを作成するには、次のようにします。
- ホスト プロジェクトで静的内部 IP アドレスを予約します。
インスタンスを作成します。
gcloud compute instances create INSTANCE_NAME \ --project SERVICE_PROJECT_ID \ --private-network-ip IP_ADDR_NAME \ --zone ZONE --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET
次のように置き換えます。
INSTANCE_NAME
は、インスタンスの名前に置き換えます。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID に置き換えます。HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID に置き換えます。IP_ADDR_NAME
は、静的 IP アドレスの名前に置き換えます。ZONE
は、IP_ADDR_NAME
と同じリージョン内のゾーンに置き換えます。SUBNET
は、静的内部 IP アドレスに関連付けられている共有サブネットの名前に置き換えます。
API
サービス プロジェクト管理者としてエフェメラル内部 IP アドレスを持つインスタンスを作成する場合は、サブネットのみを指定します。
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/zones/ZONE/instances { "machineType": "MACHINE_TYPE", "name": "INSTANCE_NAME", "networkInterfaces": [ { "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME" } ], "disks": [ { "boot": true, "initializeParams": { "sourceImage": "SOURCE_IMAGE" } } ] }
プレースホルダを有効な値に置き換えます。
INSTANCE_NAME
はインスタンス名です。HOST_PROJECT_ID
は、共有 VPC ネットワークを含むプロジェクトの ID です。MACHINE_TYPE
はインスタンスのマシンタイプです。REGION
は、共有サブネットを含むリージョンです。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID です。SOURCE_IMAGE
は、インスタンスのイメージです。SUBNET
は共有サブネットの名前です。ZONE
は、指定されたリージョンのゾーンです。
詳細については、
instances.insert
メソッドをご覧ください。サービス プロジェクト管理者として予約済みの内部 IP アドレスを持つインスタンスを作成する場合は、サブネットと予約済み IP アドレスの名前を指定します。
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/zones/ZONE/instances { "machineType": "MACHINE_TYPE", "name": "INSTANCE_NAME", "networkInterfaces": [ { "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME", "networkIP": "projects/SERVICE_PROJECT_ID/regions/REGION/addresses/ADDRESS_NAME" } ], "disks": [ { "boot": true, "initializeParams": { "sourceImage": "SOURCE_IMAGE" } } ] }
プレースホルダを有効な値に置き換えます。
ADDRESS_NAME
は予約済み内部 IP アドレスの名前です。INSTANCE_NAME
はインスタンス名です。HOST_PROJECT_ID
は、共有 VPC ネットワークを含むプロジェクトの ID です。MACHINE_TYPE
はインスタンスのマシンタイプです。REGION
は、共有サブネットを含むリージョンです。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID です。SOURCE_IMAGE
は、インスタンスのイメージです。SUBNET
は共有サブネットの名前です。ZONE
は、指定されたリージョンのゾーンです。
詳細については、
instances.insert
メソッドをご覧ください。
インスタンス テンプレートの作成
共有 VPC を使用してインスタンス テンプレートを作成する場合は、次の点に注意してください。
インスタンス テンプレートを作成するプロセスには、ネットワークとサブネットの選択が含まれます。
カスタムモードの共有 VPC ネットワークで使用するために作成されたテンプレートで、ネットワークとサブネットの両方を指定する必要があります。
自動モードの共有 VPC ネットワークで使用するために作成されたテンプレートでは、後でサブネットを選択することもできます。このような場合、サブネットは、テンプレートを使用するいずれかのマネージド インスタンス グループと同じリージョンで自動的に選択されます(定義上、自動モードのネットワークはリージョンごとにサブネットを 1 つずつ持ちます)。
IAM メンバーがインスタンス テンプレートを作成したときに、Google Cloud は、メンバーが指定されたサブネットを使用できるかどうかを確認する権限チェックを実行しません。この権限チェックは、テンプレートを使用しているマネージド インスタンス グループが要求されるときまで、必ず延期されます。
Console
- Google Cloud Console で [インスタンス テンプレート] ページに移動します。
[インスタンス テンプレート] ページに移動 - [インスタンス テンプレートを作成] をクリックします。
- インスタンス テンプレートの名前を指定します。
- [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックします。
- [ネットワーキング] をクリックします。
- [ネットワーク インターフェース] で
default
ネットワークをクリックします。 - [共有ネットワーク] ラジオボタンをクリックします。
- インスタンス テンプレートを作成する共有サブネットを選択します。
- インスタンス テンプレートに必要な他のパラメータを指定します。
- [作成] をクリックします。
gcloud
自動モードの共有 VPC ネットワークの自動的に作成されたサブネットで使用するようにインスタンス テンプレートを作成するには、次のようにします。
gcloud compute instance-templates create TEMPLATE_NAME \ --project SERVICE_PROJECT_ID \ --network projects/HOST_PROJECT_ID/global/networks/NETWORK
次のように置き換えます。
TEMPLATE_NAME
は、テンプレートの名前に置き換えます。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID に置き換えます。HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID に置き換えます。NETWORK
は、共有 VPC ネットワークの名前に置き換えます。
共有 VPC ネットワーク(自動モードまたはカスタムモードのいずれか)で、手動で作成されたサブネット用にインスタンス テンプレートを作成するには、次のようにします。
gcloud compute instance-templates create TEMPLATE_NAME \ --project SERVICE_PROJECT_ID \ --region REGION \ --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET
次のように置き換えます。
TEMPLATE_NAME
は、テンプレートの名前に置き換えます。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID に置き換えます。HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID に置き換えます。REGION
は、共有サブネットが含まれているリージョンに置き換えます。SUBNET
は、共有サブネットの名前に置き換えます。
API
自動モードの共有 VPC ネットワークで自動生成のサブネットを使用するインスタンス テンプレートを作成するには、VPC ネットワークを指定します。
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/global/instanceTemplates { "properties": { "networkInterfaces": [ { "network": "projects/HOST_PROJECT_ID/global/networks/NETWORK" } ] ... }
プレースホルダを有効な値に置き換えます。
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むプロジェクトの ID です。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID です。NETWORK
は、共有 VPC ネットワークの名前です。
詳細については、
instanceTemplates.insert
メソッドをご覧ください。共有 VPC ネットワーク(自動モードまたはカスタムモード)で手動で作成したサブネットを使用するインスタンス テンプレートを作成するには、サブネットを指定します。
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/global/instanceTemplates { "properties": { "networkInterfaces": [ { "subnetwork": "projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME" } ] ... }
プレースホルダを有効な値に置き換えます。
HOST_PROJECT_ID
は、共有 VPC ネットワークを含むプロジェクトの ID です。REGION
は、共有サブネットを含むリージョンです。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID です。SUBNET_NAME
は共有サブネットの名前です。
詳細については、
instanceTemplates.insert
メソッドをご覧ください。
マネージド インスタンス グループの作成
共有 VPC を使用してマネージド インスタンス グループを作成するときは、次の点に注意してください。
共有 VPC で使用されるマネージド インスタンス グループでは、Google API サービス アカウントをサービス プロジェクト管理者にする必要があります。これは、自動スケーリングを使用した自動インスタンス作成のようなタスクが、そのサービス アカウントによって行われるためです。
マネージド インスタンス グループを作成する標準的なプロセスには、グループの種類とインスタンス テンプレートに応じた、ゾーンやリージョンの選択が含まれます(ネットワークとサブネットの詳細は、インスタンス テンプレートに関連付けられています)。適格なインスタンス テンプレートは、マネージド インスタンス グループによって使用されているリージョンと同じリージョン内のサブネットを参照しているテンプレートに限定されます。
サービス プロジェクト管理者が作成できるのは、権限が付与されているサブネットをメンバー インスタンスが使用するマネージド インスタンス グループのみです。ネットワークとサブネットの詳細はインスタンス テンプレートに関連付けられているため、サービス プロジェクト管理者が使用できるのは、使用が許可されているサブネットを参照しているテンプレートのみです。
Google Cloud は、マネージド インスタンス グループの作成リクエストを受信すると、リクエストを送信した IAM メンバーがインスタンス テンプレートで指定されたサブネット(グループと同じリージョン)で使用する権限を持っているかどうかを確認します。チェックが失敗した場合、マネージド インスタンス グループは作成されず、Google Cloud は権限エラーを返します。使用可能なサブネットを一覧表示して、使用できるのはどれかを確認し、共有 VPC 管理者に連絡してください。
詳細については、Compute Engine のドキュメントでマネージド インスタンスのグループを作成するをご覧ください。
内部 HTTP(S) ロードバランサの作成
共有 VPC ネットワーク内で内部 HTTP(S) 負荷分散を構成するには、次の 2 つの方法があります。ロードバランサとそのバックエンド インスタンスは、サービス プロジェクト内、ホスト プロジェクト内のいずれでも作成できます。ネットワーク管理者とサービス開発者の責任を明確に分離できるため、サービス プロジェクトにロードバランサを作成することをおすすめします。ネットワーク管理者は、内部 IP 空間を安全かつ効率的に割り当てることができます。一方、サービス開発者は、サービス プロジェクトのニーズに基づいて負荷分散リソースをデプロイして更新できます。
サービス プロジェクト管理者は、サービス プロジェクトで内部 HTTP(S) ロードバランサを作成する前に、ホスト プロジェクトで管理者の以下の操作を行う必要があります。
- 内部 HTTP(S) ロードバランサ用に予約されたプロキシ専用サブネットを作成します。サービス プロジェクト管理者が内部 HTTP(S) ロードバランサを作成する予定の共有 VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。
- ロードバランサのフロントエンドとバックエンドのサブネットを作成します。新しいサービス プロジェクトを共有 VPC ネットワークにオンボーディングするたびに、この手順を繰り返す必要があります。たとえば、各サービス プロジェクトに独自のサブネットが必要な場合は、各サービス プロジェクトに別々のサブネットを割り当てます。これにより、異なるチームがそれぞれ独自のサービス プロジェクトで作業し、互いに独立して作業できるようになります。
- サービス プロジェクト管理者またはデベロッパーに、これらのサブネットへのアクセスを許可します。サービス プロジェクト メンバーは、ホスト プロジェクト管理者を介さずに、これらのサブネットの負荷分散リソースとバックエンドをデプロイおよび更新できる必要があります。
- 内部 HTTP(S) ロードバランサに必要なグローバル ファイアウォール ルールを作成します。
内部 HTTP(S) ロードバランサに必要なネットワーク リソースをプロビジョニングする手順については、共有 VPC を使用した内部 HTTP(S) 負荷分散の設定をご覧ください。
内部 TCP / UDP ロードバランサの作成
次の例では、共有 VPC ネットワークで内部 TCP / UDP ロードバランサを作成する際の考慮事項について説明します。サービス プロジェクト管理者は、ホスト プロジェクトでアクセス権のあるサブネットを使用する内部 TCP / UDP ロードバランサを作成できます。ロードバランサの内部転送ルールはサービス プロジェクトで定義されますが、サブネット参照はホスト プロジェクトの共有 VPC ネットワーク内のサブネットを参照します。
共有 VPC 環境で内部 TCP / UDP ロードバランサを作成する前に、次のドキュメントを確認してください。
Console
Google Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動内部 TCP / UDP ロードバランサを作成して、次の調整を行います。[フロントエンド サービスの構成] セクションに移動し、[サブネット] メニューの [他のプロジェクトで共有されるネットワーク] セクションから必要な共有 VPC サブネットを選択します。
ロードバランサの作成を完了します。
gcloud
内部転送ルールを作成する場合は、--subnet
フラグを使用してホスト プロジェクトのサブネットを指定します。
gcloud compute forwarding-rules create FR_NAME \ --project SERVICE_PROJECT_ID \ --load-balancing-scheme internal \ --region REGION \ --ip-protocol IP_PROTOCOL \ --ports PORT,PORT,... \ --backend-service BACKEND_SERVICE_NAME \ --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \ --address INTERNAL_IP
次のように置き換えます。
FR_NAME
は、転送ルールの名前に置き換えます。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID に置き換えます。REGION
は、共有サブネットが含まれているリージョンに置き換えます。IP_PROTOCOL
は、ロードバランサのバックエンド サービスのプロトコルに合わせてTCP
またはUDP
のいずれかに置き換えます。PORT
は、ロードバランサの数値ポートまたはポートのリストに置き換えます。BACKEND_SERVICE_NAME
は、バックエンド サービスの名前(内部 TCP / UDP ロードバランサの作成の一般的な手順で作成済み)に置き換えます。HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID に置き換えます。SUBNET
は、共有サブネットの名前に置き換えます。INTERNAL_IP
は、共有サブネット内の内部 IP アドレス(指定しなかった場合、使用可能なアドレスが選択されます)に置き換えます。
gcloud compute forwarding-rules create
で使用可能なオプションの詳細については、こちらのページをご覧ください。
API
内部転送ルールを作成し、ホスト プロジェクトのサブネットを指定します。
POST https://compute.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/regions/REGION/forwardingRules { "name": "FR_NAME", "IPAddress": "IP_ADDRESS", "IPProtocol": "PROTOCOL", "ports": [ "PORT", ... ], "loadBalancingScheme": "INTERNAL", "subnetwork": "https://www.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET", "network": "https://www.googleapis.com/compute/v1/projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME", "backendService": "https://www.googleapis.com/compute/v1/projects/SERVICE_PROJECT_ID/regions/us-west1/backendServices/BE_NAME", "networkTier": "PREMIUM" }
プレースホルダを有効な値に置き換えます。
BE_NAME
は、バックエンド サービスの名前(内部 TCP / UDP ロードバランサの作成の一般的な手順で作成済み)です。FR_NAME
は転送ルールの名前です。HOST_PROJECT_ID
は、共有 VPC ホスト プロジェクトの ID です。IP_ADDRESS
は、共有サブネットの内部 IP アドレスです。IP_PROTOCOL
は、ロードバランサのバックエンド サービスのプロトコルに合わせてTCP
またはUDP
のいずれかです。PORT
は、ロードバランサの数値ポートまたはポートのリストです。REGION
は、共有サブネットを含むリージョンです。SERVICE_PROJECT_ID
は、サービス プロジェクトの ID です。SUBNET
は共有サブネットの名前です。
詳細については、forwardingRules.insert
メソッドをご覧ください。
次のステップ
- 共有 VPC の詳細について、共有 VPC の概要を参照する。
- 共有 VPC を使用した Kubernetes Engine クラスタの設定手順を共有 VPC を使用したクラスタの設定で確認する。
- Cloud Run(フルマネージド)、Cloud Functions、App Engine スタンダード環境から共有 VPC ネットワークへのアクセスを設定する方法を確認する。
- 共有 VPC 設定の削除手順を共有 VPC のデプロビジョニングで確認する。