Descripción general de la VPC compartida

En la VPC compartida, se pueden conectar los recursos de varios proyectos de una organización 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 usas una VPC compartida, debes designar un proyecto como proyecto host y conectarle uno o más proyectos de servicio. Las redes de VPC en el proyecto host se conocen como redes de VPC compartida. Para los recursos aptos de proyectos de servicio, se pueden usar subredes en la red de VPC compartida.

Con la VPC compartida, los administradores de la organización pueden delegar responsabilidades administrativas, como la creación y administración de instancias, a los administradores de proyectos de servicio, a la vez que mantienen un control centralizado sobre los recursos de la red, como subredes, rutas y firewalls. En este modelo, se permite que las organizaciones hagan lo siguiente:

  • Pueden implementar una práctica recomendada 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.
  • Pueden usar 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

Mediante la VPC compartida, se conectan proyectos dentro de la misma organización. Los proyectos host y de servicio participantes no pueden pertenecer a organizaciones diferentes. 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.

Un servicio que participa de una VPC compartida puede ser tanto 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 VPC compartida puede conectarle uno o más proyectos de servicio.

  • Un proyecto de servicio es cualquier proyecto que un administrador de 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 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. Consulta ejemplo de múltiples proyectos host a fin de ver una ilustración.

Para mayor claridad, a un proyecto que no participa en la VPC compartida se lo llama proyecto independiente. Esto muestra que no es ni un proyecto host ni un proyecto de servicio.

Redes

Una red de VPC compartida es una red de VPC que se definió en un proyecto host y se encuentra disponible como una red compartida de forma 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, todas sus redes de VPC existentes se convierten en redes de VPC compartida, y cualquier red nueva creada en esta será automáticamente una red de VPC compartida también. Por lo tanto, un solo proyecto host puede tener más de una red de VPC compartida.

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.

Restricciones 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. Mediante las políticas de la organización, puedes 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 restricciones de 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 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.

Los administradores y la IAM

En la VPC compartida, se utilizan las funciones de administración de identidades y accesos (IAM) para la administración delegada. Las siguientes funciones se pueden otorgar a los miembros 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)
  • Miembro de IAM en la organización
Los administradores de la organización tienen la función de 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; sin embargo, para las acciones específicas de carpetas y proyectos, se requieren otras funciones de carpetas y proyectos.
Administrador de VPC compartida
(compute.xpnAdmin y
resourcemanager.projectIamAdmin)
  • Miembro de IAM en la organización o
  • Miembro de IAM en una carpeta (Beta)
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)
  • Miembro de IAM en la organización,
  • Miembro de IAM en un proyecto host o
  • Miembro de IAM en algunas subredes del proyecto host
Un administrador de VPC compartida define un administrador de proyectos de servicio cuando le otorga a un miembro 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 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 define cada administrador de proyectos de servicios, un administrador de VPC compartida puede otorgar los siguientes permisos para utilizar 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 VPC compartida le otorga la función de compute.networkUser en todo el proyecto host. Como resultado, ese administrador de proyectos de servicio tiene permiso para utilizar las subredes en todas las redes de 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 VPC compartida le otorga la función de 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 miembros de IAM:

Administrador Objetivo
Administrador de red
  • Miembro de IAM en el proyecto host o
  • Miembro de IAM en la organización
El administrador de VPC compartida define un administrador de red cuando le otorga a un miembro 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
  • Miembro de IAM en el proyecto host o
  • Miembro de IAM en la organización
Un administrador de VPC compartida puede definir un administrador de seguridad si le otorga a un miembro 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 reglas utilizadas a fin de calcular los importes de facturación de recursos en proyectos de servicio que se emplean en una red de VPC compartida son las mismas que las calculadas para los recursos 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 usar la VPC compartida a fin de organizar los recursos en centros de costos para tu organización.
    • Los costos relacionados con el balanceador de cargas se cobran 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 de salida a través de la puerta de enlace de VPN, sin importar con qué proyecto de servicio se inicie la salida, se atribuye al proyecto host.
    • Los costos por el tráfico de salida de un adjunto de interconexión (VLAN) en un proyecto de servicio de VPC compartida, que se trasladan mediante una conexión de Cloud Interconnect en un proyecto host, se atribuyen al proyecto host.

Recursos

Recursos aptos

Los siguientes recursos de proyectos de servicio pueden participar en la VPC compartida con ciertas limitaciones prácticas:

Para conocer otros recursos aptos, revisa la documentación del producto relacionado.

Limitaciones prácticas de los recursos aptos

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.

  • Si creas una instancia de VM con varias interfaces de red en un proyecto de servicio, solo su primera interfaz de red (nic0) puede hacer referencia a una subred en una red de VPC compartida. Todas las demás interfaces de red deben hacer referencia a una subred en una red de VPC independiente en el proyecto de servicio.

  • Si creas una instancia de VM con varias interfaces de red en el proyecto host, puedes hacer referencia a subredes de cualquier red de VPC compartida en cualquier interfaz de red.

Recursos no aptos

Con Deployment Manager, solo se pueden administrar recursos en un único proyecto, por lo que se requiere una configuración específica para el uso en una situación de VPC compartida. Consulta Crea una VPC compartida con Deployment Manager para obtener más información.

Direcciones IP

Mediante direcciones IP internas efímeras o estáticas reservadas, que están sujetas a las reglas de firewall aplicables, se pueden establecer comunicaciones entre las instancias de proyectos de servicio que están conectados a un proyecto host y en los que se usa la misma red de VPC compartida.

Una dirección IP interna 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 una zona, la red de VPC compartida y una subred disponible. Esta dirección IP proviene de un rango de direcciones IP disponibles en la subred compartida seleccionada.

Alternativamente, un administrador de proyectos de servicio puede optar por reservar una dirección IP interna estática. El objeto de la dirección IP debe crearse en el mismo proyecto de servicio que la instancia que lo usará, aunque el valor de la dirección IP provendrá del rango de IP disponibles en cierta subred compartida de la red de VPC compartida. Consulta Reserva una IP interna estática en la página Aprovisiona la VPC compartida para obtener más información.

Solo los recursos de ese proyecto pueden utilizar las direcciones IP externas definidas en el proyecto host. No están disponibles para su uso en proyectos de servicio. Los proyectos de servicio pueden mantener su propio conjunto de direcciones IP externas. Por ejemplo, una instancia en un proyecto de servicio debe utilizar una dirección IP externa definida en ese mismo proyecto de servicio. Esto sucede incluso si la instancia utiliza una dirección IP interna de una red de VPC compartida en el proyecto host.

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 utilizar las zonas privadas de Cloud DNS en una red de VPC compartida. Debes crear tu zona privada en el proyecto host y autorizar el acceso a la zona para la red de VPC compartida.

Balanceo de cargas

La VPC compartida puede usarse junto con el balanceo de cargas. Todos los componentes de balanceo de cargas deben existir en el mismo proyecto, ya sea todos en un proyecto host o todos en un proyecto de servicio. No se admite la creación de algunos componentes del balanceador de cargas en un proyecto host y otros en un proyecto de servicio conectado. Sin embargo, cuando creas la regla de reenvío interna para un balanceador de cargas interno (de TCP/UDP, HTTP o HTTPS) de un proyecto de servicio, debes hacer referencia a una subred compartida en el proyecto host al que está conectado el proyecto de servicio. Para obtener más información, consulta Crea un balanceador de cargas de TCP/UDP interno y Crea un balanceador de cargas de HTTP(S) interno en la página Aprovisiona VPC compartidas.

En la siguiente tabla, se resume dónde se deben crear los componentes del balanceo de cargas. 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.

Balanceador de cargas Dirección IP Regla de reenvío Otros componentes de frontend Componentes de backend
Balanceo de cargas de TCP/UDP interno Se debe definir una dirección IP interna en el mismo proyecto que las instancias de backend. Se debe definir una regla de reenvío interna en el mismo proyecto que las instancias de backend (el proyecto de servicio). No aplicable. Se debe definir un servicio de backend regional en el mismo proyecto que las instancias de backend. Las verificaciones de estado asociadas a los servicios de backend también deben definirse en el mismo proyecto.
Balanceo de cargas de TCP/UDP externo Debe definirse una dirección IP externa regional en el mismo proyecto que las instancias con balanceo de cargas. Se debe definir una regla de reenvío regional externa en el mismo proyecto que las instancias en el grupo de destino (el proyecto de servicio). No aplicable. El grupo de destino debe definirse en el mismo proyecto y en la misma región en que existen las instancias en el grupo de destino. Las verificaciones de estado asociadas con el grupo de destino también deben definirse en el mismo proyecto.
Balanceo de cargas de HTTP(S) interno Se debe definir una dirección IP interna en el mismo proyecto que el balanceador de cargas. Se debe definir una regla de reenvío interna en el mismo proyecto que las instancias de backend (el proyecto de servicio). Se debe definir un proxy HTTP(S) regional de destino y el mapa de URL regional asociado en el mismo proyecto que las instancias de backend. Se debe definir un servicio de backend regional en el mismo proyecto que usan las instancias de backend. Las verificaciones de estado asociadas a los servicios de backend también deben definirse en el mismo proyecto.
Balanceo de cargas de HTTP(S) externo Debe definirse una dirección IP externa en el mismo proyecto que las instancias del balanceo de cargas (el proyecto de servicio). La regla de reenvío externa se debe definir en el mismo proyecto que las instancias de backend (el proyecto de servicio). El proxy HTTP de destino o el proxy HTTPS de destino y el mapa de URL asociado deben definirse en el mismo proyecto que las instancias de backend. Se debe definir un servicio de backend global en el mismo proyecto que las instancias de backend. Estas instancias deben estar en grupos de instancias vinculadas al servicio de backend como backends. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.
Balanceo de cargas del proxy SSL El proxy SSL de destino debe definirse en el mismo proyecto que las instancias de backend.
Balanceo de cargas del proxy TCP El proxy TCP de destino se debe definir en el mismo proyecto que las instancias de backend.

Ejemplos y casos de uso

Conceptos básicos

En el siguiente ejemplo, se ilustra una situación de VPC compartida simple:

Conceptos básicos (haz clic para ampliar)
Conceptos básicos (haz clic para ampliar)
  • 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 miembros de IAM que tienen, como mínimo, la función de compute.InstanceAdmin para el proyecto.

Múltiples proyectos host

En el siguiente ejemplo, se muestra cómo la VPC compartida puede utilizarse para compilar entornos de producción y de prueba separados. Para este caso, una organización decidió utilizar dos proyectos host separados, un entorno de prueba y un entorno de producción.

Múltiples proyectos host (haz clic para ampliar)
Múltiples proyectos host (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 de cada proyecto de servicio pueden estar configurados para acceder a todas las subredes de Testing Network o solo a algunas de ellas.

    • Los proyectos de servicio Apps Production y Mobile Production se conectan al proyecto host Production Environment. Los administradores de cada proyecto de servicio pueden estar configurados para acceder a todas las subredes de Production Network o solo a algunas de ellas.

  • 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 el siguiente ejemplo, se muestra cómo una VPC compartida puede usarse en un entorno híbrido.

Nube híbrida (haz clic para ampliar)
Nube híbrida (haz clic para ampliar)

Para este ejemplo, una organización creó un proyecto solo 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 de un proyecto no tenga permisos para otro proyecto.

    • El administrador de VPC compartida le otorgó permisos a nivel de la subred o del proyecto a los administradores de proyectos de servicios necesarios para que puedan crear instancias que utilicen 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. En Instance A, se 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. En Instance C, se 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 miembros 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 la 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 las subredes de VPC con todas 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 el siguiente ejemplo, se muestra cómo una VPC compartida puede utilizarse 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. En el nivel 1, se representa el componente externo, detrás de un balanceador de cargas de HTTP(S). En el nivel 2, se representa un servicio interno del que depende el nivel 1. El nivel 2 se balancea mediante un balanceador de cargas TCP/UDP interno.

Servicio web de dos niveles (haz clic para ampliar)
Servicio web de dos niveles (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 miembros 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 miembros 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 miembros 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 del proyecto en el proyecto host a fin de que puedan utilizar 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