VPC compartida

En esta página, se proporciona una descripción general de la VPC compartida en Google Cloud. La VPC compartida permite que una organización conecte recursos de varios proyectos a una red de nube privada virtual (VPC) común para que se comuniquen entre sí de manera segura y eficiente mediante las IP internas de esa red.

Cuando utilizas una VPC compartida, designas un proyecto como el proyecto host y vinculas uno o más proyectos de servicio a este. Las redes de VPC en el proyecto host se conocen como redes de VPC compartida. Los recursos aptos de proyectos de servicio pueden usar subredes en la red de VPC compartida.

La VPC compartida permite que los administradores de la organización deleguen responsabilidades administrativas, como crear y administrar instancias, a los Administradores de proyectos de servicio, mientras mantienen un control centralizado de los recursos de la red, como las subredes, las rutas y los firewalls. Este modelo permite que las organizaciones hagan lo siguiente:

  • Implementar una recomendación de seguridad de menor privilegio para la administración de la red, la auditoría y el control de acceso. Los Administradores de VPC compartida pueden delegar tareas de administración de la red a los Administradores de la red y seguridad en la red de VPC compartida sin permitir que los Administradores de proyectos de servicio realicen cambios en la red. Los Administradores de proyectos de servicio solo tienen la capacidad de crear y administrar instancias a fin de utilizar la red de VPC compartida. Consulta la sección administradores y la IAM para obtener más detalles.
  • Aplicar y poner en práctica políticas de control de acceso unificadas a nivel de red para múltiples proyectos de servicio en la organización y, al mismo tiempo, delegar responsabilidades administrativas. Por ejemplo, los Administradores de proyectos de servicio pueden ser Administradores de las instancias de procesamiento en su proyecto, y crear y quitar instancias que utilicen subredes aprobadas en su proyecto host de la VPC compartida.
  • Utilizar proyectos de servicio para separar los centros de presupuestos o de costos internos. Consulta Facturación para obtener más detalles.

Conceptos

Organizaciones, carpetas y proyectos

La VPC compartida conecta proyectos dentro de la misma organización. Los proyectos vinculados pueden estar en la misma carpeta o en carpetas distintas; no obstante, si están en carpetas diferentes, el administrador debe contar con derechos de administrador de VPC compartida para ambas carpetas. Consulta Jerarquía de recursos de Google Cloud 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 es durante una 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 de forma temporal. Para obtener más información sobre la migración de proyectos, consulta Migra proyectos.

Un proyecto que participa de una VPC compartida puede ser un proyecto host como un proyecto de servicio:

  • Un proyecto host contiene una o más redes de VPC compartida. Un administrador de VPC compartida primero debe habilitar un proyecto como proyecto host. Luego, el administrador de la VPC compartida puede conectarle uno o más proyectos de servicio.

  • Un proyecto de servicio es cualquier proyecto que un administrador de la VPC compartida haya conectado a un proyecto host. Cuando se vincula un proyecto de servicio, se le permite participar en la VPC compartida. Es normal que, en departamentos o equipos diferentes de tu organización, se operen y administren distintos proyectos de servicio.

  • Un proyecto no puede ser un proyecto host y un proyecto de servicio a la vez. Por ende, un proyecto de servicio no puede ser un proyecto host para futuros proyectos de servicio.

  • Puedes crear y utilizar múltiples proyectos host; sin embargo, cada proyecto de servicio solo puede estar vinculado a un proyecto host. Para ver una ilustración, consulta el ejemplo de múltiples proyectos host.

  • Puedes crear redes, subredes, rangos de direcciones secundarios, reglas de firewall y otros recursos de red en el proyecto host. Luego, el proyecto host puede compartir las subredes seleccionadas, incluidos los rangos 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 otros proyectos de servicio.

Para ser claros, a un proyecto que no participe en la VPC compartida se lo llama proyecto independiente. Esto muestra que no es ni un proyecto 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 una red compartida de manera central para recursos aptos en proyectos de servicio. Las redes de VPC compartida pueden ser de modo automático o personalizado, pero no son compatibles con las redes heredadas.

Cuando un proyecto host está habilitado, tienes dos opciones para compartir redes:

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

Los proyectos host y de servicio están conectados por vínculos a nivel de proyecto. Los administradores de proyectos de servicio pueden acceder a las subredes de las redes de VPC compartida en el proyecto host según se describe en la próxima sección, Administradores y la IAM.

Limitaciones de las políticas de la organización

Las políticas de la organización y los permisos de IAM funcionan en conjunto para proporcionar diferentes niveles de control de acceso. Las políticas de la organización te permiten establecer controles a nivel de organización, carpeta o proyecto.

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

  • Puedes limitar el conjunto de proyectos host al que se pueden conectar uno o varios proyectos que no sean host de una organización o carpeta. La restricción se aplica cuando un administrador de VPC compartida conecta un proyecto de servicio a un proyecto host. La restricción no afecta a los adjuntos existentes. Las vinculaciones actuales permanecen intactas, incluso si una política impide que se creen vinculaciones nuevas. Para obtener más información, consulta la restricción constraints/compute.restrictSharedVpcHostProject.

  • Puedes especificar las subredes de la VPC compartida a las que puede acceder un proyecto de servicio a nivel de organización, carpeta o proyecto. La restricción se aplica cuando creas recursos nuevos en las subredes especificadas y no afecta a los recursos existentes. Los recursos existentes siguen funcionando con normalidad en sus subredes, incluso si una política impide que se agreguen recursos nuevos. Para obtener más información, consulta la restricción constraints/compute.restrictSharedVpcSubnetworks.

Administradores y la IAM

La VPC compartida usa funciones de administración de identidades y accesos (IAM) para la administración delegada. Las siguientes funciones se pueden otorgar a los principales de IAM, como usuarios, Grupos de Google, Google Domains o cuentas de servicio de Google Cloud. Si necesitas comunicarte con cualquiera de estos administradores, puedes buscarlos en la política de IAM de tu organización o proyecto. Si no cuentas con los permisos necesarios, debes contactar a un administrador de red o de proyecto de tu organización.

Funciones administrativas requeridas

Administrador (función de IAM) Objetivo
Administrador de la organización (resourcemanager.organizationAdmin)
  • Principales de IAM en la organización		 Los administradores de la organización tienen la función resourcemanager.organizationAdmin en la organización. Nominan a los administradores de VPC compartida; para ello, les otorgan funciones apropiadas de creación y eliminación de proyectos y la función de administrador de VPC compartida en la organización. Estos administradores pueden definir políticas a nivel de la organización, pero las acciones específicas de carpetas y proyectos requieren otras funciones de carpetas y proyectos.
Administrador de VPC compartida
(compute.xpnAdmin y
resourcemanager.projectIamAdmin)
  • Principal de IAM en la organización o
  • Principal de IAM en una carpeta		 Los administradores de VPC compartida tienen las funciones de administrador de VPC compartida de Compute (compute.xpnAdmin) y administrador de IAM de proyectos (resourcemanager.projectIamAdmin) dentro de la organización o de una o más carpetas. Realizan diversas tareas que son necesarias para configurar la VPC compartida, como habilitar proyectos host, conectar proyectos de servicio a proyectos host y delegar el acceso a algunas o todas las subredes en las redes de VPC compartida a los administradores de proyectos de servicio. Un administrador de VPC compartida para un proyecto host determinado suele ser también el propietario del proyecto.
Un usuario al que se le asignó la función de administrador de VPC compartida de Compute en la organización tiene esa función para todas las carpetas de la organización. Un usuario al que se le asignó la función para una carpeta tiene esa función en esa carpeta y en las demás carpetas anidadas en ella. Un Administrador de VPC compartida puede vincular proyectos en dos carpetas distintas únicamente si el administrador tiene la función para ambas carpetas.
Administrador de proyectos de servicio
(compute.networkUser).
• Principal de IAM en la organización.
• Principal de IAM en un proyecto host, o
• Principal de IAM en algunas subredes del proyecto host		 Un administrador de la VPC compartida define un administrador de proyectos de servicio cuando le otorga a un principales de IAM la función de usuario de red (compute.networkUser) en todo el proyecto host o en las subredes seleccionadas de las redes de la 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 la función de administrador de instancias (compute.instanceAdmin) sobre los proyectos de servicio correspondientes. Es posible que tengan funciones de IAM adicionales en los proyectos de servicio, como la de propietario del proyecto.

Administradores de proyectos de servicio

Cuando un administrador de la VPC compartida define cada administrador de proyectos de servicios, puede otorgar permisos para usar la totalidad del proyecto host o alguna de sus subredes:

  • Permisos a nivel de proyecto: Un administrador de proyectos de servicio puede tener permiso para usar todas las subredes en el proyecto host si el administrador de la VPC compartida le otorga la función compute.networkUser en todo el proyecto host. Como resultado, ese administrador de proyectos de servicio tiene permiso para usar las subredes en todas las redes de la VPC del proyecto host, incluidas las subredes y las redes de VPC que se agreguen al proyecto host en el futuro.

  • Permisos a nivel de subred: Como alternativa, un administrador de proyectos de servicio puede obtener un conjunto más restringido de permisos para usar solo algunas subredes si el administrador de la VPC compartida le otorga la función compute.networkUser en esas subredes seleccionadas. Un Administrador de proyectos de servicio que solo cuenta con permisos a nivel de la subred está restringido a utilizar esas subredes únicamente. Después de agregar redes de VPC compartida o subredes nuevas al proyecto host, un administrador de VPC compartida debe revisar las vinculaciones de permisos para la función de compute.networkUser a fin de asegurarse de que los permisos a nivel de subred de todos los administradores de proyectos de servicio coincidan con la configuración deseada.

Administradores de red y seguridad

Los Administradores de VPC compartida tienen control total sobre los recursos en el proyecto host, incluida la administración de la red de VPC compartida. Pueden optar por delegar ciertas tareas administrativas de la red a otros principales de IAM:

Administrador Objetivo
Administrador de red
• Principal de IAM en el proyecto host o
• Principal de IAM en la organización		 El administrador de la VPC compartida define un administrador de red cuando le otorga a un principal de IAM la función de administrador de red (compute.networkAdmin) en el proyecto host. Los administradores de redes tienen control total sobre los recursos de la red, excepto por las reglas de firewall y los certificados SSL.
Administrador de seguridad
• Principal de IAM en el proyecto host o
• Principal de IAM en la organización		 Un administrador de la VPC compartida puede definir un administrador de seguridad si le otorga a un principal de IAM la función de administrador de seguridad (compute.securityAdmin) en el proyecto host. Los administradores de seguridad administran las reglas de firewall y los certificados SSL.

Especificaciones

Cuotas y límites

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

Facturación

La facturación de los recursos que participan de la 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 en el proyecto host.

  • Las tarifas y las reglas que se usan para calcular los importes de facturación de los recursos en proyectos de servicio que usan una red de VPC compartida son las mismas que si los recursos estuvieran ubicados en el mismo proyecto host.
  • La facturación del tráfico de salida generado por un recurso se atribuye al proyecto en el que este se encuentra definido con los siguientes alcances:
    • El tráfico de salida de una instancia se atribuye al proyecto que la contiene. Por ejemplo, si una instancia se crea en un proyecto de servicio, pero utiliza una red de VPC compartida, toda facturación por tráfico de salida que se genere se atribuirá a su proyecto de servicio. De esta manera, puedes utilizar la VPC compartida a fin de organizar recursos en centros de costos para tu organización.
    • Los costos relacionados con el balanceador de cargas se facturan al proyecto que contiene los componentes del balanceador de cargas. Para obtener más detalles sobre el balanceo de cargas y la VPC compartida, consulta Balanceo de cargas.
    • El tráfico de salida a las VPN se atribuye al proyecto que contiene el recurso de puerta de enlace de VPN. Por ejemplo, si se crea una puerta de enlace de VPN en la red de VPC compartida, esta se encuentra en el proyecto host. El tráfico saliente a través de la puerta de enlace de VPN, sin importar qué proyecto de servicio inicie la transferencia de datos saliente, se atribuye al proyecto host.
    • Los costos por el tráfico de un recurso en un proyecto de servicio de VPC compartida que se transfiere a través de un adjunto de VLAN se atribuyen al proyecto que posee el adjunto 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 los proyectos de servicio de VPC compartida.

Las siguientes limitaciones se aplican a los recursos que son aptos para participar en una situación 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 utilicen una red de VPC en ese proyecto. Las redes definidas en proyectos de servicio no se comparten.

  • Es necesario volver a crear algunos recursos para poder usar una red de VPC compartida. Cuando un administrador de VPC compartida conecta un proyecto existente a un proyecto host, ese proyecto se convierte en un proyecto de servicio, pero en los recursos existentes no se utilizan automáticamente los recursos de la red compartida. A fin de utilizar una red de VPC compartida, un Administrador de proyectos de servicio debe crear un recurso apto y configurarlo para que use una subred de una red de VPC compartida. Por ejemplo, una instancia existente en un proyecto de servicio no puede reconfigurarse a fin de que utilice una red de VPC compartida, pero se puede crear una instancia nueva para que utilice subredes disponibles en una red de VPC compartida. Esta limitación se aplica a zonas privadas.

Direcciones IP

Cuando creas una instancia en un proyecto de servicio, puedes configurarla como una instancia de pila única (solo IPv4) o de pila doble (IPv4 o IPv6), según la configuración de subred del proyecto host. Para obtener más información, consulta Crea una instancia.

Las instancias de proyectos de servicio que están vinculadas con un proyecto host y usan la misma red de VPC compartida pueden comunicarse internamente entre ellas mediante sus direcciones IPv4 internas o sus direcciones IPv6 internas o externas, sujetas a las reglas de firewall correspondientes.

Los administradores de proyectos de servicio pueden asignar cualquiera de los siguientes tipos de dirección IP a los recursos en un proyecto de servicio:

  • Direcciones IPv4 e IPv6 efímeras: Una dirección IP efímera se puede asignar automáticamente a una instancia en 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. La dirección IPv4 interna principal de la instancia proviene del rango de direcciones IP disponibles en el rango de direcciones IPv4 principal de la subred compartida seleccionada. Si configuran la instancia como una instancia de doble pila, la dirección IPv6 de la instancia proviene del rango de direcciones IP disponibles en el rango de subred IPv6 de la subred compartida seleccionada.

    Las direcciones IPv4 efímeras también se pueden asignar automáticamente a balanceadores de cargas internos. Para obtener más información, consulta Crea un balanceador de cargas de red de transferencia interno o Crea un balanceador de cargas de aplicaciones interno.

  • Direcciones IPv4 e IPv6 internas estáticas: se puede reservar una dirección IPv4 o IPv6 interna estática en un proyecto de servicio. El objeto de la dirección interna IPv4 o IPv6 debe crearse en el mismo proyecto de servicio que el recurso que la usa, aunque el valor de la dirección IP provenga de las direcciones IP disponibles de la subred compartida que seleccionó en una red de VPC compartida. Para obtener más información, consulta Reserva direcciones IPv4 e IPv6 internas estáticas en la página “Aprovisiona la VPC compartida”.

  • Direcciones IPv4 externas estáticas: Los objetos de dirección IPv4 externas definidos en el proyecto host pueden usarlos los recursos en cualquier proyecto host o en cualquier proyecto de servicio vinculado. Los proyectos de servicio también pueden usar sus propios objetos de dirección IPv4 externa. Por ejemplo, una instancia en 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 optar por reservar una dirección IPv6 externa estática. El objeto de la dirección interna IPv6 debe crearse en el mismo proyecto de servicio que el recurso que la usa, aunque el valor de la dirección IP provenga de las direcciones IPv6 disponibles de la subred compartida que seleccionó en una red de VPC compartida. Para obtener más información, consulta Reserva una dirección IPv6 externa estática en la página Aprovisiona una VPC compartida.

DNS interno

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

Zonas privadas de Cloud DNS

Puedes usar las 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 con vinculación entre proyectos.

Balanceo de cargas

La VPC compartida puede usarse 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 cargas se crean en ese proyecto. Si bien es posible crear instancias de backend en el proyecto host, esta configuración no es adecuada para implementaciones de VPC compartida típicas, ya que no divide las responsabilidades de administración de red y de desarrollo de servicios.

Usa los vínculos de la siguiente tabla para obtener más información sobre las arquitecturas de VPC compartidas compatibles para cada tipo de balanceador de cargas.

Tipo de balanceador de cargas Vínculos
Balanceador de cargas de aplicaciones externo Arquitectura de VPC compartida
Balanceador de cargas de aplicaciones interno Arquitectura de VPC compartida
Balanceador de cargas de red del proxy externo Arquitectura de VPC compartida
Balanceador de cargas de red del proxy interno Arquitectura de VPC compartida
Balanceador de cargas de red de transferencia interno Arquitectura de VPC compartida
Balanceador de cargas de red de transferencia externo Arquitectura de VPC compartida

Ejemplos y casos prácticos

Conceptos básicos

En la figura 1, se muestra una situación de VPC compartida simple:

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

  • Un administrador de VPC compartida de la organización creó un proyecto host y le vinculó dos proyectos de servicio:

    • Los administradores de proyectos de servicio en Service project A pueden configurarse a fin de que tengan acceso a todas las subredes en la red de VPC compartida o solo a algunas de ellas. Un administrador de proyectos de servicio que tiene, como mínimo, permisos a nivel de subred para 10.0.1.0/24 subnet creó Instance A en una zona de la región us-west1. En esta instancia, se recibe la dirección IP interna, 10.0.1.3, del bloque CIDR 10.0.1.0/24.

    • Los administradores de proyectos de servicio en Service project B pueden configurarse a fin de que tengan acceso a todas las subredes en la red de VPC compartida o solo a algunas de ellas. Un administrador de proyectos de servicio que tiene, como mínimo, permisos a nivel de subred para 10.15.2.0/24 subnet creó Instance B en una zona de la región us-east1. En esta instancia, se recibe la 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 en absoluto; no es un proyecto host ni de servicio. Las instancias independientes son creadas por principales de IAM que tienen, como mínimo, la función de compute.InstanceAdmin para el proyecto.

Múltiples proyectos host

En la Figura 2, se muestra cómo se puede usar la VPC compartida para compilar entornos de prueba y producción independientes. Para este caso, una organización decidió utilizar dos proyectos host separados, un Entorno de prueba y un Entorno de producción.

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

  • Un administrador de VPC compartida para la organización creó dos proyectos host y les vinculó los siguientes dos proyectos de servicio de la siguiente manera:

    • Los proyectos de servicio Apps testing y Mobile testing se conectan al proyecto host Test environment. Los administradores del proyecto de servicio en cada proyecto pueden configurarse para acceder a todas o algunas de las subredes en Testing network.

    • Los proyectos de servicio Apps production y Mobile production se conectan al proyecto host Production environment. Los administradores de proyectos de servicio en cada proyecto pueden configurarse a fin de acceder a todas o algunas de las subredes en Production network.

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

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

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

  • Considera Instance AT en el proyecto de servicio Apps testing y Instance AP en el proyecto de servicio Apps production con los siguientes alcances:

    • Los administradores de proyectos de servicio pueden crear instancias como estas siempre que tengan, como mínimo, 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 debido a que ambas instancias existen en un proyecto de servicio vinculado con un proyecto host único que contiene su propia red de VPC compartida. Las redes de prueba y de producción se configuraron de igual manera a propósito.

    • Las instancias en las que se usa 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 distintos. Debido a que 10.0.1.0/24 subnet se encuentra en la región us-west1, los administradores de proyectos de servicio que crean instancias con esa subred deben elegir una zona en 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.

Figura 3. Una red de VPC compartida está conectada a una red local y tres proyectos de servicio (haz clic para ampliar).

Para este ejemplo, una organización creó un solo proyecto host con una sola red de VPC compartida. La red de VPC compartida está conectada mediante Cloud VPN a una red local. Algunos servicios y aplicaciones se alojan en Google Cloud, mientras que otros se mantienen de forma local:

  • Un administrador de VPC compartida habilitó el proyecto host y lo conectó con tres proyectos de servicio: Service project A, Service project B y Service project C.

    • Distintos equipos pueden administrar cada uno de los proyectos de servicio. Los permisos de IAM se configuraron a fin de que un Administrador de proyectos de servicio para un proyecto no tenga permisos para otro proyecto.

    • El administrador de la VPC compartida le otorgó permisos a nivel de la subred o de proyecto a los administradores de proyectos de servicios necesarios para que puedan crear instancias que usen la red de VPC compartida:

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

      • Un administrador de proyectos de servicio de Service project B con permisos a nivel de subred para 10.15.2.0/24 subnet puede crear el objeto Instance B en él. El administrador de proyectos de servicio debe elegir una zona en la región us-east1 para la instancia, ya que esa es la región que contiene 10.15.2.0/24 subnet. En Instance B, se recibe la dirección IP, 10.15.2.4, del rango de direcciones IP gratuitas de 10.15.2.0/24 subnet.

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

    • Cada proyecto de servicio se factura por separado.

    • Los Administradores de proyectos de servicio en cada proyecto son responsables de crear y administrar recursos.

  • Un Administrador de VPC compartida delegó las tareas de administración de la red a otros principales de IAM que son Administradores de redes y seguridad de la red de VPC compartida.

    • Un administrador de la red creó una puerta de enlace de Cloud VPN y configuró un túnel VPN a través de Internet hacia una puerta de enlace local. En Cloud VPN, se intercambian y reciben rutas con su contraparte local porque se configuró un Cloud Router correspondiente en la misma región us-east1.

    • Si el modo de enrutamiento dinámico de la VPC es global, Cloud Router aplica las rutas aprendidas a la red local en todas las subredes de la red de VPC y comparte las rutas a todas las subredes de la VPC con las contrapartes locales.

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

    • Las instancias en los proyectos de servicio, que están sujetas a las reglas aplicables de firewall, se pueden configurar para que se comuniquen con servicios internos, como servidores de bases de datos o directorios locales.

Servicio web de dos niveles

En la figura 4, se muestra cómo se puede usar la VPC compartida para delegar responsabilidades administrativas y mantener el principio de privilegio mínimo. En este caso, una organización tiene un servicio web que está separado en dos niveles, y equipos distintos administran cada nivel. El nivel 1 representa el componente externo, detrás de un balanceador de cargas HTTP(S). El nivel 2 representa un servicio interno del que depende el nivel 1 y se balancea mediante un balanceador de cargas de TCP/UDP interno.

Figura 4. En este servicio web de dos niveles, un componente externo y un servicio interno están conectados a una red de VPC compartida común y son administrados por diferentes equipos (haz clic para ampliar).

La VPC compartida te permite asignar cada nivel del servicio web con proyectos diferentes a fin de que puedan administrarlos equipos distintos mientras comparten una red de VPC en común:

  • Los recursos, como instancias y componentes del balanceador de cargas, para cada nivel se colocan en proyectos de servicio individuales administrados con equipos distintos.

  • Un administrador de VPC compartida conectó cada proyecto de servicio de nivel al proyecto host. El administrador de VPC compartida también habilitó el proyecto host.

    • Equipos separados pueden administrar cada uno de los servicios web, ya que son Administradores de proyectos de servicio en el proyecto de servicio correspondiente.

    • Cada proyecto de servicio se factura por separado.

    • Los Administradores de proyectos de servicio en cada proyecto son responsables de crear y administrar recursos.

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

    • Los principales de IAM que solo trabajan en el nivel 1 son administradores de proyectos 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, uno de estos administradores de proyectos de servicio creó tres Tier 1 instances en esa subred.

    • Los principales de IAM que solo trabajan en el nivel 2 son administradores de proyectos 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 proyectos de servicio creó tres Tier 2 instances en esa subred junto con un balanceador de cargas interno en cuya regla de reenvío se usa una dirección IP del rango disponible en esa subred.

    • Los prinicpales de IAM que supervisan todo el servicio web son administradores de proyectos de servicio en ambos proyectos de servicio y cuentan con permisos a nivel de proyecto en el proyecto host a fin de que puedan usan cualquier subred definida en este.

    • Existe la opción de que los administradores de VPC compartida puedan delegar tareas de administración de la red a los Administradores de la red y seguridad.

Próximos pasos