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

ピアリングおよび動的ルーティング・ゲートウェイで使用されるIAMポリシーについて学習します。

ネットワーキングで使用される一般的なIAMポリシーの詳細は、ネットワーキングに対するIAMポリシーを参照してください。

DRGを使用したローカル・ピアリングまたはリモート・ピアリングに固有のIAMポリシーについては、次を参照してください:

LPGを使用したローカル・ピアリングに固有のIAMポリシーについては、次を参照してください:

DRGおよび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を使用したリモート・ピアリングを参照してください。

EndorseAdmitおよび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にアタッチできます。

この図は、同じテナンシ内の異なるリージョンにあるVCNに対する2つのポリシーを示しています。

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

ヒント

RequestorCompのすべてのネットワーキング・コンポーネントを管理する別のポリシーでリクエスタに権限がある場合、Policy Rによって付与された権限がすでに設定されている可能性があります。たとえば、Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorCompのような一般的なネットワーク管理ポリシーが存在する場合がありますリクエスタがNetworkAdminグループに属している場合、ポリシーRでカバーされる必要な権限をすでに持っています(virtual-network-familyにRPCが含まれます)。さらに、テナンシ全体をカバーするようにポリシーが書き込まれた場合(Allow group NetworkAdmin to manage virtual-network-family in tenancy)、リクエスト元は、接続を確立するために必要な権限を両方のコンパートメントですでに持っています。その場合、ポリシーAは必要ありません。

アップグレードされた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)を使用したローカル・ピアリングを参照してください。

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

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

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

ヒント

RequestorComp内のすべてのネットワーキング・コンポーネントを管理する別のポリシーでリクエスタに権限がある場合、Policy Rによって付与された権限がすでに設定されている可能性があります。たとえば、次のような一般的なネットワーク管理ポリシーが存在する可能性があります:

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

リクエスタがNetworkAdminグループに属している場合、ポリシーRでカバーされる必要な権限をすでに持っています(virtual-network-familyにLPGが含まれます)。さらに、requestorCompコンパートメントのみではなく、テナンシ全体をカバーするようにポリシーが記述されている場合、リクエスタは、接続を確立するために必要なすべての権限を両方のコンパートメントですでに持っています。その場合、ポリシーAは必要ありません。

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

このユース・ケースでは、SCNは異なるテナンシ(つまり、クロステナンシ・ピアリング)にあります。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に対する2つのポリシーの場所を示しています。

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

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

define group VcnAdmin as <vcnAdminGroupOcid>

Allow group VcnAdmin to manage vcns in tenancy
Allow group VcnAdmin to manage drgs in tenancy
ノート

VCNルート表をアタッチメントに関連付けるには、次の追加行を追加します:
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です。