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

ピアリングの確立の制御

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

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

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

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

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

Policy RとPolicy 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を使用したローカル・ピアリング(異なるテナンシのVCNs) 🔗

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

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

• ポリシー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はアクセプタのテナンシ(ルート・コンパートメント)にアタッチする必要があり、アクセプタのコンパートメントにはアタッチしません。

同じテナンシ内のVCNsへのアタッチ 🔗

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

他のテナンシのVCNsへのアタッチ 🔗

「クロステナンシ・アタッチメント」は、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です。