Politiques IAM pour le routage entre les réseaux en nuage virtuels

Découvrez les politiques IAM utilisées avec les passerelles d'appairage et de routage dynamique.

Pour plus d'informations sur les politiques IAM générales utilisées dans le service de réseau, voir Politiques IAM pour le service de réseau.

Pour les politiques IAM propres à l'appairage local ou distant à l'aide de DRG, voir :

Pour les politiques IAM propres à l'appairage local à l'aide de passerelles LPG, voir :

Appairage local à l'aide d'une passerelle LPG (réseaux en nuage virtuels dans la même location)
Appairage local à l'aide d'une passerelle LPG (réseaux en nuage virtuels dans des locations différentes)

Pour les politiques IAM propres à l'attachement de passerelles de routage dynamique et de réseaux en nuage virtuels, voir :

Contrôle de l'établissement des appairages

Avec les politiques GIA, vous pouvez contrôler :

Qui peut abonner votre location à une autre région (obligatoire pour l'appairage distant de réseaux VCN).
Qui dans votre organisation a l'autorisation d'établir des appairages de réseaux VCN (par exemple, voir les politiques GIA dans Configuration d'un appairage local et Configuration d'un appairage distant). La suppression de ces politiques GIA n'a aucune incidence sur les appairages existants, uniquement sur la capacité à créer des appairages futurs.
Pour l'appairage local de VCN au moyen d'une passerelle DRG attachée mutuellement dans la même location et la même région, aucune politique IAM spéciale n'est nécessaire. Si l'appairage peut se produire avec des réseaux en nuage virtuels dans une location différente (qui peut appartenir à votre organisation, Oracle ou une tierce partie) nécessiterait des énoncés de politique spéciaux pour permettre l'appairage interlocation. Dans les énoncés, vous pouvez spécifier quelle location particulière. Pour l'appairage local de VCN au moyen d'une passerelle DRG attachée mutuellement dans une location différente mais dans la même région, voir Attachement à des réseaux en nuage virtuels dans d'autres locations. Pour l'appairage distant de réseaux VCN (éventuellement vers une location différente), voir Appairage distant avec une passerelle DRG existante.
Qui peut gérer les tables de routage et les listes de sécurité.

Entente explicite requise des deux côtés

L'appairage et le routage de transit impliquent deux réseaux en nuage virtuels détenus par une seule entité ou par deux. Les deux entités peuvent faire partie de votre société mais dans des services différents. Elles peuvent également appartenir à des sociétés distinctes (par exemple, dans un modèle avec fournisseur de service). Voir Accès aux ressources de stockage d'objets entre des locations pour plus d'exemples de politiques interlocations.

L'entente se présente sous la forme de politiques de gestion des identités et des accès Oracle Cloud Infrastructure que chaque entité met en oeuvre pour le compartiment ou la location de son propre réseau VCN. Si les réseaux en nuage virtuels se trouvent dans des locations différentes, chaque administrateur doit fournir son OCID de location et définir des énoncés particuliers pour permettre l'appairage. Pour plus de détails sur les politiques IAM requises pour se connecter à un réseau VCN dans une autre location, voir Appairage distant avec une passerelle DRG mise à niveau.

`Endorse`, `Admit` et `Define` Énoncés

Voici un aperçu des verbes utilisés dans ces instructions :

Endorse : Indique le jeu général de fonctions qu'un groupe de votre propre location peut exécuter dans d'autres locations. L'énoncé Endorse se trouve toujours dans la location où le groupe d'utilisateurs franchit les limites de l'autre location pour en utiliser les ressources. Dans les exemples, cette location est la location source.
Admit : Indique le type de fonction dans votre propre location que vous voulez accorder à un groupe de l'autre location. L'énoncé Admit se trouve dans la location qui accorde "l'entrée" à la location. L'énoncé Admit identifie le groupe d'utilisateurs qui demande l'accès aux ressources de la location source et qui est identifié par un énoncé Endorse correspondant. Dans les exemples, cette location est la location de destination.
Define : Affecte un alias local à un OCID de location pour les énoncés de politique Endorse et Admit. Un énoncé Define est également requis dans la location de destination pour affecter un alias à l'OCID du groupe IAM source pour les énoncés Admit.

Incluez un énoncé Define dans la même entité de politique que celle de l'énoncé Endorse ou Admit.

Les énoncés Endorse et Admit fonctionnent ensemble. Un énoncé Endorse se trouve dans la location source alors qu'un énoncé Admit se trouve dans la location de destination. Sans un énoncé correspondant indiquant l'accès, un énoncé Endorse ou Admit particulier n'octroie aucun accès. Les deux locations doivent accepter l'accès.

Important

En plus des énoncés de politique, vous devez également vous abonner à une région pour partager des ressources entre les régions.

Appairage distant avec une passerelle DRG existante

Une passerelle DRG peut se connecter à une autre passerelle DRG (et à tout réseau VCN attaché) dans une autre région, à condition que les compartiments contenant le demandeur et l'accepteur aient les politiques appropriées en place. Il s'agit des politiques suivantes :

Politique D (mise en oeuvre par le demandeur) :
```
Define group RequestorGrp as <requestorGroupOcid>
Define compartment RequestorComp as <RequestorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-from in compartment RequestorComp
```
Le demandeur fait partie d'un groupe IAM nommé RequestorGrp. Cette politique permet à tous les membres du groupe de lancer une connexion à partir de toute passerelle DRG du compartiment du demandeur (RequestorComp). La politique R peut être associée à la location ( compartiment racine) ou à RequestorComp. Pour des informations sur les raisons pour lesquelles vous l'associez à une location plutôt qu'à l'autre, voir Principes de base des politiques.
Politique A (mise en oeuvre par l'accepteur) :
```
Define group RequestorGrp as <requestorGroupOcid>
Define compartment AcceptorComp as <AcceptorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-to in compartment AcceptorComp
```
Cette politique permet au demandeur de se connecter à toute connexion d'appairage distant du compartiment de l'accepteur (AcceptorComp). Cet énoncé reflète l'accord requis de l'accepteur pour établir l'appairage. La politique A peut être associée à la location ( compartiment racine) ou à AcceptorComp.

Cette image présente les deux politiques pour les réseaux VCN de régions différentes mais dans une même location.

La politique R et la politique A accordent l'accès à RequestorGrp. La politique D contient toutefois un type de ressource nommé remote-peering-from; la politique A, un type de ressource appelé remote-peering-to. Ensemble, ces politiques permettent à un utilisateur de RequestorGrp d'établir la connexion depuis une connexion d'appairage distant du compartiment du demandeur vers une connexion d'appairage distant du compartiment de l'accepteur. L'appel d'API pour créer la connexion précise ces deux connexions.

Conseil

L'autorisation accordée par la politique R peut déjà être en place si le demandeur dispose d'une autorisation dans une autre politique pour gérer tous les composants de réseau dans RequestorComp. Il peut exister, par exemple, une politique d'administration de réseau générale comme celle-ci : Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorComp. Si le demandeur fait partie du groupe NetworkAdmin, il dispose déjà des autorisations requises couvertes par la politique D (virtual-network-family inclut des connexions d'appairage distant). De plus, si la politique couvre l'ensemble de la location (Allow group NetworkAdmin to manage virtual-network-family in tenancy), le demandeur dispose déjà de toutes les autorisations nécessaires dans les deux compartiments pour établir la connexion. Dans ce cas, la politique A n'est pas obligatoire.

Appairage distant avec une passerelle DRG mise à niveau

Le demandeur et l'accepteur doivent vérifier que les politiques correctes sont en place . Cet exemple présente les politiques d'identité minimales nécessaires pour créer une connexion d'appairage distant interlocation :

Politique D (mise en oeuvre par le demandeur) :

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

Politique A (mise en oeuvre par l'accepteur) :

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>

Appairage local à l'aide d'une passerelle LPG (réseaux en nuage virtuels dans la même location)

Dans ce cas d'utilisation, les deux réseaux en nuage virtuels se trouvent dans la même location. S'ils se trouvent dans des locations différentes, voir plutôt Appairage local à l'aide d'une passerelle LPG (réseaux en nuage virtuels dans des locations différentes).

Les administrateurs des réseaux en nuage virtuels du demandeur et de l'accepteur doivent s'assurer que les politiques correctes sont en place :

Politique D (mise en oeuvre par le demandeur) :
```
Define group requestorGrp as <requestorGroupOcid>
Define compartment requestorComp as <requestorCompartmentOcid>

Allow group requestorGrp to manage local-peering-from in compartment requestorComp
```
Le demandeur fait partie d'un groupe IAM nommé requestorGrp. Cette politique permet à tous les membres du groupe de lancer une connexion à partir de toute passerelle LPG du compartiment du demandeur (requestorComp). La politique R peut être associée à la location ( compartiment racine) ou à requestorComp. Pour des informations sur les raisons pour lesquelles vous l'associez à une location plutôt qu'à l'autre, voir Principes de base des politiques.
Politique A (mise en oeuvre par l'accepteur) :
```
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
```
Les énoncés de la politique permettent au demandeur de se connecter à une passerelle LPG dans le compartiment de l'accepteur (acceptorComp). Cet énoncé reflète l'accord requis de l'accepteur pour établir l'appairage. La politique A peut être associée à la location ( compartiment racine) ou à acceptorComp.

Conseil

Les énoncés de la politique A permettent au demandeur de lister les réseaux en nuage virtuels et les passerelles LPG dans acceptorComp. Les énoncés sont requis pour que le demandeur utilise l'interface utilisateur de la console pour effectuer une sélection dans une liste de réseaux en nuage virtuels et de passerelles LPG dans acceptorComp et établir la connexion. Le diagramme suivant illustre le premier énoncé uniquement, indispensable pour autoriser la connexion.

Cette image présente les deux politiques pour les réseaux VCN d'une même location.

La politique R et la politique A accordent l'accès à requestorGrp. La politique D contient toutefois un type de ressource nommé local-peering-from; la politique A, un type de ressource appelé local-peering-to. Ensemble, ces politiques permettent à un utilisateur de requestorGrp d'établir la connexion depuis une passerelle LPG du compartiment du demandeur vers une passerelle LPG du compartiment de l'accepteur. L'appel d'API pour créer la connexion précise ces deux passerelles.

Conseil

L'autorisation accordée par la politique R peut déjà être en place si le demandeur dispose d'une autorisation dans une autre politique pour gérer tous les composants du service de réseau dans RequestorComp. Il peut s'agir, par exemple, d'une politique d'administration de réseau générale comme celle-ci :

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

Si le demandeur fait partie du groupe NetworkAdmin, il dispose déjà des autorisations requises couvertes par la politique D (virtual-network-family inclut des passerelles LPG). De plus, si la politique couvre l'ensemble de la location au lieu du seul compartiment requestorComp, le demandeur dispose déjà de toutes les autorisations nécessaires dans les deux compartiments pour établir la connexion. Dans ce cas, la politique A n'est pas obligatoire.

Appairage local à l'aide d'une passerelle LPG (réseaux en nuage virtuels dans des locations différentes)

In this use case, the VCNs are in different tenancies (in other words, it's a cross-tenancy peering). Si les réseaux en nuage virtuels se trouvent dans la même location, voir plutôt Appairage local à l'aide d'une passerelle LPG (réseaux en nuage virtuels dans la même location).

Le demandeur et l'accepteur doivent vérifier que les politiques correctes sont en place :

Politique D (mise en oeuvre par le demandeur) :
```
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
```
Le demandeur fait partie d'un groupe IAM avec un OCID affecté que vous fournissez. Cette politique permet à n'importe quel membre du groupe de lancer une connexion à partir de toute passerelle LPG du compartiment du demandeur (requestorComp).

Le premier énoncé est un énoncé Define qui affecte une étiquette conviviale à l'OCID de la location de l'accepteur. Ici, l'énoncé utilise "Acceptor" comme étiquette, mais le demandeur peut choisir la valeur qu'il veut. Tous les énoncés Define d'une politique doivent être les premiers (en haut).

Le deuxième énoncé permet à requestorGrp d'établir une connexion depuis une passerelle LPG du compartiment du demandeur.

Les énoncés Allow et Endorse sont obligatoires car les passerelles LPG figurent dans des locations différentes. Ils permettent à requestorGrp de connecter une passerelle LPG de la location du demandeur à une autre de la location de l'accepteur.

Pour accorder à requestorGrp l'autorisation de se connecter à une passerelle LPG dans n'importe quelle location, la politique pourrait ressembler à ceci :
```
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
```
La politique R doit être obligatoirement associée à la location du demandeur (compartiment racine) et non au compartiment du demandeur. Les politiques qui permettent un accès interlocation doivent être associées à la location. Pour plus d'informations sur l'association des politiques, voir Principes de base des politiques.
Politique A (mise en oeuvre par l'accepteur) :
```
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
```
Comme pour la politique du demandeur, cette politique utilise d'abord des énoncés Define pour affecter des étiquettes conviviales à l'OCID de la location du demandeur et à celui du groupe d'administrateurs du demandeur. Comme mentionné ci-dessus, l'accepteur peut utiliser d'autres valeurs pour ces étiquettes, s'il le souhaite.

Les quatrième et cinquième énoncés permettent à requestorGrp de se connecter à une passerelle LPG du compartiment de l'accepteur (acceptorComp). Ces énoncés reflètent l'accord indispensable à l'établissement de l'appairage. Le mot Admit indique que l'accès s'applique à un groupe en dehors de la location où réside la politique.

La politique A doit être associée à la location de l'accepteur (compartiment racine) et non au compartiment de celui-ci.

Cette image présente l'emplacement des deux politiques pour les réseaux VCN dans des locations différentes.

Attachement à des réseaux en nuage virtuels dans la même location

Si vous voulez que le groupe d'administrateurs de VCN crée et gère des attachements de VCN et affecte des tables de routage DRG à ceux-ci, mettez en oeuvre la politique suivante :

define group VcnAdmin as <vcnAdminGroupOcid>

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

Note

Pour associer une table de routage de VCN à l'attachement, ajoutez cette ligne supplémentaire :

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

Attachement à des réseaux en nuage virtuels dans d'autres locations

Les "attachements interlocation" sont des attachements de VCN spéciaux utilisés pour connecter une passerelle DRG directement à un VCN d'une autre location, mais hébergés dans la même région. Le VCN ne sera pas attaché à une passerelle DRG dans sa propre location. L'exemple de politique ci-dessous détaille les exigences minimales de politique IAM pour les deux locations afin d'autoriser ce type de connexion.

Cet exemple d'un jeu de politiques permet d'effectuer les actions suivantes :

Les administrateurs de passerelle DRG du client DRG peuvent créer un attachement dans le client VCN.
Les administrateurs de VCN du locataire VCN peuvent associer une table de routage de VCN à l'attachement (utilisé lorsque le VCN attaché est un VCN de transit). Si l'administrateur du VCN a une politique pour gérer toutes les ressources du locataire de VCN, il dispose déjà de cette capacité, car l'attachement de VCN réside dans la location du VCN.
Les administrateurs de réseau VCN ne peuvent pas modifier l'association de la table de routage DRG pour l'attachement DRG.

Politique R (DRG dans cette location)

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 est l'OCID du groupe vcnAdmin qui se trouve dans la location de l'accepteur et endossé dans la politique de l'accepteur.

Politique A (VCN dans cette location)

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 est l'OCID du groupe drgAdmin qui se trouve dans la location du demandeur et endossé dans la politique du demandeur.

Documentation sur Oracle Cloud Infrastructure