Saltar al contenido principal
Esta página describe una forma de ejecutar Claude apps gateway en Google Cloud. La configuración es un ejemplo funcional para infraestructura administrada por el cliente en lugar de una implementación de producción compatible; úsela para ver cómo encajan las piezas antes de adaptarla a su propio entorno. Para los requisitos independientes de la plataforma, consulte la guía de implementación.
Este ejemplo aprovisiona Claude apps gateway en Google Cloud con Google Cloud’s Agent Platform como el upstream del modelo, utilizando Cloud Run o GKE para la computación. Google Workspace es el ejemplo del proveedor de identidad (IdP), pero cualquier proveedor de identidad compatible con OpenID Connect (OIDC) funciona; solo cambia el bloque oidc. Consulte Configuración del proveedor de identidad para obtener detalles específicos de cada IdP.

Lo que construirá

Diagrama de Claude apps gateway en Google Cloud: los clientes de Claude Code se conectan a través de HTTPS a la puerta de enlace (Cloud Run o GKE), que se ejecuta dentro de una VPC junto a una base de datos Cloud SQL de IP privada para el estado de la sesión. La puerta de enlace inicia sesión de usuarios a través de OIDC contra Google Workspace, lee la configuración y los secretos de Secret Manager, reenvía solicitudes de modelo a Agent Platform y extrae su imagen de Artifact Registry en la implementación.
El despliegue consta de:
  • Servicio Cloud Run o GKE Deployment ejecutando el contenedor de la puerta de enlace
  • Repositorio de Artifact Registry para la imagen de la puerta de enlace
  • Instancia de Cloud SQL para PostgreSQL, solo IP privada, para el store de la puerta de enlace
  • Secretos de Secret Manager para gateway.yaml, la clave de firma JWT, el secreto del cliente OIDC y la URL de Postgres
  • Cuenta de servicio con roles/aiplatform.user, adjunta directamente en Cloud Run o vinculada a través de Workload Identity en GKE
  • Front end HTTPS que tú proporcionas: un equilibrador de carga de aplicaciones interno delante de Cloud Run, para el cual esta guía configura el gateway pero que no crea, o un GKE Ingress interno de clase gce-internal en GKE

Requisitos previos

  • Un proyecto de GCP con facturación habilitada y permiso para crear los recursos anteriores
  • La CLI gcloud, autenticada con gcloud auth login, y Docker instalado localmente
  • Para la ruta de GKE: kubectl y un clúster de GKE en la VPC creada en el tutorial a continuación
  • Acceso a los modelos de Claude que necesita en Model Garden, en una región que los publique
  • Un cliente de aplicación web OAuth 2.0 de Google Workspace con URI de redirección https://<gateway-host>/oauth/callback; consulte Configuración del proveedor de identidad
  • Un nombre de host TLS para la puerta de enlace, típicamente un nombre DNS interno que apunta al equilibrador de carga
Establezca el proyecto y la región una vez:

Implementar la puerta de enlace

Los pasos a continuación aprovisionan la implementación completa con comandos gcloud.
1

Habilitar APIs

Habilite las API de servicio que utiliza el tutorial:
Las API que necesita dependen de la ruta de implementación:
  • compute y servicenetworking: necesarias para la ruta de Cloud SQL de IP privada
  • run: solo Cloud Run
  • container: solo GKE
2

Crear la cuenta de servicio y otorgar IAM

La puerta de enlace se ejecuta como una cuenta de servicio dedicada con permiso para llamar a Agent Platform. Alcanza Cloud SQL sobre la VPC con un usuario de contraseña, por lo que no se requiere ningún rol de IAM de Cloud SQL:
Luego habilite los modelos de Claude para el proyecto en Model Garden; los modelos se publican en regiones específicas, así que verifique cada tarjeta de modelo.
3

Construir e insertar la imagen en Artifact Registry

Construya la imagen según los requisitos de imagen de contenedor, utilizando el binario glibc linux-x64, e insértela:
4

Aprovisionar Cloud SQL para PostgreSQL

Cree la instancia en una VPC a través de Private Services Access para que no tenga IP pública; esto también satisface proyectos donde constraints/sql.restrictPublicIp se aplica:
El tiempo de ejecución de Cloud Run o GKE debe estar en, o enrutado hacia, esta VPC.
5

Escribir gateway.yaml

El bloque upstreams apunta a Agent Platform con auth: {}, por lo que la puerta de enlace se autentica a través de Application Default Credentials desde la cuenta de servicio del tiempo de ejecución. Consulte la referencia de configuración para cada campo.Dos campos de listen describen lo que está delante del gateway:
  • public_url: el origen https:// externo, obligatorio para cualquier enlace que no sea de loopback; consulta la referencia de listen. El gateway construye el redirect_uri del IdP y su documento de descubrimiento solo a partir de este valor, nunca a partir de encabezados X-Forwarded-*.
  • trusted_proxies: los rangos de origen del front end. El gateway respeta X-Forwarded-For solo cuando el par TCP está en esta lista, y luego recorre la cadena más allá de los saltos de confianza, de modo que los rate limits de inicio de sesión por IP y los eventos de auditoría registran las IP de los desarrolladores en lugar de la del balanceador de carga.
Establezca trusted_proxies para que coincida con su front end. Un GKE Ingress externo de clase gce no está listado: aprovisiona una dirección de regla de reenvío público, que la verificación de red privada de /login rechaza.El ejemplo a continuación utiliza los valores del equilibrador de carga interno frente a Cloud Run.
gateway.yaml
Los id_tokens de Google no llevan ninguna reclamación groups. Para usar políticas basadas en grupos en managed.policies con Google Workspace como IdP, configure oidc.google_groups, que busca los grupos de cada usuario a través de la API de Admin SDK Directory usando una cuenta de servicio con delegación en todo el dominio. Sin ella, coincida con email_domain en su lugar.
6

Almacenar secretos en Secret Manager

Cree cuatro secretos y otorgue roles/secretmanager.secretAccessor a la cuenta de servicio claude-gateway:La forma en que los secretos llegan al contenedor difiere según la ruta:
  • En GKE se montan como archivos a través del controlador CSI de Secret Manager, y gateway.yaml hace referencia a ${file:/secrets/...}.
  • En Cloud Run, que no puede montar múltiples secretos en un directorio, gateway.yaml se monta como un archivo y los otros tres se inyectan como variables de entorno, por lo que gateway.yaml hace referencia a ${GATEWAY_JWT_SECRET}, ${OIDC_CLIENT_SECRET} y ${GATEWAY_POSTGRES_URL} en su lugar.
7

Implementar

El comando a continuación se implementa para producción detrás de un equilibrador de carga interno.
La salida directa de VPC, mediante --network, --subnet y --vpc-egress=private-ranges-only, permite que el servicio acceda directamente a la IP privada de Cloud SQL. La salida pública hacia los endpoints de Agent Platform de Google Cloud y accounts.google.com va directamente a Internet en lugar de pasar por la VPC, por lo que no se necesita Cloud NAT.
Cada instancia mantiene hasta store.max_connections conexiones de Postgres, cinco por defecto. Usa Dimensionar el pool de conexiones para comprobar --max-instances=8 frente a las conexiones que tu base de datos tiene disponibles para el gateway, e incluye las instancias adicionales que inicia una actualización gradual.
La verificación de IAM del invocador debe estar abierta o deshabilitada. La puerta de enlace ejecuta su propio OIDC y sus clientes no llevan ningún token de GCP, por lo que la verificación del invocador de Cloud Run tiene que admitir solicitudes no autenticadas. La autenticación OIDC de la puerta de enlace autentica la solicitud una vez que llega al contenedor, con allowed_email_domains controlando qué dominios pueden iniciar sesión.Dos indicadores admiten solicitudes no autenticadas:
  • --no-invoker-iam-check: deshabilita la verificación sin ningún enlace allUsers para administrar, y funciona bajo Domain Restricted Sharing
  • --allow-unauthenticated: otorga al rol run.invoker a allUsers; úselo si su organización no permite --no-invoker-iam-check
La restricción de ingreso a través de --ingress es una capa separada e independiente de la verificación del invocador; manténgala establecida para limitar el servicio a su red corporativa.Por defecto, la URL de Cloud Run *.run.app se resuelve a una dirección pública, que la verificación de red privada de /login rechaza. Dos topologías dan a los desarrolladores un nombre de host resolvible de forma privada, y Cloud Run no aprovisiona ninguno para usted:
  • Balanceador de carga de aplicaciones interno, la topología que asume el gateway.yaml de esta página: aprovisiona un balanceador de carga de aplicaciones interno delante del servicio con un nombre DNS interno y un certificado, y establece listen.public_url en ese nombre de host. El ajuste de ingreso internal ya admite tráfico de balanceadores de carga de aplicaciones internos; internal-and-cloud-load-balancing admite además balanceadores de carga de aplicaciones externos, cuyas direcciones públicas rechaza la verificación de red privada de /login, por lo que ninguna topología de esta página lo necesita.
  • Ingreso solo interno sin balanceador de carga: mantén el comando de despliegue tal como está y deja listen.public_url como la URL *.run.app, el valor predeterminado en los recursos de referencia a continuación. Para que *.run.app se resuelva de forma privada, tu equipo de red ya debe operar un endpoint de Private Service Connect para las API de Google, una zona privada de Cloud DNS que resuelva *.run.app en él y enrutamiento local hacia ese endpoint.
La guía de redes privadas de Google para Cloud Run cubre la infraestructura que ambas opciones necesitan. Verifique el inicio de sesión una vez que la puerta de enlace esté sirviendo en un nombre de host privado; hasta entonces, confirme que el contenedor se inició desde sus registros en Cloud Run.Actualice el URI de redirección autorizado del cliente OAuth a <public_url>/oauth/callback antes del primer inicio de sesión. Reimplemente después de cambiar public_url, porque la puerta de enlace construye su origen público solo a partir de esa configuración e ignora X-Forwarded-Host y X-Forwarded-Proto. X-Forwarded-For se honra para las IP de cliente solo cuando listen.trusted_proxies está establecido.
8

Enviar la URL del gateway a las máquinas de los desarrolladores

El gateway ya se está ejecutando, pero los desarrolladores no pueden acceder a él desde /login hasta que la URL del gateway esté en sus máquinas. Despliega el fragmento completo de configuración administrada, con forceLoginMethod, forceLoginGatewayUrl y la opción parentSettingsBehavior: "merge", en cada dispositivo mediante MDM. No hay ninguna opción de gateway en el selector de inicio de sesión que un desarrollador pueda seleccionar manualmente.

Referencia de Terraform

Los activos de implementación de referencia automatizan la ruta de Cloud Run en esta página; los activos de configuración e imagen se aplican a ambas rutas:
  • setup.sh: un aprovisionador gcloud idempotente que recorre la ruta completa de Cloud Run, desde habilitar API hasta la primera implementación
  • terraform/: la misma implementación como infraestructura como código, para una implementación de campo virgen: una aplicación dirigida para crear el repositorio de Artifact Registry, luego construir e insertar la imagen, luego una aplicación completa
  • gateway.yaml.example y un Dockerfile para la imagen de tiempo de ejecución sin distro
Los artefactos establecen por defecto el ingreso de Cloud Run a internal, lo que coincide con el comando de despliegue de esta página; ese ajuste funciona con o sin un Application Load Balancer interno delante del servicio, y los artefactos tampoco crean el equilibrador de carga. Los artefactos también establecen por defecto la capa del invocador a una concesión run.invoker de allUsers en lugar de --no-invoker-iam-check, lo inverso del tutorial de esta página; cualquiera funciona, y la elección depende de las restricciones de política de tu organización. Los activos se proporcionan como ejemplos funcionales, no como un artefacto de producción compatible; revíselos y adáptelos a su entorno.

Solución de problemas

Para errores de arranque y inicio de sesión de la puerta de enlace, consulte la tabla de solución de problemas independiente de la plataforma. Las entradas a continuación son específicas de Google Cloud.

Próximos pasos