Información sobre el acceso a las APIs de Google a través de endpoints

En este documento se ofrece una descripción general de los puntos finales de Private Service Connect que se usan para acceder a las APIs de Google.

De forma predeterminada, si tienes una aplicación que usa un servicio de Google, como Cloud Storage, tu aplicación se conecta al nombre de DNS predeterminado de ese servicio, como storage.googleapis.com. Los nombres de DNS predeterminados de los servicios de Google se resuelven en direcciones IP enrutables públicamente. Sin embargo, el tráfico enviado desde recursos deGoogle Cloud a esas direcciones IP permanece en la red de Google.

Con Private Service Connect, puedes crear endpoints privados con direcciones IP internas globales en tu red de VPC. Puedes asignar nombres de DNS a estas direcciones IP internas con nombres significativos, como storage-vialink1.p.googleapis.com y bigtable-adsteam.p.googleapis.com. Estos nombres y direcciones IP son internos de tu red VPC y de cualquier red on-premise que esté conectada a ella mediante túneles de Cloud VPN o asignaciones de VLAN. Puedes controlar qué tráfico llega a cada punto final y demostrar que el tráfico se mantiene dentro de Google Cloud.

Esta opción te da acceso a todas las APIs y servicios de Google incluidos en los paquetes de APIs.

Imagen 1. Private Service Connect te permite enviar tráfico a las APIs de Google mediante un endpoint privado de tu red de VPC (haz clic para ampliar).

Funciones y compatibilidad

En esta tabla se resumen las funciones que admiten los endpoints que se usan para acceder a las APIs de Google.

Configuración Detalles
Configuración del consumidor (endpoint)
Accesibilidad global Usa una dirección IP interna global
Tráfico de Cloud Interconnect
Tráfico de Cloud VPN
Acceso mediante el emparejamiento entre redes de VPC
Propagación de conexiones a través de Network Connectivity Center
Configuración automática de DNS
Versión de IP IPv4
Producer
Servicios admitidos APIs de Google globales admitidas

Acceso in situ

Se puede acceder a los puntos finales de Private Service Connect que usas para acceder a las APIs de Google desde los hosts on-premise conectados compatibles. Para obtener más información, consulta Acceder al endpoint desde hosts locales.

Private Service Connect y Directorio de servicios

Los endpoints se registran en Directorio de servicios. El Directorio de servicios es una plataforma para almacenar, gestionar y publicar servicios. Cuando creas un punto final para acceder a las APIs y los servicios de Google, seleccionas una región y un espacio de nombres de Directorio de servicios.

Región de Directorio de servicios

Service Directory es un servicio regional. La región que selecciones define dónde se encuentra el plano de control de Service Directory. No hay ninguna diferencia funcional entre las regiones, pero puede que tengas una preferencia por motivos administrativos.

Cuando creas el primer endpoint para las APIs de Google en una red de VPC, la región que seleccionas se usa como región predeterminada para todos los endpoints posteriores que se creen en esa red. Si aún no se ha definido una región para una red y no especifica ninguna, se asignará us-central1. Todos los endpoints de una red deben usar la misma región de Service Directory.

Espacio de nombres de Directorio de servicios

Cuando creas el primer endpoint para las APIs de Google en una red de VPC, el espacio de nombres que seleccionas se usa como espacio de nombres predeterminado para todos los endpoints que se creen posteriormente en esa red. Si el espacio de nombres aún no se ha definido para una red y no especificas uno, se usará un espacio de nombres generado por el sistema. Todos los endpoints de una red deben usar el mismo espacio de nombres de Service Directory. El espacio de nombres que elijas solo se debe usar para los endpoints que se utilicen para acceder a las APIs de Google. Puedes usar el mismo espacio de nombres para los endpoints de varias redes.

Cuando creas un endpoint, se crean las siguientes configuraciones de DNS:

  • Se crea una zona DNS privada de Directorio de servicios para p.googleapis.com

  • Los registros DNS se crean en p.googleapis.com para algunas APIs y servicios de Google de uso común que están disponibles mediante Private Service Connect y tienen nombres DNS predeterminados que terminan en googleapis.com.

    Consulta las instrucciones para crear registros DNS de APIs y servicios que no tengan un registro DNS en p.googleapis.com.

Los servicios disponibles varían en función de si seleccionas all-apis o el vpc-sc paquete de APIs.

Se crea una zona DNS de Directory de servicios para cada red VPC que contenga un endpoint.

Los nombres de DNS de un endpoint son accesibles en todas las regiones de tu red de VPC.

APIs admitidas

Cuando creas un endpoint para acceder a las APIs y los servicios de Google, eliges el paquete de APIs al que necesitas acceder: Todas las APIs (all-apis) o VPC-SC (vpc-sc).

Los paquetes de APIs solo admiten protocolos basados en HTTP a través de TCP (HTTP, HTTPS y HTTP/2). No se admiten otros protocolos, como MQTT e ICMP.

Paquete de APIs Servicios admitidos Ejemplo de uso
all-apis

Permite el acceso a la API a la mayoría de las APIs y los servicios de Google, independientemente de si son compatibles con Controles de Servicio de VPC. Incluye acceso a las APIs de Google Maps, Google Ads, Google Cloudy la mayoría de las demás APIs de Google, incluidas las que se indican en las listas de abajo. No es compatible con las aplicaciones web de Google Workspace, como Gmail y Documentos de Google. No admite ningún sitio web interactivo.

Nombres de dominio que coinciden:

  • accounts.google.com (solo admite las rutas necesarias para la autenticación OAuth de cuentas de servicio; la autenticación de cuentas de usuario es interactiva y no se admite)
  • *.aiplatform-notebook.cloud.google.com
  • *.aiplatform-notebook.googleusercontent.com
  • appengine.google.com
  • *.appspot.com
  • *.backupdr.cloud.google.com
  • backupdr.cloud.google.com
  • *.backupdr.googleusercontent.com
  • backupdr.googleusercontent.com
  • *.cloudfunctions.net
  • *.cloudproxy.app
  • *.composer.cloud.google.com
  • *.composer.googleusercontent.com
  • *.datafusion.cloud.google.com
  • *.datafusion.googleusercontent.com
  • *.dataproc.cloud.google.com
  • dataproc.cloud.google.com
  • *.dataproc.googleusercontent.com
  • dataproc.googleusercontent.com
  • dl.google.com
  • gcr.io o *.gcr.io
  • *.googleapis.com
  • *.gke.goog
  • *.gstatic.com
  • *.kernels.googleusercontent.com
  • *.ltsapis.goog
  • *.notebooks.cloud.google.com
  • *.notebooks.googleusercontent.com
  • packages.cloud.google.com
  • pkg.dev o *.pkg.dev
  • pki.goog o *.pki.goog
  • *.run.app
  • source.developers.google.com
  • storage.cloud.google.com

Elige all-apis en las siguientes circunstancias:

  • No usas Controles de Servicio de VPC.
  • Usas Controles de Servicio de VPC, pero también necesitas acceder a APIs y servicios de Google que no son compatibles con Controles de Servicio de VPC. 1

vpc-sc

Habilita el acceso a las APIs de Google y a los servicios compatibles con Controles de Servicio de VPC.

Bloquea el acceso a las APIs y los servicios de Google que no admiten Controles de Servicio de VPC. No admite APIs de Google Workspace ni aplicaciones web de Google Workspace, como Gmail y Documentos de Google.

Elige vpc-sc cuando solo necesites acceder a las APIs y los servicios de Google que sean compatibles con Controles de Servicio de VPC. El paquete vpc-sc no permite el acceso a las APIs y los servicios de Google que no admiten Controles de Servicio de VPC. 1

1 Si necesitas restringir el acceso de los usuarios solo a las APIs y los servicios de Google que admitan Controles de Servicio de VPC, usa vpc-sc, ya que ofrece medidas adicionales para mitigar el riesgo de filtración externa de datos. Si usas vpc-sc, se deniega el acceso a las APIs y los servicios de Google que no son compatibles con Controles de Servicio de VPC. Para obtener más información, consulta el artículo sobre configurar la conectividad privada en la documentación de Controles de Servicio de VPC.

Requisitos de las direcciones IP

Cuando configuras Private Service Connect en una red de VPC, proporcionas una dirección IP que se va a usar en el endpoint.

La dirección se incluye en la cuota del proyecto de direcciones IP internas globales.

La dirección IP debe cumplir las siguientes especificaciones:

  • Debe ser una sola dirección IP y no un intervalo de direcciones.

  • Debe ser una dirección IPv4 válida. Puede ser una dirección RFC 1918 o una dirección que no sea RFC 1918. Las direcciones IPv6 no se admiten en Private Service Connect.

  • No puede estar dentro del intervalo de subredes configuradas en la red de VPC.

  • No puede estar dentro de un intervalo de direcciones IP principal o secundario de ninguna subred de la red de VPC ni de una red conectada a la red de VPC mediante el emparejamiento entre redes de VPC.

  • No puede solaparse con una ruta estática personalizada /32 en la red de VPC local. Por ejemplo, si la red de VPC tiene una ruta estática personalizada para 10.10.10.10/32, no puedes reservar la dirección 10.10.10.10 para Private Service Connect.

  • No puede superponerse con una ruta estática personalizada de emparejamiento /32 si has configurado la red emparejada para exportar rutas personalizadas y has configurado tu red de VPC para importar rutas personalizadas.

  • No puede estar dentro de ninguno de los intervalos de IP del modo automático (en 10.128.0.0/9) si la red VPC local es una red en modo automático o si está emparejada con una red en modo automático.

  • No puede estar dentro de un intervalo de IPs asignado en la red de VPC local. Sin embargo, puede estar dentro de un intervalo de IP asignado en una red de VPC emparejada.

  • Si un endpoint se solapa con una ruta dinámica personalizada cuyo destino es el mismo /32, el endpoint tiene prioridad.

  • Si una dirección IP de endpoint se encuentra dentro del intervalo de destino de una ruta estática local, una ruta dinámica local o una ruta personalizada de peering, y esa ruta tiene una máscara de subred más corta que /32, el endpoint tiene mayor prioridad.

Casos prácticos

Puedes crear varios endpoints en la misma red VPC. No hay límite en el ancho de banda total enviado a un endpoint concreto. Como los endpoints usan direcciones IP internas globales, cualquier recurso de tu red de VPC o de una red on-premise conectada mediante túneles de Cloud VPN o vinculaciones de Cloud Interconnect puede usarlos.

Con varios endpoints, puedes especificar diferentes rutas de red mediante Cloud Router y reglas de firewall.

  • Puedes crear reglas de cortafuegos para impedir que algunas máquinas virtuales accedan a las APIs de Google a través de un endpoint, mientras que otras máquinas virtuales sí pueden acceder.

  • Puedes tener una regla de cortafuegos en una instancia de VM que no permita todo el tráfico a Internet. El tráfico enviado a los endpoints de Private Service Connect sigue llegando a Google.

  • Si tienes hosts on-premise conectados a una VPC mediante un túnel de Cloud VPN o una vinculación de VLAN, puedes enviar algunas solicitudes a través del túnel o de la VLAN y otras a través de Internet público. Esta configuración te permite omitir el túnel o la VLAN para servicios como Google Books, que no son compatibles con el acceso privado a Google.

    Para crear esta configuración, crea un endpoint de Private Service Connect, anuncia las direcciones IP del endpoint mediante anuncios de rutas personalizadas de Cloud Router y habilita una política de reenvío entrante de Cloud DNS. La aplicación puede enviar algunas solicitudes a través del túnel de Cloud VPN o de la vinculación de VLAN mediante el nombre del endpoint, y puede enviar otras solicitudes a través de Internet mediante el nombre de DNS predeterminado.

  • Si conectas tu red on-premise a tu red de VPC mediante varias vinculaciones de VLAN, puedes enviar parte del tráfico on-premise a través de una VLAN y el resto a través de otras, como se muestra en la figura 2. De esta forma, puedes usar tu propia red de área extensa en lugar de la de Google y controlar el movimiento de los datos para cumplir los requisitos geográficos.

    Para crear esta configuración, crea dos endpoints. Crea un anuncio de ruta personalizada para el primer endpoint en la sesión BGP del router de Cloud que gestiona la primera VLAN y crea otro anuncio de ruta personalizada para el segundo endpoint en la sesión BGP del router de Cloud que gestiona la segunda VLAN. Los hosts locales configurados para usar el nombre del endpoint envían tráfico a través de la vinculación de VLAN correspondiente.

  • También puedes usar varias vinculaciones de VLAN en una topología activa/activa. Si anuncia la misma dirección IP de endpoint mediante anuncios de rutas personalizadas para las sesiones BGP de los routers de Cloud que gestionan las VLANs, los paquetes enviados desde sistemas on-premise a los endpoints se enrutan a través de las VLANs mediante ECMP.

    Imagen 2. Si configuras Private Service Connect, Cloud Router y los hosts locales, puedes controlar qué vinculación de VLAN se usa para enviar tráfico a las APIs de Google (haz clic para ampliar la imagen).

Precios

Los precios de Private Service Connect se describen en la página de precios de VPC.

Cuotas

El número de puntos finales de Private Service Connect que puedes crear para acceder a las APIs de Google se controla mediante la PSC Google APIs Forwarding Rules per VPC Networkcuota. Para obtener más información, consulta las cuotas.

Restricciones de las políticas de organización

Un administrador de políticas de la organización puede usar la restricción constraints/compute.disablePrivateServiceConnectCreationForConsumers para definir el conjunto de tipos de endpoint para los que los usuarios no pueden crear reglas de reenvío.

Para obtener información sobre cómo crear una política de la organización que use esta restricción, consulta Impedir que los consumidores implementen endpoints por tipo de conexión.

Siguientes pasos