Oracle Cloud Infrastructure - Dokumentation

IAM-Policys für das Routing zwischen VCNs

Erfahren Sie mehr über IAM-Policys, die mit Peering- und dynamischen Routinggateways verwendet werden.

Weitere allgemeine IAM-Policys, die in Networking verwendet werden, finden Sie unter IAM-Policys für Networking.

Informationen zu IAM-Policys, die für lokales oder Remote-Peering mit DRGs spezifisch sind, finden Sie unter:

Informationen zu IAM-Policys, die für lokales Peering mit LPGs spezifisch sind, finden Sie unter:

Informationen zu IAM-Policys, die für das Anhängen von DRGs und VCNs spezifisch sind, finden Sie unter:

Einrichtung von Peerings kontrollieren

Mit IAM-Policys steuern Sie Folgendes:

  • Wer kann Ihren Mandanten für eine andere Region abonnieren (für Remote-VCN-Peering erforderlich).
  • Wer ist in Ihrer Organisation zum Einrichten von VCN-Peerings berechtigt (Beispiel: IAM-Policys unter Lokales Peering einrichten und Remote-Peering einrichten). Das Löschen dieser IAM-Policys betrifft keine vorhandenen Peerings, sondern nur die Möglichkeit, zukünftige Peers zu erstellen.
  • Für lokales VCN-Peering über ein gegenseitig angehängtes DRG in demselben Mandanten und derselben Region sind keine speziellen IAM-Policys erforderlich. Ob Peering mit VCNs in einem anderen Mandanten (der zu Ihrer Organisation, Oracle oder einem Drittanbieter gehören kann) erfolgen kann, erfordert spezielle Policy-Anweisungen, um mandantenübergreifendes Peering zu aktivieren. In den Anweisungen können Sie angeben, welcher bestimmte Mandant. Informationen zum lokalen VCN-Peering über ein gegenseitig angehängtes DRG in einem anderen Mandanten, aber in derselben Region finden Sie unter An VCNs in anderen Mandanten anhängen. Informationen zum Remote-VCN-Peering (möglicherweise zu einem anderen Mandanten) finden Sie unter Remote-Peering mit einem Legacy-DRG.
  • Wer kann Routentabellen und Sicherheitslisten verwalten.

Explizite Zustimmung von beiden Seiten erforderlich

Peering und Transitrouting umfassen zwei VCNs, die zu derselben Partei oder zu zwei verschiedenen Parteien gehören. Die Parteien befinden sich möglicherweise beide in Ihrem Unternehmen, aber in verschiedenen Abteilungen. Die Parteien könnten sich auch in komplett verschiedenen Unternehmen befinden (Beispiel: in einem Serviceanbietermodell). Weitere Beispiele für mandantenübergreifende Policys finden Sie unter Auf Objektspeicherressourcen mandantenübergreifend zugreifen.

Die Vereinbarung besteht aus Oracle Cloud Infrastructure Identity and Access Management-Policys, die jede Partei für das Compartment  oder den Mandanten des eigenen VCN implementiert. Wenn sich die VCNs in unterschiedlichen Mandanten befinden, muss jeder Administrator die Mandanten-OCID angeben und spezielle Policy-Anweisungen einrichten, um das Peering zu aktivieren. Details zu den IAM-Policys, die für die Verbindung zu einem VCN in einem anderen Mandanten erforderlich sind, finden Sie unter Remote-Peering mit einem upgegradeten DRG.

Endorse-, Admit- und Define-Anweisungen

Im Folgenden finden Sie einen Überblick über die in diesen Anweisungen verwendeten Verben:

  • Endorse: Gibt das allgemeine Set von Funktionen an, die eine in Ihrem eigenen Mandanten enthaltene Gruppe in anderen Mandanten ausführen kann. Die Endorse-Anweisung gehört immer in dem Mandanten, der die Gruppe von Benutzern enthält, die die Grenzen zu den anderen Mandanten überschreiten, um mit den Ressourcen dieses Mandanten zu arbeiten. In den Beispielen wird dieser Mandant als Quellmandant bezeichnet.
  • Admit: Gibt die Art der Berechtigungen in Ihrem eigenen Mandanten an, für die Sie einer Gruppe aus dem anderen Mandanten die Berechtigung erteilen möchten. Die Admit-Anweisung befindet sich in dem Mandanten, der den Zugriff auf den Mandanten gewährt. Die Admit-Anweisung identifiziert die Benutzergruppe, die Ressourcenzugriff vom Quellmandanten benötigt und mit einer entsprechenden Endorse-Anweisung identifiziert wird. In den Beispielen wird dieser Mandant als Zielmandant bezeichnet.

  • Define: Weisen Sie einer Mandanten-OCID für die Endorse- und Admit-Policy-Anweisungen einen lokalen Alias zu. Außerdem ist eine Define-Anweisung im Zielmandanten erforderlich, um der Quell-IAM-Gruppen-OCID für Admit-Anweisungen einen Aliasnamen zuzuweisen.

    Fügen Sie eine Define-Anweisung in derselben Policy-Entity wie die Endorse- oder Admit-Anweisung ein.

Die Anweisungen Endorse und Admit arbeiten zusammen. Eine Endorse-Anweisung befindet sich im Quellmandanten, während sich eine Admit-Anweisung im Zielmandanten befindet. Ohne eine entsprechende Anweisung, die den Zugriff angibt, erteilt eine bestimmte Endorse- oder Admit-Anweisung keinerlei Zugriff. Beide Mandanten müssen dem Zugriff zustimmen.

Wichtig

Neben Policy-Anweisungen müssen Sie auch eine Region abonnieren, um Ressourcen regionsübergreifend gemeinsam nutzen zu können.

Remote-Peering mit einem Legacy-DRG

Ein DRG kann eine Verbindung zu einem anderen DRG (und einem beliebigen angehängten VCN) in einer anderen Region herstellen, sofern die Compartments, die den Requestor und den Acceptor enthalten, über die richtigen Policys verfügen. Diese setzen sich folgendermaßen zusammen:

  • Policy "R" (vom Requestor implementiert): 

    Define group RequestorGrp as <requestorGroupOcid>
Define compartment RequestorComp as <RequestorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-from in compartment RequestorComp

    Der Anforderer befindet sich in einer IAM-Gruppe mit dem Namen RequestorGrp. Mit dieser Policy kann jeder in der Gruppe eine Verbindung von jedem DRG im Compartment des Requestors (RequestorComp) initiieren. Policy "R" kann entweder an den Mandanten (root Compartment) oder an RequestorComp angehängt werden. Informationen dazu, warum Sie die Policy an das eine oder das andere Compartment anhängen würden, finden Sie unter Policy-Grundlagen.

  • Policy "A" (vom Acceptor implementiert): 

    Define group RequestorGrp as <requestorGroupOcid>
Define compartment AcceptorComp as <AcceptorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-to in compartment AcceptorComp

    Mit dieser Policy kann der Requestor eine Verbindung zu jeder RPC im Compartment des Acceptors (AcceptorComp) herstellen. Diese Anweisung reflektiert die Zustimmung des Acceptors, die für das Einreichten des Peering erforderlich ist. Policy A kann entweder an den Mandanten (root Compartment) oder an AcceptorComp angehängt werden.

In dieser Abbildung werden die zwei Policys für VCNs in unterschiedlichen Regionen, jedoch in demselben Mandanten dargestellt.

Sowohl Policy R als auch Policy A gewähren RequestorGrp den Zugriff. Policy "R" hat jedoch einen Ressourcentyp mit dem Namen remote-peering-from, und Policy "A" hat einen Ressourcentyp mit dem Namen remote-peering-to. Zusammen lassen diese Policys zu, dass ein Benutzer aus RequestorGrp die Verbindung von einer RPC im Compartment des Requestors zu einer RPC im Compartment des Acceptors herstellen kann. Im API-Aufruf zum Erstellen der Verbindung wird angegeben, welche zwei RPCs verwendet werden sollen.

Tipp

Die von Policy "R" erteilte Berechtigung ist möglicherweise bereits vorhanden, wenn der Requestor in einer anderen Policy die Berechtigung zur Verwaltung aller Networkingkomponenten in "RequestorComp" hat. Beispiel: Eine allgemeine Netzwerk-Admin-Policy kann wie folgt aussehen: Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorComp. Wenn der Requestor zur NetworkAdmin-Gruppe gehört, sind die erforderlichen Berechtigungen in Policy "R" bereits enthalten (virtual-network-family umfasst RPCs). Wenn die Policy stattdessen so erstellt wird, dass sie den vollständigen Mandanten (Allow group NetworkAdmin to manage virtual-network-family in tenancy) abdeckt, verfügt der Requestor bereits über alle erforderlichen Berechtigungen in beiden Compartments, um die Verbindung herzustellen. In diesem Fall ist Policy "A" nicht erforderlich.

Remote-Peering mit einem upgegradeten DRG

Sowohl der Requestor als auch der Acceptor müssen sicherstellen, dass die richtigen Policys verwendet werden. In diesem Beispiel werden die minimalen Identitäts-Policys gezeigt, die zum Erstellen einer mandantenübergreifenden Remote-Peering-Verbindung erforderlich sind:

  • Policy "R" (vom Requestor implementiert):

    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

  • Policy "A" (vom Acceptor implementiert):

    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>

Lokales Peering mit einem LPG (VCNs im selben Mandanten)

In diesem Anwendungsfall befinden sich beide VCNs im selben Mandanten. Wenn sie sich in verschiedenen Mandanten befinden, finden Sie weitere Informationen unter Lokales Peering mit einem LPG (VCNs in verschiedenen Mandanten).

Administratoren für die VCNs des Anforderers und Acceptors müssen sicherstellen, dass die richtigen Policys verwendet werden:

  • Policy "R" (vom Requestor implementiert): 

    Define group requestorGrp as <requestorGroupOcid>
Define compartment requestorComp as <requestorCompartmentOcid>

Allow group requestorGrp to manage local-peering-from in compartment requestorComp

    Der Anforderer befindet sich in einer IAM-Gruppe mit dem Namen requestorGrp. Mit dieser Policy kann jeder in der Gruppe eine Verbindung von jedem LPG im Compartment des Anforderers (requestorComp) initiieren. Policy "R" kann entweder an den Mandanten (root Compartment) oder an requestorComp angehängt werden. Informationen dazu, warum Sie die Policy an das eine oder das andere Compartment anhängen würden, finden Sie unter Policy-Grundlagen.

  • Policy "A" (vom Acceptor implementiert): 

    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

    Mit den Anweisungen in der Policy kann der Requestor eine Verbindung zu jedem LPG im Compartment des Acceptors (acceptorComp) herstellen. Diese Anweisung reflektiert die Zustimmung des Acceptors, die für das Einreichten des Peering erforderlich ist. Policy A kann entweder an den Mandanten (root Compartment) oder an acceptorComp angehängt werden.

    Tipp

    Mit den Anweisungen in Policy "A" kann der Requestor die VCNs und LPGs in acceptorComp auflisten. Die Anweisungen sind erforderlich, damit der Requestor mit der Konsolen-UI die VCNs und LPGs aus einer Liste in acceptorComp auswählen und die Verbindung herstellen kann. Das folgende Diagramm zeigt nur die erste Anweisung. Es ist die kritische Anweisung, die die Verbindung zulässt.
In dieser Abbildung werden die beiden Policys für VCNs in demselben Mandanten dargestellt.

Sowohl Policy R als auch Policy A gewähren requestorGrp den Zugriff. Policy "R" hat jedoch einen Ressourcentyp mit dem Namen local-peering-from, und Policy "A" hat einen Ressourcentyp mit dem Namen local-peering-to. Zusammen lassen diese Policys zu, dass ein Benutzer aus requestorGrp die Verbindung von einem LPG im Compartment des Requestors zu einem LPG im Compartment des Acceptors herstellen kann. Im API-Aufruf zum Erstellen der Verbindung wird angegeben, welche zwei LPGs verwendet werden sollen.

Tipp

Die Berechtigung, die von Policy "R" erteilt wird, ist möglicherweise bereits vorhanden, wenn der Requestor in einer anderen Policy die Berechtigung zur Verwaltung aller Networking-Komponenten in RequestorComp hat. Beispiel: Es gibt eine allgemeine Netzwerk-Admin-Policy wie diese:

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

Wenn der Requestor zur NetworkAdmin-Gruppe gehört, sind die erforderlichen Berechtigungen in Policy "R" bereits enthalten (virtual-network-family umfasst LPGs). Wenn die Policy stattdessen so erstellt wird, dass sie den vollständigen Mandanten anstatt nur das Compartment requestorComp abdeckt, verfügt der Anforderer bereits über alle erforderlichen Berechtigungen in beiden Compartments, um die Verbindung herzustellen. In diesem Fall ist Policy "A" nicht erforderlich.

Lokales Peering mit einem LPG (VCNs in verschiedenen Mandanten)

In diesem Anwendungsfall befinden sich die VCNs in unterschiedlichen Mandanten (mandantenübergreifendes Peering). Wenn sich die VCNs in demselben Mandanten befinden, finden Sie weitere Informationen unter Lokales Peering mit einem LPG (VCNs in demselben Mandanten).

Sowohl der Requestor als auch der Acceptor müssen sicherstellen, dass die richtigen Policys verwendet werden:

  • Policy "R" (vom Requestor implementiert): 

    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

    Der Anforderer befindet sich in einer IAM-Gruppe mit einer zugewiesenen OCID, die Sie angeben. Mit dieser Policy kann jeder in dieser Gruppe eine Verbindung von jedem LPG im Compartment des Anforderers (requestorComp) initiieren.

    Die erste Anweisung ist eine Define-Anweisung, die der Mandanten-ID des Acceptors ein benutzerfreundliches Label zugewiesen. Die Anweisung verwendet "Acceptor" als Label, der Requestor kann jedoch auch ein anderes Label verwenden. Alle Define-Anweisungen in einer Policy müssen die ersten Anweisungen (oben) sein.

    Mit der zweiten Anweisung kann requestorGrp eine Verbindung von einem LPG im Compartment des Anforderers herstellen.

    Die Anweisungen Allow und Endorse sind spezielle Anweisungen, die erforderlich sind, weil sich die LPGs in verschiedenen Mandanten befinden. Mit diesen Anweisungen kann requestorGrp ein LPG im Mandanten des Requestors mit einem LPG im Mandanten des Acceptors verbinden.

    Wenn Sie requestorGrp eine Berechtigung für die Verbindung mit einem LPG in einem beliebigen Mandanten erteilen möchten, sieht die Policy folgendermaßen aus:

    
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

    Unabhängig davon muss Policy "R" an den Mandanten des Requestors (Root Compartment) und nicht an das Compartment des Requestors angehängt werden. Policys, die den mandantenübergreifenden Zugriff aktivieren, müssen an den Mandanten angehängt sein. Weitere Informationen über das Anhängen von Policys finden Sie unter Policy-Grundlagen.

  • Policy "A" (vom Acceptor implementiert): 

    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

    Ähnlich wie die Requestor-Policy verwendet auch diese Policy zunächst Define-Anweisungen, um der Mandanten-OCID des Requestors und der OCID der Requestor-Admin-Gruppe benutzerfreundliche Labels zuzuweisen. Wie zuvor erwähnt, könnte der Acceptor nach Wunsch andere Werte für diese Labels verwenden.

    Mit der vierten und der fünften Anweisung kann requestorGrp eine Verbindung zu einem LPG im Compartment des Acceptors (acceptorComp) herstellen. Diese Anweisungen reflektieren die kritische Zustimmung, die für das Einrichten des Peering erforderlich ist. Admit gibt an, dass der Zugriff für eine Gruppe außerhalb des Mandanten gilt, in dem sich die Policy befindet.

    Policy "A" muss an den Mandanten des Acceptors (Root Compartment) und nicht an das Compartment des Acceptors angehängt werden.

In dieser Abbildung wird der Speicherort der beiden Policys für VCNs in unterschiedlichen Mandanten dargestellt.

VCNs im selben Mandanten zuordnen

Wenn die VCN-Administratorgruppe VCN-Anhänge erstellen und verwalten und den Anhängen DRG-Routentabellen zuweisen soll, implementieren Sie die folgende Policy: 

define group VcnAdmin as <vcnAdminGroupOcid>

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

Um eine VCN-Routentabelle mit dem Anhang zu verknüpfen, fügen Sie die folgende zusätzliche Zeile hinzu: 
Allow group VCN-Admin to manage route-tables in tenancy

VCNs in anderen Mandanten zuordnen

"Mandantenübergreifende Anhänge" sind spezielle VCN-Anhänge, mit denen ein DRG direkt mit einem VCN in einem anderen Mandanten, aber in derselben Region gehostet wird. Das VCN wird nicht an ein DRG in seinem eigenen Mandanten angehängt. In der folgenden Beispiel-Policy werden die Mindestanforderungen an die IAM-Policy für beide Mandanten aufgeführt, damit dieser Verbindungstyp zulässig ist.

Dieses Beispiel für ein Set von Policys ermöglicht die folgenden Aktionen:

  • DRG-Administratoren im DRG-Mandanten können einen DRG-Anhang im VCN-Mandanten erstellen.
  • VCN-Administratoren im VCN-Mandanten können eine VCN-Routentabelle mit dem Anhang verknüpfen (wird verwendet, wenn das angehängte VCN ein Transit-VCN ist). Wenn der VCN-Administrator eine Policy zur Verwaltung aller Ressourcen im VCN-Mandanten verwendet, hat er diese Möglichkeit bereits, weil sich der VCN-Anhang im VCN-Mandanten befindet.
  • VCN-Administratoren können die Verknüpfung der DRG-Routentabelle mit dem DRG-Anhang nicht ändern.

  • Policy R (DRG in diesem Mandanten)

    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 ist die OCID der Gruppe vcnAdmin, die sich im Acceptor-Mandanten befindet und in der Acceptor Policy bestätigt wird.

  • Policy A (VCN in diesem Mandanten)

    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 ist die OCID der Gruppe drgAdmin, die sich im Anforderermandanten befindet und in der Anforderer-Policy bestätigt wird.