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

Contrôle de l'établissement des appairages

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

• Les utilisateurs pouvant abonner votre location à une autre région (requis pour l'appairage à distance de réseaux cloud virtuels).
• Qui dans une organisation est autorisé à établir des homologues VCN (par exemple, reportez-vous aux stratégies IAM dans Configuration d'un appairage local et Configuration d'un appairage distant). La suppression de ces stratégies IAM n'a aucune incidence sur les appairages existants, mais uniquement sur la possibilité de création d'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 dans une autre location (qui peut appartenir à votre organisation, à Oracle ou à un tiers), des instructions de stratégie spéciales sont nécessaires pour activer l'appairage inter-locations. Dans les instructions, vous pouvez indiquer quelle location particulière. Pour obtenir un 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 distant (é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 les deux se trouver dans la même 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.

Le contrat prend la forme de stratégies Oracle Cloud Infrastructure Identity and Access Management que chaque partie implémente pour son compartiment ou sa location VCN. 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 se connecter à 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 activités qu'un groupe dans votre location peut effectuer dans d'autres emplacements. L'instruction Endorse appartient toujours à la location contenant le groupe d'utilisateurs qui franchit les limites de l'autre location pour utiliser ses ressources. Dans les exemples, nous appelons cette location la location source.
• Admit : indique le type de capacité possible dans votre location que vous voulez octroyer à un groupe d'une autre location. L'instruction Admit appartient à la location octroyant l'octroi de l'admission à la location. L'instruction Admit identifie le groupe d'utilisateurs nécessitant l'accès aux ressources à partir de la location source, ce dernier étant identifié par une instruction Endorse correspondante. Dans les exemples, nous appelons cette location 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 s'accorder sur l'accès.

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 aient les stratégies de corect en place. Il s'agit des stratégies suivantes :

• 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 à tous les membres du groupe de démarrer une connexion à partir de n'importe quel DRG dans le compartiment du demandeur (RequestorComp). La stratégie R peut être attachée à la location (compartiment racine) ou à RequestorComp. Pour savoir pourquoi vous l'attacheriez à un ou à l'autre compartiment, reportez-vous à la section Notions de base relatives aux règles.

• 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 quel service 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.

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 à tout membre de RequestorGrp d'établir la connexion à partir d'un RPC dans le compartiment du demandeur vers un RPC dans le compartiment de l'accepteur. L'appel d'API de création de la connexion précise les deux RPC concernés.

Appairage à distance avec un DRG mis à niveau

Le demandeur et l'accepteur doivent tous deux vérifier que des 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 se trouvent 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 demandeur et accepteur doivent s'assurer que les stratégies nécessaires 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 à tous les membres du groupe de démarrer une connexion à partir de n'importe quelle passer d'appairage local 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 à un ou à l'autre compartiment, reportez-vous à la section Notions de base relatives aux politiques.

• 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 passerelle d'appairage local 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 contenues dans la stratégie A permettent au demandeur d'afficher la liste des réseaux cloud virtuels et des passerelles d'appairage local dans acceptorComp. Les instructions sont nécessaires pour que le demandeur puissent utiliser l'interface utilisateur de la console afin de faire une sélection dans une liste de réseaux cloud virtuels et de passerelles d'appairage local dans acceptorComp et d'établir la connexion. Le diagramme suivant présente uniquement la première instruction, celle qui permet la connexion (la plus importante)

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 à un membre de requestorGrp d'établir la connexion à partir d'une passerelle d'appairage local du compartiment du demandeur vers une passerelle d'appairage local 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.

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

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 (il s'agit donc d'un appairage inter-location). Si les réseaux cloud virtuels se trouvent dans la même location, reportez-vous à Appairage local à l'aide d'une passerelle d'appairage local (VCN dans la même location).

Le demandeur et l'accepteur doivent tous deux vérifier que des 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 à tous les membres de ce groupe de démarrer une connexion à partir de n'importe quelle Passerelle d'appairage local 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. Toutes les instructions Define d'une stratégie doivent être les premières (en haut)

  La deuxième instruction permet à requestorGrp d'établir une connexion à partir d'une passerelle d'appellation d'origine du compartiment du demandeur.

  Les instructions Allow et Endorse 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'appairage local dans la location du demandeur à une dernière dans la location de l'accepteur.

  Si l'objectif est d'autoriser requestorGrp à se connecter à une passerelle d'appairage local de n'importe quelle location, la stratégie se présente 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 de 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 à requestorGrp de se connecter à une passerelle d'appairage local 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.

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

Si vous voulez que le groupe d'administrateurs VCN crée et gère des pièces jointes VCN et affecte des tables de routage DRG aux pièces jointes, 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

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

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

Les "attachements inter-locations" 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 est attaché à un DRG dans une location distincte. L'exemple de stratégie qui suit détaille les exigences de stratégie IAM minimales 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 dans le 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 VCN ne peuvent pas modifier l'association de table de routage DRG pour la pièce jointe DRG.

• 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 dans la location Acceptor et approuvé dans la stratégie Acceptor.

• 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 dans la location du demandeur et endossé dans la stratégie du demandeur.