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

Contrôle de l'établissement des appairages

Avec les politiques IAM, 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, est autorisé à établir des appairage de VCN (par exemple, voir les politiques IAM sous Configuration d'un appairage local et Configuration d'un appairage distant). La suppression de ces politiques IAM n'a aucune incidence sur les appairages existants, seule la possibilité de 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 Oracle Cloud Infrastructure Identity and Access Management que chaque partie met en oeuvre pour le compartiment ou la location de son propre 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 d'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.

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) :

  Copier

  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) :

  Copier

  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.

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.

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) :

  Copier

  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) :

  Copier

  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) :

  Copier

  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) :

  Copier

  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.

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.

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

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

Dans ce cas d'utilisation, les réseaux en nuage virtuels se trouvent dans différentes locations (en d'autres termes, il s'agit d'un appairage interlocation). 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) :

  Copier

  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 :

  Copier

  
  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) :

  Copier

  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.

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

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)

  Copier

  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)

  Copier

  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.