VPC compartida

En esta página se ofrece una descripción general de la VPC compartida en Google Cloud. La VPC compartida permite a una organización conectar recursos de varios proyectos a una red de nube privada virtual (VPC) común para que puedan comunicarse entre sí de forma segura y eficiente mediante direcciones IP internas de esa red.

Cuando usas la VPC compartida, designas un proyecto como proyecto host y le adjuntas uno o varios proyectos de servicio. Las redes de VPC del proyecto del host se denominan redes de VPC compartidas. Los recursos aptos de los proyectos de servicio pueden usar subredes de la red de VPC compartida.

La VPC compartida permite a los administradores de la organización delegar responsabilidades administrativas, como la creación y gestión de instancias, en los administradores de proyectos de servicio, al tiempo que se mantiene el control centralizado de los recursos de red, como las subredes, las rutas y los cortafuegos. Este modelo permite a las organizaciones hacer lo siguiente:

  • Implementa la práctica recomendada de seguridad de mínimos privilegios para la administración, la auditoría y el control de acceso de la red. Los administradores de VPC compartida pueden delegar tareas de administración de redes en administradores de redes y de seguridad de la red de VPC compartida sin permitir que los administradores de proyectos de servicio hagan cambios que afecten a la red. Los administradores de proyectos de servicio solo pueden crear y gestionar instancias que utilicen la red VPC compartida. Para obtener más información, consulta la sección sobre administradores y gestión de identidades y accesos.
  • Aplica y exige el cumplimiento de políticas de control de acceso coherentes a nivel de red en varios proyectos de servicio de la organización, al tiempo que delegas responsabilidades administrativas. Por ejemplo, los administradores de proyectos de servicio pueden ser administradores de instancias de Compute en su proyecto, creando y eliminando instancias que usen subredes aprobadas en el proyecto del host de VPC compartida.
  • Usa proyectos de servicio para separar los presupuestos o los centros de costes internos. Para obtener más información, consulta la sección Facturación.

Conceptos

Organizaciones, carpetas y proyectos

La VPC compartida conecta proyectos de la misma organización. Los proyectos vinculados pueden estar en la misma carpeta o en carpetas diferentes, pero si están en carpetas diferentes, el administrador debe tener derechos de administrador de VPC compartida en ambas carpetas. Consulta la Google Cloud jerarquía de recursos para obtener más información sobre organizaciones, carpetas y proyectos.

Los proyectos host y de servicio participantes no pueden pertenecer a organizaciones diferentes. La única excepción se produce durante la migración de tus proyectos de una organización a otra. Durante la migración, los proyectos de servicio pueden estar en una organización diferente a la del proyecto host temporalmente. Para obtener más información sobre la migración de proyectos, consulta el artículo Migrar proyectos.

Un proyecto que participa en la VPC compartida es un proyecto host o un proyecto de servicio:

  • Un proyecto host contiene una o varias redes de VPC compartida. Un administrador de VPC compartida debe habilitar primero un proyecto como proyecto host. Después, un administrador de VPC compartida puede asociar uno o varios proyectos de servicio.

  • Un proyecto de servicio es cualquier proyecto que haya vinculado a un proyecto host un administrador de VPC compartida. Este adjunto le permite participar en la VPC compartida. Es habitual que varios proyectos de servicio estén gestionados y administrados por diferentes departamentos o equipos de tu organización.

  • Un proyecto no puede ser un proyecto del host y un proyecto de servicio al mismo tiempo. Por lo tanto, un proyecto de servicio no puede ser un proyecto del host para otros proyectos de servicio.

  • Puedes crear y usar varios proyectos del host, pero cada proyecto del servicio solo se puede vincular a un proyecto del host. Para ver un ejemplo, consulta el ejemplo de varios proyectos host.

  • Puedes crear redes, subredes, intervalos de direcciones secundarias, reglas de cortafuegos y otros recursos de red en el proyecto host. El proyecto host puede compartir las subredes seleccionadas, incluidos los intervalos secundarios, con los proyectos de servicio. Los servicios que se ejecutan en un proyecto de servicio pueden usar la VPC compartida para comunicarse con los recursos que se ejecutan en los demás proyectos de servicio.

Para mayor claridad, un proyecto que no participa en la VPC compartida se denomina proyecto independiente. De esta forma, se destaca que no es ni un proyecto del host ni un proyecto de servicio.

Una red de VPC independiente es una red de VPC no compartida que existe en un proyecto independiente o en un proyecto de servicio.

Redes

Una red de VPC compartida es una red de VPC definida en un proyecto host y disponible como red compartida centralmente para los recursos aptos de los proyectos de servicio. Las redes de VPC compartidas pueden ser de modo automático o personalizado, pero las redes antiguas no son compatibles.

Cuando se habilita un proyecto host, tienes dos opciones para compartir redes:

  • Puedes compartir todas las subredes del proyecto del host. Si seleccionas esta opción, también se compartirán las subredes que se creen en el proyecto del host, incluidas las subredes de las nuevas redes.
  • Puedes especificar subredes concretas para compartirlas. Si compartes subredes de forma individual, solo se compartirán esas subredes, a menos que cambies la lista manualmente.

Los proyectos host y de servicio se conectan mediante adjuntos a nivel de proyecto. Los administradores de proyectos de servicio pueden acceder a las subredes de las redes de VPC compartida del proyecto host, tal como se describe en la siguiente sección, Administradores y gestión de identidades y accesos.

Restricciones de las políticas de organización

Las políticas de organización y los permisos de gestión de identidades y accesos funcionan conjuntamente para proporcionar diferentes niveles de control de acceso. Las políticas de organización te permiten definir controles a nivel de organización, carpeta o proyecto.

Si eres administrador de políticas de organización, puedes especificar las siguientes restricciones de VPC compartida en una política de organización:

  • Puede limitar el conjunto de proyectos del host a los que se puede adjuntar un proyecto que no sea del host o proyectos que no sean del host en una carpeta o una organización. La restricción se aplica cuando un administrador de VPC compartida vincula un proyecto de servicio con un proyecto de host. La restricción no afecta a los archivos adjuntos que ya tengas. Los archivos adjuntos que ya haya no se verán afectados aunque una política impida añadir otros nuevos. Para obtener más información, consulta la restricción constraints/compute.restrictSharedVpcHostProjects.

  • Puedes especificar las subredes de VPC compartida a las que puede acceder un proyecto de servicio a nivel de proyecto, carpeta u organización. La restricción se aplica cuando creas recursos en las subredes especificadas y no afecta a los recursos que ya tengas. Los recursos que ya tengas seguirán funcionando con normalidad en sus subredes aunque una política impida que se añadan recursos nuevos. Para obtener más información, consulta la restricción constraints/compute.restrictSharedVpcSubnetworks.

Administradores y gestión de identidades y accesos

La VPC compartida usa roles de Gestión de Identidades y Accesos (IAM) para la administración delegada. Los siguientes roles se pueden asignar a entidades principales de gestión de identidades y accesos, como usuarios, grupos de Google, dominios de Google o cuentas de servicio. Google Cloud Si necesitas ponerte en contacto con alguno de estos administradores, puedes buscarlo en la política de gestión de identidades y accesos de tu organización o proyecto. Si no tienes los permisos necesarios, debes ponerte en contacto con un administrador de la red o del proyecto de tu organización.

Roles de administrador necesarios

Administrador (rol de gestión de identidades y accesos) Finalidad
Administrador de la organización (resourcemanager.organizationAdmin)
  • Principal de IAM en la organización		 Los administradores de la organización tienen el rol resourcemanager.organizationAdmin en tu organización. Para ello, designan administradores de VPC compartida concediéndoles los roles de creación y eliminación de proyectos adecuados y el rol Administrador de VPC compartida de la organización. Estos administradores pueden definir políticas a nivel de organización, pero para realizar acciones específicas en carpetas y proyectos, se necesitan roles adicionales de carpeta y proyecto.
Administrador de VPC compartida
(compute.xpnAdmin y
resourcemanager.projectIamAdmin)
  • Principal de gestión de identidades y accesos de la organización
  • Principal de gestión de identidades y accesos de una carpeta		 Los administradores de VPC compartida tienen los roles Administrador de VPC compartida de Compute (compute.xpnAdmin) y Administrador de IAM de proyecto (resourcemanager.projectIamAdmin) en la organización o en una o varias carpetas. Realizan varias tareas necesarias para configurar la VPC compartida, como habilitar proyectos host, adjuntar proyectos de servicio a proyectos host y delegar el acceso a algunas o todas las subredes de las redes de VPC compartida a los administradores de proyectos de servicio. Un administrador de VPC compartida de un proyecto host determinado suele ser también el propietario del proyecto.
Un usuario al que se le ha asignado el rol de administrador de VPC compartida de Compute en la organización tiene ese rol en todas las carpetas de la organización. Un usuario al que se le haya asignado el rol de una carpeta tendrá ese rol en la carpeta en cuestión y en cualquier carpeta anidada en ella. Un administrador de VPC compartida solo puede vincular proyectos de dos carpetas diferentes si tiene el rol de ambas carpetas.
Administrador de proyectos de servicio
(compute.networkUser)
  • Principal de gestión de identidades y accesos de la organización
  • Principal de gestión de identidades y accesos de un proyecto host
  • Principal de gestión de identidades y accesos de algunas subredes del proyecto host		 Un administrador de VPC compartida define un administrador de proyecto de servicio concediendo a una entidad de gestión de identidades y accesos el rol Usuario de red (compute.networkUser) en todo el proyecto del host o en subredes seleccionadas de sus redes de VPC compartida. Los administradores de proyectos de servicio también conservan la propiedad y el control de los recursos definidos en los proyectos de servicio, por lo que deben tener el rol Administrador de instancias (compute.instanceAdmin) en los proyectos de servicio correspondientes. Pueden tener roles de gestión de identidades y accesos adicionales en los proyectos de servicio, como el de propietario del proyecto.

Administradores de proyectos de servicio

Al definir cada administrador de proyecto de servicio, un administrador de VPC compartida puede conceder permiso para usar todo el proyecto host o solo algunas subredes:

  • Permisos a nivel de proyecto: se puede definir un administrador de proyecto de servicio para que tenga permiso para usar todas las subredes del proyecto host si el administrador de VPC compartida le asigna el rol compute.networkUser a nivel de proyecto host. Como resultado, el administrador del proyecto de servicio tiene permiso para usar todas las subredes de todas las redes de VPC del proyecto del host, incluidas las subredes y las redes de VPC que se añadan al proyecto del host en el futuro.

  • Permisos a nivel de subred: otra opción es que un administrador de proyecto de servicio reciba un conjunto más restrictivo de permisos para usar solo algunas subredes si el administrador de VPC compartida le asigna el rol de compute.networkUser a esas subredes seleccionadas. Un administrador de proyecto de servicio que solo tenga permisos a nivel de subred solo podrá usar esas subredes. Después de añadir nuevas redes de VPC compartida o nuevas subredes al proyecto host, un administrador de VPC compartida debe revisar las vinculaciones de permisos del rol compute.networkUser para asegurarse de que los permisos a nivel de subred de todos los administradores de proyectos de servicio coincidan con la configuración prevista.

Administradores de redes y seguridad

Los administradores de VPC compartida tienen control total sobre los recursos del proyecto del host, incluida la administración de la red de VPC compartida. También pueden delegar ciertas tareas administrativas de la red en otros principales de gestión de identidades y accesos:

Administrador Finalidad
Administrador de redes
  • Principal de gestión de identidades y accesos en el proyecto host
  • Principal de gestión de identidades y accesos en la organización		 El administrador de VPC compartida define un administrador de redes concediendo a una entidad principal de gestión de identidades y accesos el rol Administrador de redes (compute.networkAdmin) en el proyecto host. Los administradores de red tienen control total sobre todos los recursos de red, excepto las reglas de cortafuegos y los certificados SSL.
Administrador de seguridad
  • Principal de gestión de identidades y accesos en el proyecto host
  • Principal de gestión de identidades y accesos en la organización		 Un administrador de VPC compartida puede definir un administrador de seguridad concediendo a una entidad principal de gestión de identidades y accesos el rol Administrador de seguridad (compute.securityAdmin) en el proyecto host. Los administradores de seguridad gestionan las reglas de cortafuegos y los certificados SSL.

Especificaciones

Cuotas y límites

Los proyectos host de VPC compartida están sujetos a las cuotas de VPC por proyecto estándar. Las redes de VPC compartidas están sujetas a los límites por red y a los límites por instancia de las redes de VPC. Además, las relaciones entre los proyectos host y de servicio se rigen por límites específicos de la VPC compartida.

Facturación

La facturación de los recursos que participan en una red de VPC compartida se atribuye al proyecto de servicio en el que se encuentra el recurso, aunque este utilice la red de VPC compartida del proyecto del host.

  • Las tarifas y las reglas que se usan para calcular los importes de facturación de los recursos de los proyectos de servicio que usan una red de VPC compartida son las mismas que si los recursos estuvieran ubicados en el propio proyecto del host.
  • La facturación del tráfico de salida generado por un recurso se atribuye al proyecto en el que se define el recurso:
    • El tráfico de salida de una instancia se atribuye al proyecto que contiene la instancia. Por ejemplo, si se crea una instancia en un proyecto de servicio, pero usa una red de VPC compartida, la facturación del tráfico saliente que genere se atribuirá a su proyecto de servicio. De esta forma, puedes usar la VPC compartida para organizar los recursos en centros de costes de tu organización.
    • Los costes asociados a un balanceador de carga se cobran al proyecto que contiene los componentes del balanceador de carga. Para obtener más información sobre el balanceo de carga y la VPC compartida, consulta la sección sobre el balanceo de carga.
    • El tráfico saliente a las VPNs se atribuye al proyecto que contiene el recurso Gateway de VPN. Por ejemplo, si se crea una pasarela de VPN en la red de VPC compartida, se incluirá en el proyecto host. El tráfico saliente a través de la pasarela VPN, independientemente del proyecto de servicio que inicie la transferencia de datos saliente, se atribuye al proyecto host.
    • Los costes del tráfico de un recurso de un proyecto de servicio de VPC compartida que se transfiere a través de una vinculación de VLAN se atribuyen al proyecto al que pertenece la vinculación de VLAN. Para obtener más información, consulta los precios de Cloud Interconnect.

Recursos

Recursos aptos

Puedes usar la mayoría de los productos y las funciones de Google Cloud en proyectos de servicio de VPC compartida.

Se aplican las siguientes limitaciones a los recursos que pueden participar en un escenario de VPC compartida:

  • No es obligatorio usar una red de VPC compartida. Por ejemplo, los administradores de instancias pueden crear instancias en el proyecto de servicio que usen una red de VPC de ese proyecto. Las redes definidas en proyectos de servicio no se comparten.

  • Algunos recursos deben volver a crearse para usar una red de VPC compartida. Cuando un administrador de VPC compartida adjunta un proyecto a un proyecto host, ese proyecto se convierte en un proyecto de servicio, pero sus recursos no utilizan automáticamente los recursos de red compartidos. Para usar una red de VPC compartida, un administrador de proyecto de servicio debe crear un recurso apto y configurarlo para que use una subred de una red de VPC compartida. Por ejemplo, una instancia de un proyecto de servicio no se puede reconfigurar para usar una red de VPC compartida, pero se puede crear una instancia para usar las subredes disponibles en una red de VPC compartida. Esta limitación se aplica a las zonas privadas.

Direcciones IP

Cuando creas una instancia en un proyecto de servicio, las versiones de IP que puedes configurar dependen de la configuración de la subred del proyecto host. Para obtener más información, consulta Crear una instancia.

Las instancias de los proyectos de servicio asociados a un proyecto host que usa la misma red de VPC compartida pueden comunicarse internamente entre sí mediante sus direcciones IPv4 internas o sus direcciones IPv6 internas o externas, de acuerdo con las reglas de cortafuegos aplicables.

Los administradores de proyectos de servicio pueden asignar cualquiera de los siguientes tipos de direcciones IP a los recursos de un proyecto de servicio:

  • Direcciones IPv4 e IPv6 efímeras: se puede asignar automáticamente una dirección IP efímera a una instancia de un proyecto de servicio. Por ejemplo, cuando los administradores de proyectos de servicio crean instancias, seleccionan la red de VPC compartida y una subred compartida disponible. En el caso de las instancias con direcciones IPv4, la dirección IPv4 interna principal procede del intervalo de direcciones IP disponibles del intervalo de direcciones IPv4 principal de la subred compartida seleccionada. En el caso de las instancias con direcciones IPv6, la dirección IPv6 procede del intervalo de direcciones IP disponibles del intervalo de subred IPv6 de la subred compartida seleccionada.

    También se pueden asignar automáticamente direcciones IPv4 efímeras a los balanceadores de carga internos. Para obtener más información, consulta cómo crear un balanceador de carga de red de transferencia interno o crear un balanceador de carga de aplicación interno.

  • Direcciones IPv4 e IPv6 internas estáticas: se pueden reservar direcciones IPv4 o IPv6 internas estáticas en un proyecto de servicio. El objeto de dirección IPv4 o IPv6 interna se debe crear en el mismo proyecto de servicio que el recurso que lo utiliza, aunque el valor de la dirección IP proceda de las direcciones IP disponibles de la subred compartida seleccionada en una red de VPC compartida. Para obtener más información, consulta Reservar direcciones IPv4 e IPv6 internas estáticas en la página "Aprovisionar VPC compartida".

  • Direcciones IPv4 externas estáticas: los objetos de dirección IPv4 externa definidos en el proyecto host pueden usarse en los recursos de ese proyecto host o en cualquier proyecto de servicio adjunto. Los proyectos de servicio también pueden usar sus propios objetos de dirección IPv4 externa. Por ejemplo, una instancia de un proyecto de servicio puede usar una dirección IPv4 externa regional definida en su proyecto de servicio o en el proyecto host.

  • Direcciones IPv6 externas estáticas: un administrador de proyectos de servicio también puede reservar una dirección IPv6 externa estática. El objeto de dirección IPv6 externa se debe crear en el mismo proyecto de servicio que el recurso que lo utiliza, aunque el valor de la dirección IP proceda de las direcciones IPv6 disponibles de la subred compartida seleccionada en una red de VPC compartida. Para obtener más información, consulta Reservar una dirección IPv6 externa estática en la página Aprovisionar una VPC compartida.

DNS interno

Las VMs del mismo proyecto de servicio pueden comunicarse entre sí mediante los nombres de DNS internos que Google Cloud crea automáticamente. Estos nombres de DNS usan el ID de proyecto del proyecto de servicio en el que se crean las VMs, aunque los nombres apunten a direcciones IP internas del proyecto host. Para obtener una explicación completa, consulta Nombres de DNS internos y VPC compartida en la documentación de DNS interno.

Zonas privadas de Cloud DNS

Puedes usar zonas privadas de Cloud DNS en una red de VPC compartida. Puedes crear tu zona privada en el proyecto host y autorizar el acceso a la zona para la red de VPC compartida o configurar la zona en un proyecto de servicio mediante el enlace entre proyectos.

Balanceo de carga

VPC compartida se puede usar junto con Cloud Load Balancing. En la mayoría de los casos, las instancias de backend se crean en un proyecto de servicio. En ese caso, todos los componentes del balanceador de carga se crearán en ese proyecto. Aunque es posible crear instancias de backend en el proyecto host, esta configuración no es adecuada para las implementaciones típicas de VPC compartida, ya que no separa las responsabilidades de administración de la red y de desarrollo de servicios.

Consulte los enlaces de la siguiente tabla para obtener más información sobre las arquitecturas de VPC compartida admitidas para cada tipo de balanceador de carga.

Tipo de balanceador de carga Enlaces
Balanceador de carga de aplicación externo Arquitectura de VPC compartida
Balanceador de carga de aplicación interno Arquitectura de VPC compartida
Balanceador de carga de red de proxy externo Arquitectura de VPC compartida
Balanceador de carga de red de proxy interno Arquitectura de VPC compartida
Balanceador de carga de red de paso a través interno Arquitectura de VPC compartida
Balanceador de carga de red de paso a través externo Arquitectura de VPC compartida

Ejemplos y casos prácticos

Conceptos básicos

En la figura 1 se muestra un escenario sencillo de VPC compartida:

Imagen 1. Un proyecto del host con una red de VPC compartida proporciona conectividad interna a dos proyectos de servicio, mientras que un proyecto independiente no usa la VPC compartida (haz clic para ampliar).

  • Un administrador de VPC compartida de la organización ha creado un proyecto host y ha asociado dos proyectos de servicio a él:

    • Los administradores de proyectos de servicio de Service project A se pueden configurar para que accedan a todas o a algunas de las subredes de la red de VPC compartida. Un administrador de proyectos de servicio con al menos permisos a nivel de subred para 10.0.1.0/24 subnet ha creado Instance A en una zona de la región us-west1. Esta instancia recibe su dirección IP interna, 10.0.1.3, del bloque CIDR 10.0.1.0/24.

    • Los administradores de proyectos de servicio de Service project B se pueden configurar para que accedan a todas o a algunas de las subredes de la red de VPC compartida. Un administrador de proyectos de servicio con al menos permisos a nivel de subred para 10.15.2.0/24 subnet ha creado Instance B en una zona de la región us-east1. Esta instancia recibe su dirección IP interna, 10.15.2.4, del bloque CIDR 10.15.2.0/24.

  • El proyecto independiente no participa en la VPC compartida; no es ni un proyecto host ni un proyecto de servicio. Las instancias independientes las crean principales de IAM que tienen al menos el rol compute.InstanceAdmin en el proyecto.

Varios proyectos del host

En la figura 2 se muestra cómo se puede usar una VPC compartida para crear entornos de prueba y de producción independientes. En este caso, una organización ha decidido usar dos proyectos host independientes: un entorno de prueba y un entorno de producción.

Imagen 2. Un proyecto host de entorno de pruebas y un proyecto host de entorno de producción usan la VPC compartida para crear entornos de producción y de pruebas distintos (haz clic para ampliar).

  • Un administrador de VPC compartida de la organización ha creado dos proyectos host y ha asociado dos proyectos de servicio a ellos de la siguiente manera:

    • Los proyectos de servicio Apps testing y Mobile testing están vinculados al proyecto del host Test environment. Los administradores de proyectos de servicio de cada proyecto se pueden configurar para que accedan a todas o a algunas de las subredes de Testing network.

    • Los proyectos de servicio Apps production y Mobile production están vinculados al proyecto del host Production environment. Los administradores de proyectos de servicio de cada proyecto se pueden configurar para que accedan a todas o algunas de las subredes de la Production network.

  • Ambos proyectos del host tienen una red de VPC compartida con subredes configuradas para usar los mismos intervalos de CIDR. En Testing network y Production network, las dos subredes son las siguientes:

    • 10.0.1.0/24 subnet en la región de us-west1

    • 10.15.2.0/24 subnet en la región de us-east1

  • Considera Instance AT en el proyecto de servicio Apps testing y Instance AP en el proyecto de servicio Apps production:

    • Los administradores de proyectos de servicio pueden crear instancias como estas siempre que tengan al menos permisos a nivel de subred para 10.0.1.0/24 subnet.

    • Ten en cuenta que ambas instancias usan la dirección IP 10.0.1.3. Esto es aceptable porque cada instancia se encuentra en un proyecto de servicio asociado a un proyecto del host único que contiene su propia red de VPC compartida. Las redes de prueba y de producción se han configurado de forma intencionada de la misma manera.

    • Las instancias que usen 10.0.1.0/24 subnet deben estar ubicadas en una zona de la misma región que la subred, aunque la subred y las instancias se definan en proyectos independientes. Como 10.0.1.0/24 subnet se encuentra en la región us-west1, los administradores de proyectos de servicio que creen instancias con esa subred deben elegir una zona de la misma región, como us-west1-a.

Situación de nube híbrida

En la figura 3 se muestra cómo se puede usar la VPC compartida en un entorno híbrido.

Imagen 3. Una red de VPC compartida está conectada a una red local y a tres proyectos de servicio (haz clic en la imagen para ampliarla).

En este ejemplo, una organización ha creado un único proyecto host con una única red de VPC compartida. La red de VPC compartida se conecta a una red local mediante Cloud VPN. Algunos servicios y aplicaciones se alojan en Google Cloud , mientras que otros se mantienen en las instalaciones:

  • Un administrador de VPC compartida ha habilitado el proyecto host y ha conectado tres proyectos de servicio: Service project A, Service project B y Service project C.

    • Equipos independientes pueden gestionar cada uno de los proyectos de servicio. Los permisos de gestión de identidades y accesos se han configurado de forma que un administrador de proyectos de servicio de un proyecto no tenga permisos en los demás proyectos de servicio.

    • El administrador de la VPC compartida ha concedido permisos a nivel de subred o de proyecto a los administradores de proyectos de servicio necesarios para que puedan crear instancias que usen la red de la VPC compartida:

      • Un administrador de proyecto de servicio de Service project A que tenga permisos a nivel de subred en 10.0.1.0/24 subnet puede crear Instance A en él. El administrador del proyecto de servicio debe elegir una zona de la región us-west1 para la instancia, ya que es la región que contiene el 10.0.1.0/24 subnet. Instance A recibe su dirección IP, 10.0.1.3, del intervalo de direcciones IP libres de la 10.0.1.0/24 subnet.

      • Un administrador de proyecto de servicio de Service project B que tenga permisos a nivel de subred en 10.15.2.0/24 subnet puede crear Instance B en él. El administrador del proyecto de servicio debe elegir una zona de la región us-east1 para la instancia, ya que es la región que contiene el 10.15.2.0/24 subnet. Instance B recibe su dirección IP, 10.15.2.4, del intervalo de direcciones IP libres de 10.15.2.0/24 subnet.

      • Un administrador de proyectos de servicio de Service project C que tenga permisos a nivel de proyecto en todo el proyecto host puede crear instancias en cualquiera de las subredes de cualquiera de las redes de VPC del proyecto host. Por ejemplo, el administrador del proyecto de servicio puede crear Instance C en 10.7.1.0/24 subnet y elegir una zona de la región us-east1 para que coincida con la región de la subred. Instance C recibe su dirección IP, 10.7.1.50, del intervalo de direcciones IP libres de la 10.7.1.0/24 Subnet.

    • Los administradores de proyectos de servicio de cada proyecto son responsables de crear y gestionar recursos.

  • Un administrador de VPC compartida ha delegado tareas de administración de redes en otras entidades de IAM que son administradores de redes y seguridad de la red de VPC compartida.

    • Un administrador de red ha creado una pasarela de Cloud VPN y ha configurado un túnel de VPN a través de Internet a una pasarela local. La VPN de Cloud intercambia y recibe rutas con su contraparte on-premise porque se ha configurado un router de Cloud correspondiente en la misma us-east1 región .

    • Si el modo de enrutamiento dinámico de la VPC es global, Cloud Router aplica las rutas aprendidas a la red on-premise en todas las subredes de la red de VPC y comparte rutas con todas las subredes de la VPC con su contraparte on-premise.

    • Los administradores de seguridad crean y gestionan reglas de cortafuegos en la red de VPC compartida para controlar el tráfico entre las instancias de Google Cloud y la red local.

    • De acuerdo con las reglas de cortafuegos aplicables, las instancias de los proyectos de servicio se pueden configurar para que se comuniquen con servicios internos, como bases de datos o servidores de directorios ubicados en las instalaciones.

Servicio web de dos niveles

En la imagen 4 se muestra cómo se puede usar una VPC compartida para delegar responsabilidades administrativas y mantener el principio de mínimos accesos. En este caso, una organización tiene un servicio web que se divide en dos niveles, y diferentes equipos gestionan cada nivel. El nivel 1 representa el componente orientado al exterior, detrás de un balanceador de carga HTTP(S). El nivel 2 representa un servicio interno del que depende el nivel 1 y se equilibra mediante un balanceador de carga TCP/UDP interno.

Imagen 4. En este servicio web de dos niveles, un componente orientado al exterior y un servicio interno están conectados a una red de VPC compartida común y gestionados por distintos equipos (haz clic para ampliar).

La VPC compartida te permite asignar cada nivel del servicio web a un proyecto diferente para que puedan gestionarlos distintos equipos y, al mismo tiempo, compartir una red de VPC común:

  • Los recursos de cada nivel, como las instancias y los componentes del balanceador de carga, se colocan en proyectos de servicio individuales gestionados por diferentes equipos.

  • Un administrador de VPC compartida ha asociado cada proyecto de servicio de nivel al proyecto del host. El administrador de la VPC compartida también ha habilitado el proyecto host.

    • Diferentes equipos pueden gestionar cada nivel del servicio web si tienen el rol de administrador de proyecto de servicio en el proyecto de servicio correspondiente.

    • Los administradores de proyectos de servicio de cada proyecto son responsables de crear y gestionar recursos.

  • El control de acceso a la red se describe de la siguiente manera:

    • Las entidades de gestión de identidades y accesos que solo trabajan en el nivel 1 son administradores del proyecto de servicio de Tier 1 service project y tienen permisos a nivel de subred solo para 10.0.1.0/24 subnet. En este ejemplo, un administrador de proyectos de servicio ha creado tres Tier 1 instances en esa subred.

    • Las entidades de gestión de identidades y accesos que solo trabajan en el nivel 2 son administradores del proyecto de servicio de Tier 2 service project y tienen permisos a nivel de subred solo para 10.0.2.0/24 subnet. En este ejemplo, otro administrador de proyecto de servicio ha creado tres Tier 2 instances en esa subred junto con un balanceador de carga interno cuya regla de reenvío usa una dirección IP del intervalo disponible en esa subred.

    • Los principales de gestión de identidades y accesos que supervisan todo el servicio web son administradores de proyectos de servicio en ambos proyectos de servicio y tienen permisos a nivel de proyecto en el proyecto host, por lo que pueden usar cualquier subred definida en él.

    • De forma opcional, un administrador de VPC compartida puede delegar tareas de administración de redes en administradores de redes y de seguridad.

Siguientes pasos