Comienza con la puerta de enlace de las aplicaciones Claude para Google Cloud.

La herramienta de codificación agencial de Anthropic, Claude Code, ha estado trabajando con Google Cloud durante un tiempo. Un desarrollador individual podría fácilmente apuntar CLAUDE_CODE_USE_VERTEX=1 a un proyecto de Google Cloud (GCP), otorgar el rol roles/aiplatform.user y la inferencia permanece dentro de su perímetro de Google Cloud. Ese flujo funciona muy bien cuando solo eres tú o un pequeño grupo de ingenieros. Pero implementarlo en toda una organización te obliga a lidiar con la fricción empresarial: tienes que gestionar las credenciales en la nube por desarrollador, enviar un managed-settings.json a cada computadora portátil a través de MDM, y no ser verificado con cero atribución de uso por desarrollador o límites de gasto fácilmente aplicables. La puerta de enlace de aplicaciones Claude cierra esa brecha. Es un servicio autohospedado, que se envía con el mismo binario de Claude, que se sitúa directamente entre tus clientes locales de Claude Code y Google Cloud. Esta publicación desglosa exactamente por qué deberías ejecutarlo y cómo se ve una implementación segura en Google Cloud. (Nota: Si deseas saltar directamente al código, el recorrido completo se encuentra en la puerta de enlace de aplicaciones Claude en la documentación de Google Cloud.)

Por qué ejecutar la puerta de enlace. Ejecuta la puerta de enlace para centralizar la gobernanza que los desarrolladores y los administradores de plataforma de otro modo llevarían cada uno solo, como identidad, política, costo y enrutamiento. Así es como se ve eso en la práctica. Identidad. La solicitud /login se enrutará a través de tu proveedor de identidad (IdP) - Google Workspace o cualquier OIDC/OpenID Connect - y la puerta de enlace intercambia el token por una sesión de corta duración. No se almacena información sensible en la computadora portátil del desarrollador, como claves de service-account, claves API o ANTHROPIC_VERTEX_PROJECT_ID. La incorporación es tan simple como agregar un usuario a un grupo IdP; la baja se realiza eliminándolos, y su próxima actualización de sesión falla en el acto. Política. Tus reglas de RBAC (control de acceso basado en roles) viven una vez en gateway.yaml, resueltas por grupo y aplicadas del lado del servidor. La puerta de enlace vuelve a verificar availableModels en cada llamada /v1/messages, por lo que editar el managed-settings.json local no cambia nada, y las actualizaciones de reglas llegan a toda la flota en menos de una hora. Telemetría. Cada métrica claude_code.token.usage lleva el correo electrónico verificado y los grupos del JWT de sesión (token de sesión firmado), no los OTEL_RESOURCE_ATTRIBUTES establecidos por el cliente que pueden ser falsificados. La puerta de enlace los envía a través de OTLP/HTTP a un colector que tú ejecutes: Cloud Monitoring, Grafana, Datadog, lo que sea que uses. Límites de gasto. Establece límites diarios, semanales o mensuales por usuario, grupo u organización a través de la API de administración; la puerta de enlace mide tokens contra un libro mayor de Cloud SQL y devuelve un 429 en el límite. Los costos están al precio de lista, así que trátalos como una barandilla de uso descontrolado, no como una reconciliación de facturas (los descuentos por uso comprometido y las tarifas negociadas no aparecen). Enrutamiento. Las llamadas salen bajo una única identidad de servicio de Cloud Run. Establece la región: global para el punto de enlace global de Agent Platform, o añade un segundo upstream: entrada para fallar en 5xx/429/timeout en orden de lista. De cualquier manera, la inferencia permanece en tu proyecto GCP: cuota, Acuerdo de Procesamiento de Datos y facturación, todo sin cambios.

Cómo encaja todo. Un proceso local o desplegado de claude de un desarrollador envía tráfico de inferencia a la puerta de enlace sobre HTTPS. La puerta de enlace es un contenedor sin estado en Cloud Run como se muestra a continuación. La puerta de enlace valida su propio portador de sesión: Google Workspace solo se contacta al iniciar sesión y al refrescar el token, verifica la política y reenvía la solicitud a Agent Platform usando la cuenta de servicio de Cloud Run. Cloud SQL mantiene el estado de inicio de sesión del código del dispositivo y el libro mayor de gastos; un colector OTLP recibe las métricas atribuidas. Configurándolo en Google Cloud. El recorrido completo, cada comando gcloud y la referencia completa de gateway.yaml, se encuentran en la puerta de enlace de aplicaciones Claude en la documentación de Google Cloud. La versión corta: Paso 1: Provisiona la base de GCP. Habilita las APIs de Agent Platform, Cloud SQL y Secret Manager; crea una cuenta de servicio claude-gateway con roles/aiplatform.user; establece una pequeña instancia de base de datos Postgres de Cloud SQL para estado. La puerta de enlace se autentica en Agent Platform como la identidad del servicio de Cloud Run; no creas una clave de cuenta de servicio. Finalmente, crea un nuevo cliente OAuth (tipo aplicación web) en la consola de Google Cloud: en este ejemplo, la puerta de enlace autentica a los desarrolladores contra Google Workspace como una parte confiable de OIDC, y este cliente es el que le emite un client_id y client_secret para ese apretón de manos. Esos dos valores alimentan el bloque oidc: en el siguiente paso. Agregarás más tarde el URI de redirección autorizado una vez que se conozca la URL de la puerta de enlace. Paso 2: Configura la puerta de enlace. Escribe gateway.yaml apuntando a tu cliente OIDC de Google Workspace, la cadena de conexión de Postgres y Agent Platform como el upstream. Almacénalo en Secret Manager, junto con el secreto del cliente OIDC, la URL de Postgres, y una clave de firma JWT. Luego, registra https://<public_url host>/oauth/callback como un URI de redirección autorizado en el cliente OAuth de Google; debe coincidir exactamente con listen.public_url:

Paso 3: Despliega en Cloud Run. gcloud run deploy con la cuenta de servicio adjunta, la conexión a Cloud SQL en la VPC y la configuración montada desde Secret Manager. El contenedor es sin estado y escala horizontalmente detrás del balanceador de carga de Cloud Run. GKE funciona igualmente bien si esa ya es tu plataforma, y solo cambia el manifiesto de despliegue. Los desarrolladores se conectan a través de la red corporativa; puedes adelantar el servicio con un balanceador de carga de aplicaciones interno: consulta la red privada de Cloud Run. Ya sea público o interno, tus desarrolladores deben poder acceder a cualquier URL que configures o puedes confiar en la URL predeterminada de Cloud Run. Para el ejemplo a continuación, utilizaremos https://claude-gateway.example.internal.

Paso 4: Incorpora a un desarrollador. Empuja forceLoginMethod: "gateway" y forceLoginGatewayUrl a las máquinas de los desarrolladores a través de configuraciones gestionadas. Así es como /login sabe dónde conectarse, sin entrada manual de URL. Para un despliegue organizacional, ese es tu canal MDM. Para una primera prueba sin MDM, el desarrollador puede escribir el archivo a mano en /Library/Application Support/ClaudeCode/managed-settings.json en macOS (o /etc/claude-code/managed-settings.json en Linux) si tiene permisos de administrador local:

Al iniciar Claude Code, el desarrollador presiona Enter en la pantalla de inicio de sesión de la puerta de enlace prellenada para confirmar la URL. Confirma el código del dispositivo en la página de verificación de la puerta de enlace en el navegador, y serás redirigido a Google Workspace para iniciar sesión. Después de eso, el desarrollador completa el flujo del código del dispositivo en el navegador contra Google Workspace. Si la configuración se completa correctamente, podrás ver Cloud Gateway en la vista del terminal como se muestra a continuación.

Qué sigue. En este punto, deberías tener una mejor comprensión de cómo configurar y usar la puerta de enlace de aplicaciones Claude en Google Cloud. Aquí hay algunos próximos pasos que podrías considerar: referencia completa de configuración: cada campo de gateway.yaml está en claude-apps-gateway-config. Configuración por IdP y el seguimiento de GKE viven en claude-apps-gateway-deploy y claude-apps-gateway-on-gcp. Políticas de alcance grupal: adelanta la puerta de enlace con un IdP capaz de grupos, establece groups_claim y agrega match: { groups: [...] } políticas por encima del catch-all para dar a diferentes equipos diferentes listas de modelos y permisos de herramientas. Por ahora, gracias por leer. Y si tienes preguntas o comentarios adicionales, no dudes en contactarnos en redes sociales (Roy Arsan - Linkedin, X e Ivan Nardini - LinkedIn, X). ¡Feliz construcción!