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 políticas de IAM más generales utilizadas en las redes, consulte Políticas de IAM para Networking.

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

Para conocer las políticas de IAM específicas del 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 necesita ninguna política de IAM especial. Si el intercambio de tráfico se puede producir con VCN en un arrendamiento diferente (que puede pertenecer a su organización, a Oracle o a un tercero) requeriría 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 redes virtuales en la nube 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`

A continuación, se muestra 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 pertenece 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 pertenece al arrendamiento que otorga la "admisión". 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 a cualquier VCN asociada) de 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
```
El solicitante está en un grupo de IAM denominado 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 ( compartimento 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 llamado remote-peering-from y la Política A tiene un tipo de recurso llamado remote-peering-to. En conjunto, estas políticas permiten a un usuario 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 esta: 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 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 (VCNs in the Same Tenancy)

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

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
```
El solicitante está en un grupo de IAM denominado 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 ( compartimento 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 llamado local-peering-from y la Política A tiene un tipo de recurso llamado local-peering-to. En conjunto, estas políticas permiten a un usuario 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 cubrir 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 diferentes arrendamientos)

In this use case, the VCNs are in different tenancies (in other words, it's a cross-tenancy peering). Si las VCN están en el mismo arrendamiento, consulte Intercambio de tráfico local mediante un LPG (VCNas 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. Permite a requestorGrp conectar un LPG en el arrendamiento del solicitante a un LPG 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 que requestorGrp se conecte 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, gestione asociaciones de VCN y asigne tablas de rutas de DRG a las asociaciones, implante 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 VCN en otros arrendamientos

Las "asociaciones entre arrendamientos" son asociaciones de VCN especiales que se usan para conectar un DRG directamente a una VCN de otro arrendamiento pero que están ubicadas 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 inquilino de DRG pueden crear una asociación de DRG en el inquilino 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 del aceptador y está avalado en la política del aceptador.

Política A (VCN de 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