Langsung ke konten utama
Halaman ini menjelaskan satu cara untuk menjalankan gateway aplikasi Claude di Google Cloud. Konfigurasi ini adalah contoh kerja untuk infrastruktur yang dikelola pelanggan daripada penyebaran produksi yang didukung; gunakan ini untuk melihat bagaimana potongan-potongan cocok bersama sebelum menyesuaikannya dengan lingkungan Anda sendiri. Untuk persyaratan yang tidak bergantung pada platform, lihat panduan penyebaran.
Contoh ini menyediakan gateway aplikasi Claude di Google Cloud dengan Agent Platform Google Cloud sebagai upstream model, menggunakan Cloud Run atau GKE untuk komputasi. Google Workspace adalah penyedia identitas contoh (IdP), tetapi penyedia IdP yang sesuai dengan OpenID Connect (OIDC) apa pun berfungsi; hanya blok oidc yang berubah. Lihat Penyiapan penyedia identitas untuk detail per-IdP.

Apa yang akan Anda bangun

Diagram gateway aplikasi Claude di Google Cloud: klien Claude Code terhubung melalui HTTPS ke gateway (Cloud Run atau GKE), yang berjalan di dalam VPC bersama database Cloud SQL IP pribadi untuk status sesi. Gateway menandatangani pengguna melalui OIDC terhadap Google Workspace, membaca konfigurasi dan rahasia dari Secret Manager, meneruskan permintaan model ke Agent Platform, dan menarik gambarnya dari Artifact Registry saat penyebaran.
Deployment ini terdiri dari:
  • Layanan Cloud Run atau GKE Deployment yang menjalankan kontainer gateway
  • Repositori Artifact Registry untuk gambar gateway
  • Instans Cloud SQL untuk PostgreSQL, IP pribadi saja, untuk store gateway
  • Rahasia Secret Manager untuk gateway.yaml, kunci penandatanganan JWT, rahasia klien OIDC, dan URL Postgres
  • Service account dengan roles/aiplatform.user, terlampir langsung di Cloud Run atau terikat melalui Workload Identity di GKE
  • Front end HTTPS yang Anda sediakan: internal Application Load Balancer di depan Cloud Run, yang menjadi acuan konfigurasi gateway dalam panduan ini tetapi tidak dibuat oleh panduan ini, atau GKE Ingress internal dari kelas gce-internal di GKE

Prasyarat

  • Proyek GCP dengan penagihan diaktifkan, dan izin untuk membuat sumber daya di atas
  • CLI gcloud, diautentikasi dengan gcloud auth login, dan Docker dipasang secara lokal
  • Untuk jalur GKE: kubectl, dan kluster GKE di VPC yang dibuat dalam panduan di bawah
  • Akses ke model Claude yang Anda butuhkan di Model Garden, di wilayah yang menerbitkannya
  • Klien aplikasi web OAuth 2.0 Google Workspace dengan URI pengalihan https://<gateway-host>/oauth/callback; lihat Penyiapan penyedia identitas
  • Nama host TLS untuk gateway, biasanya nama DNS internal yang menunjuk ke load balancer
Atur proyek dan wilayah sekali:

Men-deploy gateway

Langkah-langkah di bawah ini menyediakan deployment lengkap dengan perintah gcloud.
1

Aktifkan API

Aktifkan API layanan yang digunakan dalam panduan ini:
API yang Anda perlukan bergantung pada jalur deployment:
  • compute dan servicenetworking: diperlukan untuk jalur Cloud SQL dengan IP privat
  • run: hanya Cloud Run
  • container: hanya GKE
2

Buat service account dan berikan IAM

Gateway berjalan sebagai service account khusus dengan izin untuk memanggil Agent Platform milik Google Cloud. Gateway menjangkau Cloud SQL melalui VPC dengan pengguna berbasis kata sandi, sehingga tidak diperlukan peran IAM Cloud SQL:
Kemudian aktifkan model Claude untuk proyek di Model Garden; model dipublikasikan ke region tertentu, jadi periksa setiap kartu model.
3

Build dan push image ke Artifact Registry

Build image sesuai persyaratan image container, menggunakan binary glibc linux-x64, lalu push image tersebut:
4

Sediakan Cloud SQL untuk PostgreSQL

Buat instance pada VPC melalui Private Services Access sehingga instance tidak memiliki IP publik; ini juga memenuhi persyaratan proyek yang memberlakukan constraints/sql.restrictPublicIp:
Runtime Cloud Run atau GKE harus berada di VPC ini, atau dirutekan ke dalamnya.
5

Tulis gateway.yaml

Blok upstreams mengarah ke Agent Platform milik Google Cloud dengan auth: {}, sehingga gateway melakukan autentikasi melalui Application Default Credentials dari service account runtime. Lihat referensi konfigurasi untuk setiap field.Dua field listen menjelaskan apa yang berada di depan gateway:
  • public_url: origin https:// eksternal, wajib untuk setiap bind non-loopback; lihat referensi listen. Gateway membangun redirect_uri IdP dan dokumen discovery-nya hanya dari nilai ini, tidak pernah dari header X-Forwarded-*.
  • trusted_proxies: rentang sumber front end. Gateway hanya menghormati X-Forwarded-For ketika peer TCP ada dalam daftar ini, lalu menelusuri rantai melewati hop tepercaya, sehingga rate limit masuk per IP dan peristiwa audit mencatat IP developer alih-alih IP load balancer.
Atur trusted_proxies agar sesuai dengan front end Anda. GKE Ingress eksternal dengan class gce tidak tercantum: Ingress tersebut menyediakan alamat forwarding-rule publik, yang ditolak oleh pemeriksaan jaringan privat /login.Contoh di bawah ini menggunakan nilai untuk load balancer internal di depan Cloud Run.
gateway.yaml
id_token Google tidak membawa klaim groups. Untuk menggunakan kebijakan berbasis grup di managed.policies dengan Google Workspace sebagai IdP, konfigurasikan oidc.google_groups, yang mencari grup setiap pengguna melalui Admin SDK Directory API menggunakan service account dengan domain-wide delegation. Tanpa itu, lakukan pencocokan berdasarkan email_domain sebagai gantinya.
6

Simpan secret di Secret Manager

Buat empat secret dan berikan roles/secretmanager.secretAccessor kepada service account claude-gateway:Cara secret mencapai container berbeda menurut jalurnya:
  • Di GKE, secret di-mount sebagai file melalui Secret Manager CSI driver, dan gateway.yaml mereferensikan ${file:/secrets/...}.
  • Di Cloud Run, yang tidak dapat me-mount beberapa secret ke dalam satu direktori, gateway.yaml di-mount sebagai file dan tiga secret lainnya diinjeksikan sebagai environment variable, sehingga gateway.yaml mereferensikan ${GATEWAY_JWT_SECRET}, ${OIDC_CLIENT_SECRET}, dan ${GATEWAY_POSTGRES_URL} sebagai gantinya.
7

Deploy

Perintah di bawah ini men-deploy untuk produksi di belakang load balancer internal.
Direct VPC egress, melalui --network, --subnet, dan --vpc-egress=private-ranges-only, memungkinkan layanan menjangkau IP privat Cloud SQL secara langsung. Egress publik ke endpoint Agent Platform milik Google Cloud dan accounts.google.com langsung menuju internet alih-alih melalui VPC, sehingga Cloud NAT tidak diperlukan.
Setiap instance menampung hingga store.max_connections koneksi Postgres, lima secara default. Gunakan Menentukan ukuran connection pool untuk memeriksa --max-instances=8 terhadap koneksi yang tersisa di database Anda untuk gateway, dan sertakan instance tambahan yang dimulai oleh rolling update.
Pemeriksaan invoker IAM harus terbuka atau dinonaktifkan. Gateway menjalankan OIDC-nya sendiri dan klien-kliennya tidak membawa token GCP, sehingga pemeriksaan invoker Cloud Run harus menerima permintaan yang tidak terautentikasi. Proses masuk OIDC gateway mengautentikasi permintaan setelah permintaan tersebut mencapai container, dengan allowed_email_domains yang membatasi domain mana yang boleh masuk.Dua flag menerima permintaan yang tidak terautentikasi:
  • --no-invoker-iam-check: menonaktifkan pemeriksaan tanpa binding allUsers yang perlu dikelola, dan berfungsi di bawah Domain Restricted Sharing
  • --allow-unauthenticated: memberikan peran run.invoker kepada allUsers; gunakan ini jika organisasi Anda tidak mengizinkan --no-invoker-iam-check
Pembatasan ingress melalui --ingress adalah lapisan terpisah dan independen dari pemeriksaan invoker; tetap atur untuk membatasi layanan ke jaringan perusahaan Anda.Secara default, URL Cloud Run *.run.app di-resolve ke alamat publik, yang ditolak oleh pemeriksaan jaringan privat /login. Dua topologi memberikan developer hostname yang dapat di-resolve secara privat, dan Cloud Run tidak menyediakan keduanya untuk Anda:
  • Internal Application Load Balancer, topologi yang diasumsikan oleh gateway.yaml di halaman ini: sediakan internal Application Load Balancer di depan layanan dengan nama DNS internal dan sertifikat, lalu atur listen.public_url ke hostname tersebut. Pengaturan ingress internal sudah menerima traffic dari internal Application Load Balancer; internal-and-cloud-load-balancing juga menerima external Application Load Balancer, yang alamat publiknya ditolak oleh pemeriksaan jaringan privat /login, sehingga tidak ada topologi di halaman ini yang memerlukannya.
  • Ingress khusus internal tanpa load balancer: biarkan perintah deploy apa adanya dan biarkan listen.public_url sebagai URL *.run.app, yang merupakan default di aset referensi di bawah. Agar *.run.app dapat di-resolve secara privat, tim jaringan Anda harus sudah mengoperasikan endpoint Private Service Connect untuk Google API, zona privat Cloud DNS yang me-resolve *.run.app ke endpoint tersebut, dan perutean on-premises ke endpoint tersebut.
Panduan jaringan privat untuk Cloud Run dari Google mencakup infrastruktur yang diperlukan oleh kedua opsi. Verifikasi proses masuk setelah gateway melayani pada hostname privat; hingga saat itu, konfirmasikan bahwa container telah berjalan dari log-nya di Cloud Run.Perbarui authorized redirect URI pada OAuth client menjadi <public_url>/oauth/callback sebelum proses masuk pertama. Deploy ulang setelah mengubah public_url, karena gateway membangun origin publiknya hanya dari pengaturan tersebut dan mengabaikan X-Forwarded-Host serta X-Forwarded-Proto. X-Forwarded-For dihormati untuk IP klien hanya ketika listen.trusted_proxies diatur.
8

Kirim URL gateway ke mesin developer

Gateway kini sudah berjalan, tetapi developer tidak dapat menjangkaunya dari /login hingga URL gateway ada di mesin mereka. Deploy cuplikan pengaturan terkelola lengkap, dengan forceLoginMethod, forceLoginGatewayUrl, dan opt-in parentSettingsBehavior: "merge", ke setiap perangkat melalui MDM. Tidak ada opsi gateway di pemilih login yang dapat dipilih developer secara manual.

Referensi Terraform

Aset penyebaran referensi mengotomatisasi jalur Cloud Run di halaman ini; aset konfigurasi dan gambar berlaku untuk kedua jalur:
  • setup.sh: penyedia gcloud idempoten yang berjalan melalui jalur Cloud Run lengkap, dari mengaktifkan API melalui penyebaran pertama
  • terraform/: penyebaran yang sama sebagai infrastruktur-sebagai-kode, untuk penyebaran greenfield: penerapan bertarget untuk membuat repositori Artifact Registry, kemudian membangun dan mendorong gambar, kemudian penerapan penuh
  • gateway.yaml.example dan Dockerfile untuk gambar runtime distroless
Artefak menetapkan default ingress Cloud Run ke internal, sesuai dengan perintah deploy di halaman ini; pengaturan tersebut berfungsi dengan atau tanpa internal Application Load Balancer di depan layanan, dan artefak juga tidak membuat load balancer tersebut. Artefak juga default lapisan invoker ke pemberian run.invoker allUsers daripada --no-invoker-iam-check, kebalikan dari panduan halaman ini; keduanya berfungsi, dan pilihan bergantung pada batasan kebijakan organisasi Anda. Aset disediakan sebagai contoh kerja, bukan sebagai artefak produksi yang didukung; tinjau dan sesuaikan dengan lingkungan Anda.

Troubleshooting

Untuk boot gateway dan kesalahan login, lihat tabel troubleshooting yang tidak bergantung pada platform. Entri di bawah khusus untuk Google Cloud.

Langkah berikutnya