Descripción general de la VPC compartida

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 puedan comunicarse entre sí de manera segura y eficiente mediante las IP internas de esa red. Cuando usas una VPC compartida, debes designar un proyecto como el proyecto host y vincular uno o más proyectos de servicio con él. 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 la creación y administración de instancias, a los administradores del proyecto de servicio, a la vez que mantienen un control centralizado sobre los recursos de la red, como subredes, rutas y firewalls. Este modelo permite que las organizaciones pongan en práctica tareas como las siguientes:

  • Pueden implementar una práctica recomendada de seguridad de menor privilegio para la administración de red, la auditoría y el control de acceso. Los administradores de VPC compartida pueden delegar tareas de administración de red a los administradores de red y seguridad en la red de VPC compartida sin permitir que los administradores del proyecto de servicio realicen cambios en la red. Los administradores del proyecto de servicio solo tienen la capacidad de crear y administrar instancias que usen la red de VPC compartida. Consulta la sección Administradores y la IAM para obtener más detalles.
  • Pueden aplicar y poner en práctica políticas unificadas de control de acceso 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 del proyecto de servicio pueden ser administradores de las instancias de procesamiento en sus proyectos, y crear y borrar instancias que usen subredes aprobadas en el proyecto host de la VPC compartida.
  • Pueden usar proyectos de servicio para separar los centros de presupuestos o de costos internos. Consulta la sección 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 host y de servicio involucrados no pueden pertenecer a organizaciones diferentes. Los proyectos vinculados pueden estar en la misma carpeta o en carpetas distintas, pero, 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 proyecto que forma parte de una VPC compartida puede ser un proyecto host o 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 vincular uno o más proyectos de servicio con este.

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

  • Un proyecto no puede ser un proyecto host y un proyecto de servicio a la vez. Por este motivo, un proyecto de servicio no puede ser un proyecto host para otros proyectos de servicio.

  • Puedes crear y usar múltiples proyectos host; sin embargo, cada proyecto de servicio puede vincularse solo con un proyecto host. Consulta el ejemplo de múltiples proyectos host a fin de ver una ilustración.

Para ser claros, a un proyecto que no participe en la VPC compartida se lo llama proyecto independiente. Esto indica 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 se habilita un proyecto host, todas sus redes de VPC existentes se convierten en redes de VPC compartida, y, de forma automática, cualquier red nueva que se cree en este proyecto también será una red de VPC compartida. Por lo tanto, un 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 del proyecto 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. 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 restricciones de VPC compartida en una política de la organización:

  • Puedes limitar el conjunto de proyectos host con el que se puede vincular un proyecto o proyectos que no sean host en una organización o carpeta. La restricción se aplica cuando un administrador de VPC compartida vincula un proyecto de servicio con un proyecto host. La restricción no afecta a las vinculaciones existentes. Las vinculaciones existentes 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 restringir las subredes de VPC compartida a las que pueden acceder los proyectos de servicio a nivel de proyecto, organización o carpeta. 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 nuevos recursos. Para obtener más información, consulta la restricción constraints/compute.restrictSharedVpcSubnetworks.

Administradores y la IAM

beta

La VPC compartida usa las funciones de la 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 la organización.

Funciones administrativas requeridas

Administrador (función de IAM) Propósito
Administrador de la organización (resourcemanager.organizationAdmin)
• Miembro 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 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)
• Miembro de IAM en la organización o
• Miembro de IAM en una carpeta (Beta)
Los administradores de VPC compartida tienen funciones de administrador de VPC compartida de Compute (compute.xpnAdmin) y administrador de IAM del proyecto (resourcemanager.projectIamAdmin) dentro de la organización, o dentro de una o más carpetas. Realizan diversas tareas que son necesarias para configurar la VPC compartida, como habilitar proyectos host, vincular proyectos de servicio con proyectos host y delegar el acceso a algunas o todas las subredes en las redes de VPC compartida a los administradores del proyecto 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 asignó la función de administrador de VPC compartida de Compute en la organización tiene esa función en 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 las demás carpetas anidadas en ella. Un administrador de VPC compartida puede vincular proyectos en dos carpetas distintas solo si el administrador tiene la función para ambas carpetas.
Administrador del proyecto 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 proyecto 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 sus redes de VPC compartida. Los administradores del proyecto 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). Es posible que tengan funciones de IAM adicionales en los proyectos de servicio, como la función de propietario del proyecto.

Administradores de proyectos de servicio

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

  • Permisos a nivel de proyecto: un administrador del proyecto 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 del proyecto de servicio tiene permiso para usar todas 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 del proyecto de servicio puede obtener un conjunto más restrictivo de permisos para usar solo algunas subredes si el administrador de VCP compartida le otorga la función de compute.networkUser en esas subredes seleccionadas. Un administrador del proyecto de servicio que solo cuenta con permisos a nivel de subred está restringido a usar nada más esas subredes. 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 compute.networkUser a fin de asegurarse de que los permisos a nivel de subred de todos los administradores del proyecto 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, lo que incluye la administración de la red de VPC compartida. Pueden optar por delegar ciertas tareas de administración de red a otros miembros de IAM:

Administrador Propósito
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 red tienen control total sobre los recursos de la red, excepto 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 VPC compartida están sujetos a cuotas de VPC por proyecto estándar. Las redes de VPC compartida están sujetas a límites por red y por instancia para las redes de VPC. Además, la relación entre los proyectos host y de servicio está regida por 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 el recurso use la red de VPC compartida en el proyecto host.

  • Las tarifas y 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 se usarían si los recursos estuvieran ubicados en el mismo proyecto host.
  • La facturación por el tráfico de salida que genera un recurso se atribuye al proyecto en el que este se encuentra definido:
    • 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 usa 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 suman al proyecto que contiene los componentes del balanceador de cargas. Si deseas obtener más detalles acerca del balanceo de cargas y la VPC compartida, consulta la sección de 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, la puerta de enlace está contenida en el proyecto host. El tráfico de salida mediante la puerta de enlace de VPN, sin importar qué proyecto de servicio inicie la salida, se atribuye al proyecto host.

Recursos

Recursos aptos

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

Para descubrir 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 deben usar 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 vincula un proyecto existente con un proyecto host, ese proyecto se convierte en un proyecto de servicio, pero sus recursos existentes no usan de forma automática los recursos de la red compartida. A fin de usar una red de VPC compartida, un administrador del proyecto de servicio debe crear un recurso apto y configurarlo para que use una subred de una red de VPC compartida. Por ejemplo, no se puede volver a configurar una instancia existente en un proyecto de servicio a fin de que use una red de VPC compartida, pero se puede crear una instancia nueva para que use las subredes disponibles en una red de VPC compartida. Esta limitación se aplica a zonas privadas.

Recursos no aptos

Deployment Manager solo puede administrar recursos en un solo proyecto, por lo que usarlo en una situación de VPC compartida requiere una configuración específica. Consulta Crea una VPC compartida con Deployment Manager para obtener más información.

Direcciones IP

Las instancias de proyectos de servicio que están vinculadas con un proyecto host y usan la misma red de VPC compartida pueden comunicarse entre ellas mediante direcciones IP internas efímeras o estáticas y reservadas, que están sujetas a las reglas de firewall aplicables.

Una dirección IP interna y efímera se puede asignar de forma automática a una instancia en un proyecto de servicio. Por ejemplo, cuando los administradores del proyecto de servicio crean instancias, seleccionan una zona, una red de VPC compartida y una subred disponible. Esta dirección IP proviene de un rango de direcciones IP disponibles en la subred compartida que se seleccionó.

Como alternativa, un administrador del proyecto de servicio puede optar por reservar una dirección IP interna y 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 la subred compartida que se seleccione en la red de VPC compartida. Consulta Reserva una IP interna y estática en la página Aprovisiona una VPC compartida para obtener más información.

Con respecto a las direcciones IP externas que se definen en el proyecto host, solo los recursos de ese proyecto las pueden usar. 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 usar una dirección IP externa definida en ese mismo proyecto de servicio. Esto sucede incluso si la instancia usa una dirección IP interna de una red de VPC compartida en el proyecto host.

DNS interno

Las VM en el mismo proyecto de servicio pueden comunicarse entre sí mediante los nombres de DNS interno que Google Cloud crea de forma automática. Estos nombres de DNS usan el ID del proyecto de servicio en el que 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 interno y VPC compartida en la documentación de DNS interno.

Zonas privadas de Cloud DNS

Puedes usar 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 del balanceo de cargas deben existir en el mismo proyecto, ya sea todos en el 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 vinculado. Sin embargo, cuando creas la regla de reenvío interno para un balanceador de cargas TCP/UDP interno en un proyecto de servicio, debes hacer referencia a una subred compartida en el proyecto host al que está vinculado el proyecto de servicio. Para obtener más información, consulta Crea un balanceador de cargas TCP/UDP interno en la página Aprovisiona una VPC compartida.

En la siguiente tabla, se resumen los componentes de HTTP(S), del proxy SSL y del balanceo de cargas del proxy TCP. En la mayoría de los casos, las instancias de backend se crean en un proyecto de servicio. En este caso, todos los componentes del balanceador de cargas se crean en ese proyecto. También es posible crear las instancias de backend en el proyecto host. En ese caso, todos los componentes del balanceador de cargas deberán estar en el proyecto host.

Balanceador de cargas Dirección IP Regla de reenvío Otros componentes de frontend Componentes de backend
Balanceo de cargas HTTP(S) 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 externo debe definirse 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 asociadas a los servicios de backend también 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 debe definirse en el mismo proyecto que las instancias de backend.

En la siguiente tabla, se resumen los componentes para el balanceo de cargas de red:

Dirección IP Regla de reenvío Componentes de backend
Debe definirse una dirección IP externa y regional en el mismo proyecto que las instancias del balanceo de cargas. Debe definirse una regla de reenvío regional y externa en el mismo proyecto que las instancias en el grupo de destino (el proyecto de servicio). El grupo de destino debe definirse en el mismo proyecto y en la misma región en los que existen las instancias en el grupo de destino. Las verificaciones de estado asociadas al grupo de destino también deben definirse en el mismo proyecto.

En la siguiente tabla, se resumen los componentes para el balanceo de cargas TCP/UDP interno. Consulta Crea un balanceador de cargas TCP/UDP interno en la página Aprovisiona una VPC compartida para ver un ejemplo.

Dirección IP Regla de reenvío Componentes de backend
Se debe definir un objeto de la dirección IP interna en el mismo proyecto que las VM del balanceo de cargas.

Para que el balanceador de cargas esté disponible en una red de VPC compartida, el objeto de la dirección IP interna de Google Cloud debe definirse en el mismo proyecto de servicio en el que se encuentran las VM de backend. Además, debe hacer referencia a una subred en la red de VPC compartida que se desea usar en el proyecto host. La dirección en sí proviene del rango de IP principal de la subred a la que se hace referencia.

Si creas un objeto de la dirección IP interna en un proyecto de servicio que hace referencia a una subred en una red de VPC dentro del proyecto de servicio, el balanceador de cargas TCP/UDP interno será local para esa red, no para cualquier red de VPC compartida.
Se debe definir una regla de reenvío interna en el mismo proyecto que las VM del balanceo de cargas.

Para que el balanceador de cargas esté disponible en una red de VPC compartida, la regla de reenvío debe definirse en el mismo proyecto de servicio en el que se encuentran las VM de backend. Además, debe hacer referencia a la misma subred (en la red de VPC compartida) a la que hace referencia la dirección IP interna asociada.

Si creas una regla de reenvío interna en un proyecto de servicio que hace referencia a una subred en una red de VPC dentro del proyecto de servicio, el balanceador de cargas TCP/UDP interno será local para esa red, no para cualquier red de VPC compartida.
En una situación de VPC compartida, las VM de backend se ubican en un proyecto de servicio. En ese proyecto de servicio, debe definirse un servicio de backend interno y regional y una verificación de estado.

Ejemplos y casos prácticos

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 vinculó dos proyectos de servicio con él:

    • Los administradores del proyecto de servicio en Service Project A pueden configurarse a fin de que accedan a todas las subredes en la red de VPC compartida o solo a algunas de ellas. Un administrador del proyecto de servicio que tiene, como mínimo, permisos a nivel de subred para la 10.0.1.0/24 Subnet creó 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 del proyecto de servicio en Service Project B pueden configurarse a fin de que accedan a todas las subredes en la red de VPC compartida o solo a algunas de ellas. Un administrador del proyecto de servicio que tiene, como mínimo, permisos a nivel de subred para la 10.15.2.0/24 Subnet creó 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 en absoluto; no es un proyecto host ni un proyecto de servicio. Las instancias independientes son creadas por miembros de IAM que tienen, como mínimo, la función compute.InstanceAdmin para el proyecto.

Múltiples proyectos host

En el siguiente ejemplo, se muestra cómo la VPC compartida puede usarse para compilar entornos de prueba y de producción independientes. Para este caso, una organización decidió usar dos proyectos host diferentes, 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 de la organización creó dos proyectos host y vinculó dos proyectos de servicio con él de la siguiente manera:

    • Los proyectos de servicio Apps Testing y Mobile Testing se vinculan con el proyecto host Test Environment. Los administradores del proyecto de servicio en cada uno de ellos pueden estar configurados para acceder a todas las subredes en el Testing Network o solo a algunas de ellas.

    • Los proyectos de servicio Apps Production y Mobile Production se vinculan con el proyecto host Production Environment. Los administradores del proyecto de servicio en cada uno de ellos pueden estar configurados para acceder a todas las subredes en el Production Network o solo a algunas de ellas.

  • Ambos proyectos host tienen una red de VPC compartida con subredes configuradas para que usen los mismos rangos de 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:

    • Los administradores del proyecto de servicio pueden crear instancias como estas siempre que tengan, como mínimo, permisos a nivel de subred para la 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 que está 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 que usan la 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 distintos proyectos. Debido a que la 10.0.1.0/24 Subnet se encuentra en la región us-west1, los administradores del proyecto de servicio que crean instancias y que usan 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 host único 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 alojan de forma local:

  • Un administrador de VPC compartida habilitó el proyecto host y le conectó 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 del proyecto de servicio dentro de un proyecto no tenga permisos en otro proyecto.

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

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

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

      • Un administrador del proyecto de servicio para el Service Project C que tenga permisos 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 la Instance C en la 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. La Instance C recibe su dirección IP, 10.7.1.50, del rango de direcciones IP gratuitas en la 10.7.1.0/24 Subnet.

    • Cada proyecto de servicio se factura por separado.

    • Los administradores del proyecto de servicio en cada proyecto son responsables de crear y administrar los recursos.

  • Un administrador de VPC compartida delegó las tareas de administración de red a otros miembros de IAM que son administradores de red y seguridad en la red de VPC compartida.

    • Un administrador de 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. Cloud VPN intercambia y recibe rutas con su contraparte local porque se configuró Cloud Router 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 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 de los proyectos de servicio están sujetas a las reglas aplicables de firewall y pueden configurarse para que se comuniquen con servicios internos, como servidores locales de bases de datos o directorios.

Servicio web de dos niveles

En el siguiente ejemplo, se muestra cómo una VPC compartida puede usarse 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 de HTTP(S). El nivel 2 representa un servicio interno del que depende el nivel 1 y 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 a proyectos diferentes a fin de que puedan administrarlos distintos equipos mientras comparten una red de VPC en común:

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

  • A cada proyecto de servicio de nivel, un administrador de VCP compartida lo vinculó al proyecto host. El administrador de VPC compartida también habilitó el proyecto host.

    • Distintos equipos pueden administrar cada nivel del servicio web, ya que son administradores del proyecto de servicio en el proyecto de servicio correspondiente.

    • Cada proyecto de servicio se factura por separado.

    • Los administradores del proyecto de servicio en cada proyecto son responsables de crear y administrar los 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 del proyecto de servicio en el Tier 1 Service Project y tienen permisos a nivel de subred solo para la 10.0.1.0/24 Subnet. En este ejemplo, uno de estos administradores del proyecto de servicio creó tres Tier 1 Instances en esa subred.

    • Los miembros de IAM que solo trabajan en el nivel 2 son administradores del proyecto de servicio en el Tier 2 Service Project y tienen permisos a nivel de subred solo para la 10.0.2.0/24 Subnet. En este ejemplo, otro administrador del proyecto de servicio creó tres Tier 2 Instances en esa subred junto con un balanceador de cargas interno cuya regla de reenvío usa una dirección IP del rango disponible en esa subred.

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

    • Como opción, los administradores de VPC compartida pueden delegar tareas de administración de red a los administradores de red y seguridad.

Próximos pasos