Stratégies IAM pour le routage entre réseaux cloud virtuels

Découvrez les stratégies IAM utilisées avec l'appairage et les passerelles de routage dynamique.

Pour obtenir des stratégies IAM plus générales utilisées dans les fonctions de réseau, reportez-vous à Stratégies IAM pour les fonctions de réseau.

Pour les stratégies IAM propres à l'appairage local ou distant à l'aide de passerelles de routage dynamique, reportez-vous aux sections suivantes :

Pour les stratégies IAM propres à l'appairage local à l'aide de passerelles d'appairage local, reportez-vous aux sections suivantes

Pour les stratégies IAM propres à l'attachement de passerelles de routage dynamique et de réseaux cloud virtuels, reportez-vous aux sections suivantes :

Contrôle de l'établissement des appairages

Avec les stratégies IAM, vous pouvez contrôler les éléments suivants :

Les utilisateurs pouvant abonner votre location à une autre région (requis pour l'appairage à distance de réseaux cloud virtuels).
Les utilisateurs de votre organisation ayant l'autorisation d'établir des appairages de réseaux cloud virtuels (reportez-vous par exemple aux stratégies IAM dans Configuration d'un appairage local et Configuration d'un appairage à distance). La suppression de ces stratégies IAM n'a aucune incidence sur les appairages existants, mais seulement sur la possibilité de créer des appairages ultérieurs.
Pour l'appairage VCN local via un DRG mutuellement attaché dans la même location et région, aucune stratégie IAM spéciale n'est nécessaire. Si l'appairage peut avoir lieu avec des réseaux cloud virtuels d'une autre location (qui peut appartenir à votre organisation, à Oracle ou à un tiers), des instructions de stratégie spéciales sont requises pour activer l'appairage inter-location. Dans les instructions, vous pouvez indiquer quelle location particulière. Pour l'appairage VCN local via un DRG mutuellement attaché dans une autre location mais dans la même région, reportez-vous à Attachement à des réseaux cloud virtuels dans d'autres locations. Pour l'appairage VCN à distance (éventuellement vers une autre location), reportez-vous à Appairage à distance avec un DRG hérité.
Les utilisateurs pouvant gérer les tables de routage et les listes de sécurité.

Accord explicite des deux parties requis

L'appairage et le routage de transit impliquent deux réseaux cloud virtuels appartenant à la même partie ou à deux parties différentes. Les deux parties peuvent toutes deux se trouver dans votre société mais dans des services différents. Elles peuvent également être dans des sociétés totalement différentes (c'est le cas dans un modèle de fournisseur de services par exemple). Pour plus d'exemples de stratégie inter-locataire, reportez-vous à Accès aux ressources Object Storage dans des locations.

L'accord prend la forme de stratégies Oracle Cloud Infrastructure Identity and Access Management que chaque partie implémente pour le compartiment ou la location de son propre réseau cloud virtuel. Si les réseaux cloud virtuels se trouvent dans des locations différentes, chaque administrateur doit fournir l'OCID de location et mettre en place des instructions de stratégie spéciales pour permettre l'appairage. Pour plus de détails sur les stratégies IAM requises pour la connexion à un VCN dans une autre location, reportez-vous à Appairage à distance avec un DRG mis à niveau.

Instructions Endorse, Admit et Define

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

Endorse : présente l'ensemble général des actions qu'un groupe de votre location peut effectuer dans d'autres locations. L'instruction Endorse appartient toujours à la location contenant le groupe d'utilisateurs qui accède à l'autre location pour utiliser ses ressources. Dans les exemples, nous désignons cette location comme la location source.
Admit : indique le type de d'action possible dans votre location que vous voulez octroyer à un groupe d'une autre location. L'instruction Admit appartient à la location octroyant l'"admission". L'instruction Admit identifie le groupe d'utilisateurs nécessitant un accès aux ressources à partir de la location source, ce groupe étant identifié par une instruction Endorse correspondante. Dans les exemples, nous désignons cette location comme la location de destination.
Define : affecte un alias local à un OCID de location pour les instructions de stratégie Endorse et Admit. Une instruction Define est également requise dans la location de destination afin d'affecter un alias à l'OCID de groupe IAM source pour les instructions Admit.

Incluez une instruction Define dans la même entité de stratégie que l'instruction Endorse ou Admit.

Les instructions Endorse et Admit sont utilisées conjointement. Une instruction Endorse réside dans la location source tandis qu'une instruction Admit réside dans la location de destination. Sans instruction correspondante définissant l'accès, une instruction Endorse ou Admit particulière n'accorde aucun accès. Les deux locations doivent se mettre d'accord sur l'accès.

Important

En plus d'utiliser des instructions de stratégie, vous devez également vous abonner à une région pour partager des ressources entre les régions.

Appairage à distance avec un DRG hérité

Un DRG peut se connecter à un autre DRG (et à tout VCN attaché) dans une autre région à condition que les compartiments contenant le demandeur et l'accepteur disposent des stratégies appropriées. Il s'agit :

Stratégie R (implémentée 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 appartient à un groupe IAM appelé RequestorGrp. Cette stratégie permet à tout membre du groupe de lancer une connexion à partir de n'importe quel DRG du compartiment du demandeur (RequestorComp). La stratégie R peut être attachée à la location ( compartiment racine) ou à RequestorComp. Pour savoir pourquoi vous l'attacheriez à l'un ou à l'autre, reportez-vous à Notions de base relatives aux stratégies.
Stratégie A (implémentée 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 stratégie permet au demandeur de se connecter à n'importe quelle RPC du compartiment de l'accepteur (AcceptorComp). Cette instruction correspond à l'accord qui doit être obtenu de l'accepteur pour que l'appairage soit établi. La stratégie A peut être attachée à la location ( compartiment racine) ou à AcceptorComp.

Cette image montre les deux stratégies pour des réseaux cloud virtuels se trouvant dans des régions différentes mais dans la même location.

Les stratégies R et A donnent un accès à RequestorGrp. Cependant, la stratégie R comporte un type de ressource appelé remote-peering-from et la stratégie A un type de ressource appelé remote-peering-to. Ensemble, ces stratégies permettent à toute personne dans RequestorGrp d'établir la connexion à partir d'une RPC du compartiment du demandeur vers une RPC du compartiment de l'accepteur. L'appel API de création de la connexion précise les deux connexions d'appairage à distance concernées.

Conseil

Le droit d'accès accordé par la stratégie R est peut-être déjà en place si le demandeur est autorisé dans une autre stratégie à gérer tous les composants de Networking de RequestorComp. Par exemple, il peut y avoir une stratégie générale d'administration réseau comme ceci : Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorComp. Si le demandeur appartient au groupe NetworkAdmin, il dispose déjà des droits d'accès requis inclus dans la stratégie R (virtual-network-family inclut les connexions d'appairage à distance). En outre, si la stratégie est écrite pour couvrir l'ensemble de la location (Allow group NetworkAdmin to manage virtual-network-family in tenancy), le demandeur dispose déjà de tous les droits d'accès requis dans les deux compartiments pour établir la connexion. Dans ce cas, la stratégie A n'est pas requise.

Appairage à distance avec un DRG mis à niveau

Le demandeur et l'accepteur doivent vérifier que les stratégies appropriées sont en place . Cet exemple présente les stratégies d'identité minimales requises pour créer une connexion d'appairage à distance inter-location :

Stratégie R (implémentée 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

Stratégie A (implémentée 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 d'appairage local (réseaux cloud virtuels dans la même location)

Dans ce cas d'emploi, les deux réseaux cloud virtuels se trouvent dans la même location. S'ils résident dans des locations différentes, reportez-vous à Appairage local à l'aide d'une passerelle d'appairage local (réseaux cloud virtuels dans des locations différentes).

Les administrateurs des réseaux cloud virtuels du demandeur et de l'accepteur doivent vérifier que les stratégies appropriées sont en place :

Stratégie R (implémentée 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 appartient à un groupe IAM appelé requestorGrp. Cette stratégie permet à tout membre du groupe de lancer une connexion à partir de n'importe quelle GPL du compartiment du demandeur (requestorComp). La stratégie R peut être attachée à la location ( compartiment racine) ou à requestorComp. Pour savoir pourquoi vous l'attacheriez à l'un ou à l'autre, reportez-vous à Notions de base relatives aux stratégies.
Stratégie A (implémentée 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 instructions de la stratégie permettent au demandeur de se connecter à n'importe quelle d'elles du compartiment de l'accepteur (acceptorComp). Cette instruction correspond à l'accord qui doit être obtenu de l'accepteur pour que l'appairage soit établi. La stratégie A peut être attachée à la location ( compartiment racine) ou à acceptorComp.

Conseil

Les instructions de la stratégie A permettent au demandeur de répertorier les réseaux cloud virtuels et les passerelles d'accès d'accès d'accès d'accès local dans acceptorComp. Les instructions sont nécessaires pour que le demandeur puisse utiliser l'interface utilisateur de la console afin de procéder à une sélection dans la liste des réseaux cloud virtuels et des PG dans acceptorComp et d'établir la connexion. Le diagramme suivant présente uniquement la première instruction, celle qui autorise la connexion (la plus importante).

Cette image montre les deux stratégies pour des réseaux cloud virtuels se trouvant dans la même location.

Les stratégies R et A donnent un accès à requestorGrp. Cependant, la stratégie R comporte un type de ressource appelé local-peering-from et la stratégie A un type de ressource appelé local-peering-to. Ensemble, ces stratégies permettent à toute personne dans requestorGrp d'établir la connexion à partir d'une passerelle d'accès de niveau supérieur du compartiment du demandeur vers une passerelle d'accès de niveau supérieur du compartiment de l'accepteur. L'appel d'API de création de la connexion précise les deux passerelles d'appairage local concernées.

Conseil

Le droit d'accès accordé par la stratégie R est peut-être déjà en place si le demandeur est autorisé dans une autre stratégie à gérer tous les composants de Networking de RequestorComp. Par exemple, une stratégie générale d'administration réseau telle que celle-ci peut exister :

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

Si le demandeur appartient au groupe NetworkAdmin, il dispose déjà des droits d'accès requis inclus dans la stratégie R (virtual-network-family inclut les passerelles d'appairage local). En outre, si la stratégie est écrite pour couvrir l'ensemble de la location plutôt que le compartiment requestorComp uniquement, le demandeur dispose déjà de tous les droits d'accès requis dans les deux compartiments pour établir la connexion. Dans ce cas, la stratégie A n'est pas requise.

Appairage local à l'aide d'une passerelle d'appairage local (réseaux cloud virtuels dans différentes locations)

Dans ce cas d'emploi, les réseaux cloud virtuels se trouvent dans des locations différentes (en d'autres termes, il s'agit d'un appairage inter-location). S'ils appartiennent à la même location, reportez-vous à Appairage local à l'aide d'une passerelle d'appairage local (réseaux cloud virtuels dans la même location).

Le demandeur et l'accepteur doivent vérifier que les stratégies appropriées sont en place :

Stratégie R (implémentée 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 se trouve dans un groupe IAM avec un OCID affecté que vous fournissez. Cette stratégie permet à tout membre de ce groupe de lancer une connexion à partir de n'importe quelle GPL du compartiment du demandeur (requestorComp).

La première instruction est une instruction "define" qui affecte un libellé convivial à l'OCID de location de l'accepteur. L'instruction utilise "Acceptor" comme libellé, mais le demandeur peut choisir une autre valeur. Les instructions "define" doivent toujours se situer en tête (en haut) de la stratégie.

La deuxième instruction permet à l'instance requestorGrp d'établir une connexion à partir d'une passerelle d'accès d'ensemble d'extension du compartiment du demandeur.

Les instructions "Allow" (Autoriser) et "Endorse" (Approuver) sont des instructions spéciales requises car les passerelles d'appairage local se trouvent dans des locations différentes. Elles permettent à requestorGrp de connecter une passerelle d'extension dans la location du demandeur à une passerelle d'extension dans la location de l'accepteur.

Si l'objectif est d'accorder à requestorGrp le droit d'accès permettant de se connecter à une gestion d'accès de type LPG dans n'importe quelle location, la stratégie se présentera plutôt comme suit :
```
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
```
Quel que soit le cas, la stratégie R doit être attachée à la location du demandeur (compartiment racine) et non à son compartiment. Les stratégies qui autorisent l'accès inter-location doivent être attachées à la location. Pour plus d'informations sur l'attachement de stratégies, reportez-vous à Notions de base relatives aux stratégies.
Stratégie A (implémentée 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 celle du demandeur, cette stratégie utilise d'abord des instructions "define" pour affecter des libellés conviviaux aux OCID de location du demandeur et du groupe d'administrateurs du demandeur. Comme mentionné précédemment, l'accepteur peut utiliser si nécessaire d'autres valeurs pour ces libellés.

Les quatrième et cinquième instructions permettent à l'instance requestorGrp de se connecter à une passerelle d'accès d'ensemble d'extension du compartiment de l'accepteur (acceptorComp). Ces instructions correspondent à l'accord qui doit impérativement être obtenu pour que l'appairage soit établi. Le mot Admit indique que l'accès s'applique à un groupe en dehors de la location où réside la stratégie.

La stratégie A doit être attachée à la location de l'accepteur (compartiment racine) et non à son compartiment.

Cette image montre l'emplacement des deux stratégies pour des réseaux cloud virtuels se trouvant dans des locations différentes.

Connexion à des réseaux cloud virtuels dans la même location

Si vous souhaitez que le groupe d'administrateurs VCN crée et gère des attachements VCN et affecte des tables de routage DRG aux attachements, implémentez la stratégie suivante :

define group VcnAdmin as <vcnAdminGroupOcid>

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

Remarque

Pour associer une table de routage VCN à la pièce jointe, ajoutez la ligne supplémentaire suivante :

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

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

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

Cet exemple d'ensemble de stratégies autorise les actions suivantes :

Les administrateurs DRG du locataire DRG peuvent créer un attachement DRG dans le locataire VCN.
Les administrateurs de réseau cloud virtuel du locataire de réseau cloud virtuel peuvent associer une table de routage de réseau cloud virtuel à l'attachement (utilisée lorsque le réseau attaché est un réseau cloud virtuel de transit). Ils sont déjà en mesure de le faire s'ils disposent d'une stratégie permettant de gérer toutes les ressources du locataire de réseau cloud virtuel, car l'attachement de réseau cloud virtuel réside dans la location de réseau cloud virtuel.
Les administrateurs de réseau cloud virtuel n'ont pas la possibilité de modifier l'association de table de routage de passerelle de routage dynamique pour l'attachement de passerelle de routage dynamique.

Stratégie 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 d'accepteur et approuvé dans la stratégie d'accepteur.

Stratégie 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 approuvé dans la stratégie du demandeur.

Documentation Oracle Cloud Infrastructure