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 in einer Organisation zum Einrichten von VCN-Peerings berechtigt ist (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 beiden Parteien befinden sich möglicherweise beide in demselben 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 Gruppe in Ihrem eigenen Mandanten in anderen Mandanten ausführen kann. Die Endorse-Anweisung gehört immer in dem Mandanten, der die Grenzwerte zu den anderen Mandanten überschreitet, um mit dem Ressourcen in diesem Mandanten zu arbeiten. In den Beispielen wird dieser Mandant der Quellmandant genannt.
Admit: Gibt die Art der Möglichkeiten in Ihrem eigenen Mandanten an, die Sie einer Gruppe aus dem anderen Mandanten die Berechtigung erteilen möchten. Die Admit-Anweisung ist in dem Mandanten vorhanden, der den Zugriff auf den Mandanten gewährt. Die Admit-Anweisung identifiziert die Benutzergruppen, die Ressourcenzugriff vom Quellmandanten benötigt und mit einer entsprechenden Endorse-Anweisung identifiziert wird. In den Beispielen wird dieser Mandant der Zielmandant genannt.
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 Corect-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 namens RequestorGrp. Mit dieser Policy kann jeder in der Gruppe eine Verbindung von einem beliebigen DRG im Compartment des Anforderers (RequestorComp) starten. Policy "R" kann entweder an den Mandanten (Root Compartment) oder an RequestorComp angehängt werden. Informationen dazu, warum Sie diese Policy an das ein oder das andere Fach 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 es 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 liegt möglicherweise bereits vor, wenn der Requestor in einer anderen Policy zur Verwaltung aller Netzwerkkomponenten in RequestorComp die Berechtigung zur Verwaltung 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 erstellt wird, dass der Requestor den gesamten 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 die Acceptor müssen sicherstellen, dass die erforderlichen 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 Requestor- und Acceptor-VCNs müssen sicherstellen, dass die erforderlichen Policys vorhanden sind:

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 namens requestorGrp. Mit dieser Policy kann jeder in der Gruppe eine Verbindung von jedem LPG im Compartment des Anforderer (requestorComp) starten. Policy "R" kann entweder an den Mandanten (Root Compartment) oder an requestorComp angehängt werden. Informationen dazu, warum Sie sie an ein oder das andere Fach 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 der zweiten und dritten Anweisung 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. Im folgenden Diagramm wird nur die erste Anweisung dargestellt. Diese kritische Anweisung ermöglicht die Verbindung.

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 von Policy R erteilte Berechtigung besteht möglicherweise bereits, wenn der Requestor in einer anderen Policy über die Berechtigung zur Verwaltung aller Networking-Komponenten in RequestorComp verfügt. Beispiel: Es kann eine allgemeine Netzwerk-Admin-Policy wie die folgende geben:

 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 geschrieben wird, dass Sie den gesamten Mandanten anstatt nur das Compartment requestorComp abdeckt, verfügt der Anfordererin 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 verschiedenen Mandanten (also ein mandantenübergreifendes Peering). Wenn sich die VCNs in demselben Mandanten befinden, lesen Sie stattdessen Lokales Peering mit einem LPG (VCNs im selben Mandanten).

Sowohl der Requestor als auch die Acceptor müssen sicherstellen, dass die erforderlichen 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 Requestor befindet sich in einer IAM-Gruppe mit einer zugewiesenen OCID, die Sie angeben. Mit dieser Policy kann jeder in einer Gruppe eine Verbindung von jedem LPG im Compartment des Anforderer (requestorComp) starten.

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 der requestorGrp eine Berechtigung zur Verbindung mit einem LPG in jedem beliebigen Mandanten erteilen möchten, sieht die Policy stattdessen 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 Anforderer-Policy verwendet auch diese Policy zunächst Define-Anweisungen, um der Mandanten-OCID des Anforderers und der OCID der Anforderer-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 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 verbunden, aber in derselben Region gehostet wird. Das VCN ist an ein DRG in einem separaten Mandanten angehängt. Die Beispiel-Policy, die den Mindestanforderungen an die IAM-Policy für beide Mandanten entspricht, um diesen Verbindungstyp zuzulassen.

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 DRG-Routentabellenverknüpfung für den 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 im Acceptor-Mandanten und wird in der Acceptor-Policy bestätigt.

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 im Requestor-Mandanten und in der Requestor-Policy bestätigt.

Oracle Cloud Infrastructure - Dokumentation