VCN間のルーティングに関するIAMポリシー

ピアリングの確立の制御

IAMポリシーを使用すると、次のことを制御できます:

• テナンシを別のリージョンにサブスクライブできるユーザー(リモートVCNピアリングで必要)。
• VCNピアリングを確立する権限を持つ組織内のユーザー(例については、ローカル・ピアリングの設定とリモート・ピアリングの設定のIAMポリシーを参照してください)。これらのIAMポリシーを削除しても既存のピアリングには影響せず、将来のピアリングを作成する機能にのみ影響します。
• 同じテナンシおよびリージョンで相互にアタッチされたDRGを介したローカルVCNピアリングの場合、特別なIAMポリシーは必要ありません。別のテナンシ(組織、Oracleまたはサード・パーティに属している可能性がある)のVCNでピアリングを実行できるかどうかには、クロステナンシ・ピアリングを有効にするために特別なポリシー・ステートメントが必要です。文では、特定のテナンシを指定できます。異なるテナンシ内で同じリージョンで相互にアタッチされたDRGを介したローカルVCNピアリングについては、他のテナンシのVCNへのアタッチを参照してください。リモートVCNピアリング(場合によっては別のテナンシ)については、レガシーDRGを使用したリモート・ピアリングを参照してください。
• ルート表およびセキュリティ・リストを管理できるユーザー。

両方の側から必要な明示的合意

ピアリングおよび転送ルーティングには、同じ当事者または2つの異なる当事者が所有する2つのVCNが含まれます。2つの当事者は、どちらも自分の会社に存在していても、異なる部門に属する場合があります。または、2つの当事者は、完全に異なる会社に属することもあります(サービス・プロバイダ・モデルなど)。クロステナント・ポリシーの追加の例は、テナンシをまたがったオブジェクト・ストレージ・リソースへのアクセスを参照してください。

この合意は、各当事者が独自のVCNのコンパートメントまたはテナンシに対して実装するOracle Cloud Infrastructure Identity and Access Managementポリシーの形式になります。VCNが異なるテナンシにある場合、各管理者はテナンシOCIDを提供し、ピアリングを有効にする特別なポリシー・ステートメントを用意する必要があります。別のテナンシのVCNに接続するために必要なIAMポリシーの詳細は、アップグレードされたDRGによるリモート・ピアリングを参照してください。

Endorse、AdmitおよびDefineステートメント

これらの文で使用される動詞の概要は次のとおりです:

• Endorse: 自分のテナンシ内のグループが他のテナンシ内で実行できる一般的な機能セットを示します。Endorseステートメントは、境界を越えて他のテナンシにアクセスし、そのテナンシのリソースを使用するユーザーのグループを含むテナンシに常に属します。例では、このテナンシをソース・テナンシと呼びます。
• Admit: 他のテナンシのグループに付与する、自分のテナンシでの機能の種類を示します。Admitステートメントは、テナンシへのアクセスを許可するテナンシに属します。Admitステートメントは、ソース・テナンシからのリソース・アクセスを必要とし、対応するEndorseステートメントで特定されるユーザーのグループを識別します。例では、このテナンシを宛先テナンシと呼びます。

• Define: EndorseおよびAdmitポリシー・文のテナンシOCIDにローカル・エイリアスを割り当てます。AdmitステートメントのソースIAMグループOCIDに別名を割り当てるには、宛先テナンシにDefineステートメントも必要です。

  Defineステートメントは、EndorseまたはAdmitステートメントと同じポリシー・エンティティに含めます。

EndorseステートメントとAdmitステートメントは連携して動作します。Endorseステートメントがソース・テナンシに存在するのに対し、Admitステートメントは宛先テナンシに存在します。アクセス権を指定する対応ステートメントがない場合、特定のEndorseまたはAdmitステートメントはアクセス権を与えません。両方のテナンシがアクセスに同意する必要があります。

レガシーDRGでのリモート・ピアリング

リクエスタとアクセプタを含むコンパートメントに適切なポリシーが設定されている場合、DRGは別のリージョン内の別のDRG (およびアタッチされたVCN)に接続できます。構成内容は次のとおりです:

• ポリシーR (リクエスタによる実装):

  Define group RequestorGrp as <requestorGroupOcid>
  Define compartment RequestorComp as <RequestorCompartmentOcid>
  
  Allow group RequestorGrp to manage remote-peering-from in compartment RequestorComp

  リクエスタは、RequestorGrpというIAMグループに属しています。このポリシーによって、グループ内のすべてのユーザーが、リクエスタのコンパートメント(RequestorComp)の任意のDRGから接続を開始できます。Policy Rは、テナンシ(ルート・コンパートメント)またはRequestorCompにアタッチできます。これを一方または他方にアタッチする理由の詳細は、ポリシーの基本を参照してください。

• ポリシーA (アクセプタによる実装):

  Define group RequestorGrp as <requestorGroupOcid>
  Define compartment AcceptorComp as <AcceptorCompartmentOcid>
  
  Allow group RequestorGrp to manage remote-peering-to in compartment AcceptorComp
  

  このポリシーを使用すると、リクエスト元はアクセプタのコンパートメント(AcceptorComp)内の任意のRPCに接続できます。このステートメントは、ピアリングを確立するためのアクセプタからの必要な合意を反映します。ポリシーAは、テナント(ルート・コンパートメント)またはAcceptorCompにアタッチできます。

Policy RとポリシーAの両方がRequestorGrpアクセス権を付与します。ただし、ポリシーRにはremote-peering-fromというリソース・タイプがあり、ポリシーAにはremote-peering-toというリソース・タイプがあります。まとめると、これらのポリシーにより、RequestorGrpのユーザーは、リクエスト元のコンパートメント内のRPCからアクセプタのコンパートメント内のRPCへの接続を確立できます。実際に接続を作成するAPIコールで、2つのRPCを指定します。

アップグレードされたDRGによるリモート・ピアリング

リクエスタとアクセプタの両方が、適切なポリシーが有効であることを確認する必要がありますこの例では、クロステナンシ・リモート・ピアリング接続を作成するために必要な最小限のアイデンティティ・ポリシーを示します:

• ポリシーR (リクエスタによる実装):

  Define group requestorGroup as <requestorGroupOcid>
  Define compartment requestorCompartment as id <requestorCompartmentOcid>
  Define tenancy Acceptor as <AcceptorTenancyOcid>
  
  Allow group requestorGroup to manage remote-peering-from in compartment requestorCompartment
  Endorse group requestorGroup to manage remote-peering-to in tenancy Acceptor

• ポリシーA (アクセプタによる実装):

  Define group requestorGroup as <requestor-group-ocid>
  Define tenancy Requestor as <requestorTenancyOcid>
  Define compartment acceptorCompartment as id <acceptorCompartmentOcid>
  
  Admit group requestorGroup of tenancy Requestor to manage remote-peering-to in compartment <acceptorCompartment>

LPG (同じテナンシ内のVCN)を使用したローカル・ピアリング

このユースケースでは、両方のVCNが同じテナンシ内にあります。異なるテナンシにある場合は、かわりにLPG (異なるテナンシのVCN)を使用したローカル・ピアリングを参照してください。

リクエスト元およびアクセプタのVCNの管理者は、適切なポリシーが有効であることを確認する必要があります:

• ポリシーR (リクエスタによる実装):

  Define group requestorGrp as <requestorGroupOcid>
  Define compartment requestorComp as <requestorCompartmentOcid>
  
  Allow group requestorGrp to manage local-peering-from in compartment requestorComp

  リクエスタは、requestorGrpというIAMグループに属しています。このポリシーによって、グループ内のすべてのユーザーが、リクエスト元のコンパートメント(requestorComp)の任意のLPGから接続を開始できます。Policy Rは、テナンシ(ルート・コンパートメント)またはrequestorCompにアタッチできます。これを一方または他方にアタッチする理由の詳細は、ポリシーの基本を参照してください。

• ポリシーA (アクセプタによる実装):

  Define group requestorGrp as <requestorGroupOcid>
  Define compartment acceptorComp as id <acceptorCompartmentOcid>
  
  Allow group requestorGrp to manage local-peering-to in compartment acceptorComp
  Allow group requestorGrp to inspect vcns in compartment acceptorComp
  Allow group requestorGrp to inspect local-peering-gateways in compartment acceptorComp
  

  ポリシーのステートメントにより、リクエスト元はアクセプタのコンパートメント(acceptorComp)の任意のLPGに接続できます。このステートメントは、ピアリングを確立するためのアクセプタからの必要な合意を反映します。ポリシーAは、テナント(ルート・コンパートメント)またはacceptorCompにアタッチできます。

  ヒント
  
  ポリシーAの文を使用すると、リクエスタはacceptorCompのSCNおよびLPGをリストできます。文は、リクエスタがコンソールUIを使用してacceptorCompのSCNおよびLPGのリストから選択し、接続を確立するために必要です。次の図では、最初のステートメント(接続を許可する重要なもの)のみを中心に説明しています。

Policy RとポリシーAの両方がrequestorGrpアクセス権を付与します。ただし、ポリシーRにはlocal-peering-fromというリソース・タイプがあり、ポリシーAにはlocal-peering-toというリソース・タイプがあります。まとめると、これらのポリシーにより、requestorGrpのユーザーは、リクエスト元のコンパートメント内のLPGからアクセプタのコンパートメント内のLPGへの接続を確立できます。接続を作成するAPIコールで、2つのLPGを指定します。

 Allow group NetworkAdmin to manage virtual-network-family in compartment requestorComp

LPG (異なるテナンシ内のVCN)を使用したローカル・ピアリング

このユースケースでは、VCNは異なるテナンシに存在します(つまり、クロス・テナンシ・ピアリングです)。VCNが同じテナンシ内にある場合は、かわりにLPG (同じテナンシ内のVCN)を使用したローカル・ピアリングを参照してください。

リクエスタとアクセプタの両方が、適切なポリシーが有効であることを確認する必要があります:

• ポリシーR (リクエスタによる実装):

  Define tenancy Acceptor as <acceptorTenancyOcid>
  Define group requestorGrp as <requestorGroupOcid>
  Define compartment requestorComp as id <requestorCompartmentOcid>
  
  Allow group requestorGrp to manage local-peering-from in compartment requestorComp
  Endorse group requestorGrp to manage local-peering-to in tenancy Acceptor
  Endorse group requestorGrp to associate local-peering-gateways in compartment requestorComp
     with local-peering-gateways in tenancy Acceptor

  リクエスタは、指定したOCIDが割り当てられたIAMグループにあります。このポリシーによって、グループ内のすべてのユーザーが、リクエスト元のコンパートメント(requestorComp)の任意のLPGから接続を開始できます。

  最初のステートメントは、アクセプタのテナンシOCIDにわかりやすいラベルを割り当てる"define"ステートメントです。ここでのステートメントはラベルとして"Acceptor"を使用していますが、リクエスタが選択した値にすることができます。ポリシー内のすべての"define"ステートメントは、一番上にある最初のステートメントである必要があります。

  2番目のステートメントにより、requestorGrpはリリクエスト元のコンパートメントにあるLPGからの接続を確立できます。

  「Allow」および「Endorse」文は、LPGが異なるテナンシにあるために必要となる特別なものです。これらによって、requestorGrpは、リクエスト元のテナンシ内のLPGをアクセプタのテナンシ内のLPGに接続できます。

  任意のテナント内のLPGに接続する権限をrequestorGrpに付与する場合、かわりにポリシーは次のようになります:

  
  Allow group requestorGrp to manage local-peering-from in compartment requestorComp
  Endorse group requestorGrp to manage local-peering-to in any-tenancy
  Endorse group requestorGrp to associate local-peering-gateways in compartment requestorComp with local-peering-gateways in any-tenancy
  

  これとは関係なく、ポリシーRはリクエスタのテナンシ(ルート・コンパートメント)にアタッチする必要があり、リクエスタのコンパートメントにはアタッチしません。クロステナンシ・アクセスを有効にするポリシーは、テナンシにアタッチする必要があります。ポリシーのアタッチメントの詳細は、ポリシーの基本を参照してください。

• ポリシーA (アクセプタによる実装):

  Define tenancy Requestor as <requestorTenancyOcid>
  Define group requestorGrp as <requestorGroupOcid>
  Define compartment acceptorComp as id <acceptorCompartmentOcid>
  
  Admit group requestorGrp of tenancy Requestor to manage local-peering-to in compartment acceptorComp
  Admit group requestorGrp of tenancy Requestor to associate local-peering-gateways in tenancy Requestor with local-peering-gateways in compartment acceptorComp
  

  リクエスト元のポリシーと同様に、このポリシーでは、最初に"define"ステートメントを使用して、リクエスト元のテナンシOCIDおよびリクエスト元の管理グループのOCIDにフレンドリ・ラベルを割り当てます。前述のように、アクセプタは必要に応じてそれらのラベルに他の値を使用できます。

  4番目と5番目のステートメントにより、requestorGrpはアクセプタのコンパートメント(acceptorComp)のLPGに接続できます。これらのステートメントは、ピアリングを確立するために必要となる重要な合意を反映します。Admitという語は、ポリシーが存在するテナンシの外部のグループにアクセス権が適用されることを示します。

  ポリシーAはアクセプタのテナンシ(ルート・コンパートメント)にアタッチする必要があり、アクセプタのコンパートメントにはアタッチしません。

同じテナンシのVCNへのアタッチ

VCN管理者グループがVCNアタッチメントを作成および管理し、DRGルート表をアタッチメントに割り当てる場合は、次のポリシーを実装します:

define group VcnAdmin as <vcnAdminGroupOcid>

Allow group VcnAdmin to manage vcns in tenancy
Allow group VcnAdmin to manage drgs in tenancy

Allow group VCN-Admin to manage route-tables in tenancy

他のテナンシのVCNへのアタッチ

「クロス・テナンシ・アタッチメント」は、DRGを他のテナンシのVCNに直接接続するために使用されるが、同じリージョンに同居するために使用される特別なVCNアタッチメントです。VCNは、独自のテナンシのDRGにアタッチされません。次のポリシーの例では、このタイプの接続を許可する両方のテナンシの最小IAMポリシー要件について説明します。

このポリシー・セットの例では、次のアクション・セットを使用できます:

• DRGテナント内のDRG管理者は、VCNテナントにDRGアタッチメントを作成できます。
• VCNテナントのVCN管理者は、VCNルート表をアタッチメントに関連付けることができます(アタッチされたVCNが転送VCNの場合に使用されます)。VCN管理者がVCNテナント内のすべてのリソースを管理するポリシーを持っている場合、VCNアタッチメントはVCNテナンシに存在するため、すでにこの権限を持っています。
• VCN管理者は、DRGアタッチメントのDRGルート表関連付けを変更できません。

• Policy R (このテナンシのDRG)

  define group vcnAdmin as <vcnAdminGroupOcid>
  define group drgAdmin as <drgAdminGroupOcid>
  define tenancy acceptorVCN as <acceptorTenancyOcid>
  
  endorse group drgAdmin to manage drg-attachment in tenancy acceptorVCN
  admit group vcnAdmin of tenancy acceptorVCN to manage drg in tenancy 

  vcnAdminGroupOcidは、アクセプタ・テナンシにあり、アクセプタ・ポリシーで承認されているvcnAdminグループのOCIDです。

• ポリシーA (このテナンシ内のVCN)

  define tenancy requestorDRG as <requestorTenancyOcid>
  define group drgAdmin as <drgAdminGroupOcid>
  define group vcnAdmin as <vcnAdminGroupOcid>
  
  admit group drgAdmin of tenancy requestorDRG to manage drg-attachment in tenancy
  endorse group vcnAdmin to manage drg in tenancy requestorDRG

  drgAdminGroupOcidは、リクエスタ・テナンシにあり、リクエスタ・ポリシーで承認されているdrgAdminグループのOCIDです。