Políticas de IAM para el enrutamiento entre redes virtuales en la nube

Obtenga información sobre las políticas de IAM utilizadas con gateways de intercambio de tráfico y enrutamiento dinámico.

Para obtener más información sobre las políticas de IAM utilizadas en las redes, consulte Políticas de IAM para las redes.

Para conocer las políticas de IAM específicas para el intercambio de tráfico local o remoto mediante DRG, consulte:

Para conocer las políticas de IAM específicas para el intercambio de tráfico local mediante LPG, consulte:

Para conocer las políticas de IAM específicas para asociar DRG y VCN, consulte:

Control del establecimiento de intercambios

Con las políticas de IAM, puede controlar:

Quién puede suscribir su arrendamiento a otra región (requerido para el intercambio de tráfico remoto de VCN).
Quién en su organización tiene autoridad para establecer intercambios de VCN (por ejemplo, ver las políticas de IAM en Configuración de un Intercambio de tráfico local y Configuración de un intercambio de tráfico remoto). La supresión de estas políticas de IAM no afectará a ninguno de los intercambios de tráfico existentes, solo a la capacidad de crear intercambios de tráfico futuros.
Para el intercambio de VCN local a través de un DRG asociado mutuamente en el mismo arrendamiento y región, no se necesitan políticas de IAM especiales. Si el intercambio de tráfico se puede producir con redes virtuales en un arrendamiento diferente (que podría pertenecer a su organización, a Oracle o a un tercero), se necesitarían sentencias de política especiales para activar el intercambio de tráfico entre arrendamientos. En las sentencias, puede especificar qué arrendamiento concreto. Para el intercambio de VCN local a través de un DRG asociado mutuamente en un arrendamiento diferente pero en la misma región, consulte Asociación a CNV en otros arrendamientos. Para el intercambio de VCN remoto (posiblemente a un arrendamiento diferente), consulte Intercambio de tráfico remoto con un DRG heredado.
Quién puede gestionar tablas de rutas y listas de seguridad.

Acuerdo explícito necesario por ambas partes

El intercambio de tráfico y el enrutamiento en tránsito implican dos VCN propiedad de la misma parte o de dos diferentes. Las dos partes pueden estar en su compañía, pero en diferentes departamentos. O bien las dos partes podrían estar en compañías completamente diferentes (por ejemplo, en un modelo de proveedor de servicios). Consulte Acceso a recursos de Object Storage entre arrendamientos para obtener más ejemplos de políticas entre arrendamientos.

El acuerdo tiene un formato de políticas de Oracle Cloud Infrastructure Identity and Access Management que cada parte implanta para el compartimento o el arrendamiento de su propia VCN. Si las VCN están en diferentes arrendamientos, cada administrador debe proporcionar su OCID del arrendamiento y poner en marcha sentencias de políticas especiales para activar el intercambio de tráfico. Para obtener más información sobre las políticas de IAM necesarias para conectarse a una VCN de otro arrendamiento, consulte Intercambio de tráfico remoto con un DRG actualizado.

Sentencias Endorse, Admit y Define

Esta es una visión general de los verbos utilizados en estas sentencias:

Endorse: determina el juego general de capacidades que un grupo de su propio arrendamiento puede realizar en otros arrendamientos. La sentencia Endorse siempre corresponde al arrendamiento que contiene el grupo de usuarios que cruzan los límites a otro arrendamiento para trabajar con los recursos de dicho arrendamiento. En los ejemplos, hacemos referencia a este arrendamiento como el arrendamiento de origen.
Admit: determina el tipo de capacidad de su propio arrendamiento que desea otorgar a un grupo del otro arrendamiento. La sentencia Admit corresponde al arrendamiento que otorga la "admisión" en el arrendamiento. La sentencia Admit identifica el grupo de usuarios que requieren acceso al recurso desde el arrendamiento de origen y que se identifica con la sentencia Endorse correspondiente. En los ejemplos, hacemos referencia a este arrendamiento como el arrendamiento de destino.
Define: asigna un alias local a un OCID de arrendamiento para las sentencias de política Endorse y Admit. También se necesita una sentencia Define en el arrendamiento de destino para asignar un alias al OCID del grupo de IAM de origen para las sentencias Admit.

Incluya una sentencia Define en la misma entidad de política que la sentencia Endorse o Admit.

Las sentencias Endorse y Admit funcionan juntas. Una sentencia Endorse reside en el arrendamiento de origen mientras que una sentencia Admit reside en el arrendamiento de destino. Sin una sentencia correspondiente que especifique el acceso, una sentencia Endorse o Admit en particular no otorga acceso. Ambos arrendamientos deben aceptar el acceso.

Importante

Además de las sentencias de política, también debe suscribirse a una región para compartir recursos entre regiones.

Intercambio de tráfico remoto con un DRG heredado

Un DRG se puede conectar a otro DRG (y cualquier VCN asociada) en otra región siempre que los compartimentos que contienen el solicitante y el aceptante tengan las políticas adecuadas. Constan de lo siguiente:

Política R (implantada por el solicitante):
```
Define group RequestorGrp as <requestorGroupOcid>
Define compartment RequestorComp as <RequestorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-from in compartment RequestorComp
```
The requestor is in an IAM group called RequestorGrp. Esta política permite a cualquier usuario del grupo iniciar una conexión desde cualquier DRG del compartimento del solicitante (RequestorComp). La política R se puede asociar al arrendamiento ( compartimento raíz) o a RequestorComp. Para obtener más información sobre por qué se debe asociar a uno o a otro, consulte Aspectos básicos de políticas.
Política A (implantada por el aceptante):
```
Define group RequestorGrp as <requestorGroupOcid>
Define compartment AcceptorComp as <AcceptorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-to in compartment AcceptorComp
```
Esta política permite al solicitante conectarse a cualquier RPC del compartimento del aceptante (AcceptorComp). Esta declaración refleja el acuerdo requerido del aceptante para establecer el intercambio de tráfico. La política A se puede asociar al arrendamiento (compartimiento raíz) o a AcceptorComp.

En esta imagen se muestran las dos políticas de las VCN en distintas regiones, pero en el mismo arrendamiento.

La política R y la política A otorgan acceso a RequestorGrp. Sin embargo, la Política R tiene un tipo de recurso denominado remote-peering-from y la Política A tiene un tipo de recurso denominado remote-peering-to. En conjunto, estas políticas permiten a alguien de RequestorGrp establecer la conexión desde una RPC del compartimento del solicitante a una RPC del compartimento del aceptante. La llamada de la API para crear realmente la conexión especifica las dos RPC.

Sugerencia

Es posible que el permiso otorgado por la Política R ya esté vigente si el solicitante tiene permiso en otra política para gestionar todos los componentes de Networking de RequestorComp. Por ejemplo, puede haber una política general de administración de red como la siguiente: Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorComp. Si el solicitante está en el grupo NetworkAdmin, ya tienen los permisos necesarios cubiertos en la Política R (la familia de red virtual incluye las RPC). Además, si la política se escribe para cubrir el todo el arrendamiento (Allow group NetworkAdmin to manage virtual-network-family in tenancy), el solicitante ya tiene todos los permisos necesarios en ambos compartimentos para establecer la conexión. En ese caso, la Política A no es necesaria.

Intercambio de tráfico remoto con un DRG actualizado

El solicitante y el aceptante deben garantizar que se apliquen las políticas correctas. En este ejemplo se muestran las políticas de identidad mínimas necesarias para crear una conexión con intercambio de tráfico remoto entre arrendamientos:

Política R (implantada por el solicitante):

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

Política A (implantada por el aceptante):

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>

Intercambio de tráfico local mediante un LPG (VCN en el mismo arrendamiento)

En este caso de uso, ambas VCN están en el mismo arrendamiento. Si se encuentran en arrendamientos diferentes, consulte Intercambio de tráfico local mediante un LPG (VCN en arrendamientos diferentes).

Los administradores de las VCN del solicitante y del aceptante deben garantizar que se apliquen las políticas correctas:

Política R (implantada por el solicitante):
```
Define group requestorGrp as <requestorGroupOcid>
Define compartment requestorComp as <requestorCompartmentOcid>

Allow group requestorGrp to manage local-peering-from in compartment requestorComp
```
The requestor is in an IAM group called requestorGrp. Esta política permite a cualquier usuario del grupo iniciar una conexión desde cualquier LPG del compartimento del solicitante (requestorComp). La política R se puede asociar al arrendamiento ( compartimento raíz) o a requestorComp. Para obtener más información sobre por qué se debe asociar a uno o a otro, consulte Aspectos básicos de políticas.
Política A (implantada por el aceptante):
```
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
```
Las sentencias de la política permiten al solicitante conectarse a cualquier LPG del compartimento del aceptante (acceptorComp). Esta declaración refleja el acuerdo requerido del aceptante para establecer el intercambio de tráfico. La política A se puede asociar al arrendamiento (compartimiento raíz) o a acceptorComp.

Consejo

Las sentencias de la política A permiten al solicitante mostrar las VCN y los LPG en acceptorComp. Las sentencias son necesarias para que el solicitante utilice la interfaz de usuario de la consola para seleccionar de una lista de VCN y LPG en acceptorComp y establecer la conexión. El siguiente diagrama se centra solo en la primera sentencia, que es la crítica que permite la conexión.

En esta imagen se muestran las dos políticas de las VCN en el mismo arrendamiento.

La política R y la política A otorgan acceso a requestorGrp. Sin embargo, la Política R tiene un tipo de recurso denominado local-peering-from y la Política A tiene un tipo de recurso denominado local-peering-to. En conjunto, estas políticas permiten a alguien de requestorGrp establecer la conexión desde un LPG del compartimento del solicitante a un LPG del compartimento del aceptante. La llamada de la API para crear la conexión especifica los dos LPG.

Consejo

Es posible que el permiso otorgado por la política R ya esté vigente si el solicitante tiene permiso en otra política para gestionar todos los componentes de Networking en RequestorComp. Por ejemplo, puede haber una política de administrador de red general como esta:

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

Si el solicitante está en el grupo NetworkAdmin, ya tiene los permisos necesarios cubiertos en la Política R (la familia de red virtual incluye los LPG). Además, si la política se escribe para todo el arrendamiento en lugar de solo el compartimento requestorComp, el solicitante ya tiene todos los permisos necesarios en ambos compartimentos para establecer la conexión. En ese caso, la Política A no es necesaria.

Intercambio de tráfico local mediante un LPG (VCN en distintos arrendamientos)

En este caso de uso, las VCN están en arrendamientos diferentes (es decir, es un intercambio de tráfico entre arrendamientos). Si las CN están en el mismo arrendamiento, consulte Intercambio de tráfico local mediante un LPG (VCN en el mismo arrendamiento).

El solicitante y el aceptante deben garantizar que se apliquen las políticas correctas:

Política R (implantada por el solicitante):
```
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
```
El solicitante está en un grupo de IAM con un OCID asignado que proporcione. Esta política permite a cualquier usuario de ese grupo iniciar una conexión desde cualquier LPG del compartimento del solicitante (requestorComp).

La primera sentencia es una sentencia "define" que asigna una etiqueta fácil de recordar al OCID de arrendamiento del aceptante. La sentencia utiliza "Acceptor" como etiqueta, pero podría ser un valor de la elección del solicitante. Todas las sentencias "define" de una política deben ser las primeras (en la parte superior).

La segunda sentencia permite a requestorGrp establecer una conexión desde un LPG en el compartimento del solicitante.

Las sentencias "Allow" y "Endorse" son especiales porque los LPG están en diferentes arrendamientos. Permiten a requestorGrp conectar un LP en el arrendamiento del solicitante a un LP en el arrendamiento del aceptante.

Si la intención es otorgar permiso a requestorGrp para que se conecte a un LPG de cualquier arrendamiento, la política tendría este aspecto en su lugar:
```
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
```
Independientemente de esto, la política R se debe asociar al arrendamiento del solicitante (compartimiento raíz) y no al compartimiento del solicitante. Las políticas que permiten el acceso entre arrendamientos deben asociarse al arrendamiento. Para obtener más información sobre la asociación de políticas, consulte Aspectos básicos de políticas.
Política A (implantada por el aceptante):
```
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
```
De forma similar a la política del solicitante, esta política utiliza primero las sentencias "define" para asignar etiquetas fáciles de recordar al OCID del arrendamiento del solicitante y al OCID del grupo de administradores del solicitante. Como se ha mencionado anteriormente, el aceptante podría utilizar otros valores para esas etiquetas, si así lo desea.

Las sentencias cuarta y quinta permiten a requestorGrp conectarse a un LPG del compartimento del aceptante (acceptorComp). Estas sentencias reflejan el acuerdo crítico necesario para establecer el intercambio de tráfico. La palabra Admit indica que el acceso se aplica a un grupo fuera del arrendamiento en el que se encuentra la política.

La política A se debe asociar al arrendamiento del aceptante (compartimiento raíz) y no al compartimiento del aceptante.

En esta imagen se muestra la ubicación de las dos políticas para las VCN de distintos arrendamientos.

Asociación a VCN en el mismo arrendamiento

Si desea que el grupo de administradores de VCN cree y gestione asociaciones de VCN y asigne tablas de rutas de DRG a las asociaciones, implemente la siguiente política:

define group VcnAdmin as <vcnAdminGroupOcid>

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

Nota

Para asociar una tabla de rutas de VCN a la asociación, agregue esta línea adicional:

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

Asociación a redes virtuales en la nube en otros arrendamientos

Las "asociaciones entre arrendamientos" son asociaciones de VCN especiales que se utilizan para conectar un DRG directamente a una VCN de otro arrendamiento pero que se alojan en la misma región. La VCN no se asociará a un DRG en su propio arrendamiento. La siguiente política de ejemplo detalla los requisitos mínimos de política de IAM para que ambos arrendamientos permitan este tipo de conexión.

Este ejemplo de un juego de políticas permite el siguiente juego de acciones:

Los administradores de DRG del cliente de DRG pueden crear una asociación de DRG en el cliente de VCN.
Los administradores de VCN del inquilino de VCN pueden asociar una tabla de rutas de VCN a la asociación (se utiliza cuando la VCN asociada es una VCN de tránsito). Si el administrador de VCN tiene una política para gestionar todos los recursos del inquilino de VCN, ya tiene esta capacidad, porque la asociación de VCN reside en el arrendamiento de VCN.
Los administradores de VCN no tienen la capacidad de cambiar la asociación de tabla de rutas de DRG para la asociación de DRG.

Política R (DRG en este arrendamiento)

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 es el OCID del grupo vcnAdmin que está en el arrendamiento de Acceptor y que está avalado en la política de Acceptor.

Política A (VCN en este arrendamiento)

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 es el OCID del grupo drgAdmin que está en el arrendamiento del solicitante y está avalado en la política del solicitante.

Documentación de Oracle Cloud Infrastructure