Descripción general de la VPC compartida

La VPC compartida permite que una organización conecte recursos desde proyectos múltiples a una red de VPC común, a fin de que puedan comunicarse entre ellas de forma 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 compartidas. Los recursos aptos de proyectos de servicio pueden utilizar 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 sobre los recursos de la red, como subredes, rutas y 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 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 participantes no pueden pertenecer a organizaciones diferentes. Los proyectos vinculados pueden estar en carpetas iguales o 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 GCP 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 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. Este vínculo le permite participar en una VPC compartida. Es común tener múltiples proyectos de servicio operados y administrados por departamentos o equipos diferentes de la organización.

  • Un proyecto no puede ser tanto un proyecto host como 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 definida en un proyecto host y disponible como una red compartida centralmente para recursos aptos en proyectos de servicio. Las redes de VPC compartida pueden ser tanto 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 al nivel del 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.

Administradores y la IAM

La VPC compartida utiliza las funciones de administración de identidades y accesos (IAM) para la administración delegada. Las siguientes funciones pueden otorgarse a miembros de IAM, como usuarios, grupos de Google, Google Domains o cuentas de servicio de GCP. 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 Objetivo
Administrador de la organización
  • Miembro de IAM en la organización
Los administradores de la organización tienen la función resourcemanager.organizationAdmin de tu 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 para 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
  • Miembro de IAM en la organización o
  • Miembro de IAM en una carpeta (versión Beta)
Los Administradores de VPC compartida tienen la función Administrador de VPC compartida (compute.xpnAdmin) de la organización o de una o más carpetas. Realizan diversas tareas necesarias para configurar la VPC compartida, como habilitar proyectos host, vincular proyectos de servicio a proyectos host y delegar 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 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 las demás carpetas anidadas a esta. 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
  • Miembro de IAM en un proyecto de servicio o
  • Miembro de IAM en la organización
Un Administrador de VPC compartida define un Administrador de proyectos de servicio; para ello, le otorga a un miembro de IAM la función usuario de red (compute.networkUser) ya sea para todo el proyecto host o para ciertas subredes de sus redes de VPC compartida. Los Administradores de proyectos de servicio también mantienen la propiedad y el control sobre los recursos definidos en los proyectos de servicio, por lo que deberían contar con la función Administrador de instancia (compute.instanceAdmin) en los proyectos de servicio correspondientes. Es posible que tengan funciones de IAM adicionales en los proyectos de servicio, como propiedad del proyecto.

Administradores de proyectos de servicio

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

  • Permisos a nivel del proyecto: Se puede definir que un Administrador de proyectos de servicio tenga permiso para utilizar todas las subredes en el proyecto host si el Administrador de VPC compartida le otorga la función compute.networkUser para todo el proyecto host. Como resultado, ese Administrador de proyectos de servicio tiene permiso para utilizar 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 la subred: Además, el Administrador de proyectos de servicio puede tener permisos para usar solamente algunas subredes si el Administrador de VPC compartida le otorga la función de compute.networkUser para esas subredes. Un Administrador de proyectos de servicio que solamente cuenta con permisos a nivel de la subred está restringido a utilizar únicamente esas subredes. Una vez que se agregan nuevas redes de VPC compartida o nuevas subredes en el proyecto host, un Administrador de VPC compartida deberá revisar los vínculos de permisos de la función compute.networkUser a fin de garantizar que los permisos a nivel de la subred de todos los Administradores de proyectos de servicio coincidan con la configuración deseada.

Administradores de redes 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 la 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 la red; para ello, le otorga a un miembro de IAM la función de Administrador de la red (compute.networkAdmin) del 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; para ello, le otorga a un miembro de IAM la función de Administrador de seguridad (compute.securityAdmin) del 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 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ímite 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 para calcular los importes de facturación de recursos en proyectos de servicio que utilicen una red de VPC compartida son las mismas que si los recursos estuvieran ubicados en el mismo proyecto host.
  • La facturación por el tráfico de salida generado por 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 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 cobran 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, 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:

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:

  • El uso de una red de VPC compartida no es obligatorio. 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 crear algunos recursos para poder utilizar 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 utilizan automáticamente los recursos de 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.

Recursos no aptos

En un proyecto de servicio, los recursos de App Engine Flexible no pueden participar en la VPC compartida.

Direcciones IP

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

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, 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 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 cómo reservar una IP interna estática en la página Aprovisionamiento de VPC compartida para obtener más información.

Solo 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 en el mismo proyecto de servicio pueden comunicarse entre sí mediante nombres DNS internos que GCP crea automáticamente. Estos nombres 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 compartidas en la documentación sobre DNS internos.

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. Además, debes activar las zonas DNS privadas dentro de cada proyecto de servicio. Para obtener una explicación completa, consulta Zonas privadas y VPC compartida en la Descripción general de Cloud DNS.

Balanceo de cargas

La VPC compartida puede usarse junto con el balanceo de cargas. Todos los balanceos 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 de balanceador de cargas en un proyecto host y otros en un proyecto de servicio vinculado. Sin embargo, la regla de reenvío interno para un balanceador de cargas interno creado en un proyecto de servicio puede hacer referencia a una subred compartida en el proyecto host al cual está vinculado el proyecto de servicio. Consulta cómo crear un balanceador de cargas interno en la página Aprovisionamiento de VPC compartida para obtener más información.

En la siguiente tabla, se resumen los componentes para los balanceadores de cargas HTTP(S), Proxy SSL y 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 de 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 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 de SSL El Proxy SSL de destino debe definirse en el mismo proyecto que las instancias de backend.
Balanceo de cargas del proxy de TCP El proxy de TCP de destino debe definirse en el mismo proyecto que las instancias de backend.

En la siguiente tabla, se resumen los componentes para los dos tipos de balanceadores de cargas regionales. En ella se destaca cómo una regla de reenvío interna para un balanceador de cargas interno puede hacer referencia a una subred compartida en una red de VPC compartida a fin de brindar balanceos de cargas internos dentro de esa red.

Balanceador de cargas Dirección IP Regla de reenvío Componentes de backend
Balanceo de cargas de red Debe definirse una dirección IP externa regional en el mismo proyecto que las instancias del balanceador de cargas. Debe definirse una regla de reenvío regional 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 donde existen las instancias en el grupo de destino. Las verificaciones de estado relacionadas con el grupo de destino también deben definirse en el mismo proyecto.
Balanceo de cargas interno La dirección IP interna puede provenir del proyecto host o de servicio:
  • Si el balanceador de cargas está disponible para la red de VPC compartida, la dirección IP interna debe provenir del rango de la dirección IP primaria de una subred compartida.
  • Si el balanceador de cargas es local para un proyecto de servicio, la dirección IP interna puede provenir de una subred en una red dentro del proyecto de servicio.
Debe definirse una regla de reenvío interna en el mismo proyecto que las instancias del balanceador de cargas; sin embargo, la subred a la cual hace referencia determina si el balanceador de cargas funciona en una situación de VPC compartida:
  • Si el balanceador de cargas está disponible para la red de VPC compartida, la regla de reenvío debe hacer referencia a una subred compartida. Consulta cómo crear un balanceador de cargas interno en la página Aprovisionamiento de VPC compartida para obtener indicaciones detalladas.
  • Si el balanceador de cargas fuera local para un proyecto de servicio, la regla de reenvío puede hacer referencia a una subred en una red en el proyecto de servicio.
Debe definirse un servicio de backend regional en el mismo proyecto que las instancias del balanceador de cargas. Las instancias del balanceador de cargas 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.

Ejemplos y casos prácticos

Conceptos básicos

El siguiente ejemplo ilustra una situación de una VPC compartida simple:

Conceptos básicos (hacer clic para ampliar)
Conceptos básicos (hacer 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 acceder a todas o algunas de las subredes en la red de VPC compartida. Un Administrador de proyectos de servicio con, por lo menos, permisos a nivel de subred para 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 de proyectos de servicio en Service Project B pueden configurarse a fin de acceder a todas o algunas de las subredes en la red de VPC compartida. Un Administrador de proyectos de servicio con, por lo menos, permisos a nivel de subred para 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 de servicio. Crean las instancias independientes los miembros de IAM que tienen, por lo menos, la función compute.InstanceAdmin del 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.

Proyectos host múltiples (hacer clic para ampliar)
Proyectos host múltiples (hacer clic para ampliar)
  • Un Administrador de VPC compartida para la organización creó dos proyectos host y les vinculó dos proyectos de servicio de la siguiente manera:

    • Los proyectos de servicio Apps Testing y Mobile Testing están vinculados al proyecto host Test Environment. Los Administradores de proyectos de servicio en cada uno pueden configurarse a fin de acceder a todas o algunas de las subredes en Testing Network.

    • Los proyectos de servicio Apps Production y Mobile Production están vinculados al proyecto host Production Environment. En cada uno, los Administradores de proyectos de servicio 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. Tanto en Testing Network como 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 también Instance AP en el proyecto de servicio Apps Production:

    • Los Administradores de proyectos de servicio pueden crear instancias como ellos, siempre que tengan, por lo menos, permisos a nivel de subred para 10.0.1.0/24 Subnet.

    • Ten en cuenta que ambas instancias utilizan 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 que utilicen la 10.0.1.0/24 Subnet deben estar ubicadas en una zona dentro de la misma región que la subred, incluso si la subred y las instancias se definen en proyectos separados. Debido a que la 10.0.1.0/24 Subnet está ubicada en la región us-west1, los administradores de proyectos de servicios 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 (hacer clic para ampliar)
Nube híbrida (hacer 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 están alojados en GCP, mientras que otros se mantienen de forma local:

  • Un administrador de VPC compartida habilitó el proyecto host y le vinculó tres proyectos de servicio: Service Project A, Service Project B y Service Project C.

    • Equipos separados 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 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 para Service Project A con permisos a nivel de la subred para la 10.0.1.0/24 Subnet puede crear una Instance A en ella. El Administrador de proyectos de servicio debe elegir una zona en la región us-west1 para la instancia, ya que esa será la región que contenga la 10.0.1.0/24 Subnet. Instance A recibe su dirección IP, 10.0.1.3, del rango de direcciones IP disponibles en la 10.0.1.0/24 Subnet.

      • Un Administrador de proyectos de servicio para Service Project B con permisos a nivel de la subred para la 10.15.2.0/24 Subnet puede crear una Instance B en ella. El Administrador de proyectos de servicio debe elegir una zona en la región us-east1 para la instancia, ya que esa será la región que contenga la 10.15.2.0/24 Subnet. Instance B recibe su dirección IP, 10.15.2.4, del rango de direcciones IP disponibles en la 10.15.2.0/24 Subnet.

      • Un Administrador de proyectos de servicio para Service Project C con permisos a nivel del proyecto para todo el proyecto host puede crear instancias en cualquiera de las subredes de cualquiera de las redes de VPC dentro del proyecto host. Por ejemplo, el Administrador de proyectos de servicio puede crear una Instance C en la 10.7.1.0/24 Subnet y seleccionar una zona en la región us-east1 para que coincida con la región de la subred. Instance C recibe su dirección IP, 10.7.1.50, del rango de direcciones IP en la 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. Cloud VPN intercambia y recibe rutas con sus contrapartes locales, ya que 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 VPC con todas las contrapartes locales.

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

    • Sujetas a las reglas aplicables de firewall, las instancias en los proyectos de servicio pueden configurarse 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. El nivel 1 representa el componente externo, detrás del balanceador de cargas HTTP global. El nivel 2 representa un servicio interno del cual depende el nivel 1 y se balancea mediante un balanceador de cargas interno.

Servicio web de dos niveles (hacer clic para ampliar)
Servicio web de dos niveles (hacer clic para ampliar)

La VPC compartida te permite asignar cada nivel del servicio web con proyectos deferentes 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 por equipos distintos.

  • Cada proyecto de servicio de nivel fue vinculado a un proyecto host por un Administrador de VPC compartida. 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 solamente trabajan en el nivel 1 son Administradores de proyectos de servicio para Tier 1 Service Project y reciben permisos a nivel de la subred solo para 10.0.1.0/24 Subnet. En este ejemplo, un Administrador de proyectos de servicio creó tres Tier 1 Instances en esa subred.

    • Los miembros de IAM que solamente trabajan en el nivel 2 son Administradores de proyectos de servicio para Tier 2 Service Project y reciben permisos a nivel de la 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 cuya regla de reenvío utiliza 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.

¿Qué sigue?

¿Te sirvió esta página? Envíanos tu opinión: