Kezdje el a Claude alkalmazások átjárójának használatát a Google Cloudban.

Az Anthropic agenti kódolási eszköze, a Claude Code már egy ideje együttműködik a Google Cloud-dal. Egy egyéni fejlesztő könnyedén beállíthatja a CLAUDE_CODE_USE_VERTEX=1 értéket egy Google Cloud (GCP) projekthez, megadhatja a roles/aiplatform.user szerepkört, és az infereció a Google Cloud keretein belül marad. Ez a folyamat remekül működik, ha csak te vagy, vagy néhány mérnök. De ha egy egész szervezeten belül szeretnéd bevezetni, akkor vállalati nehézségekkel kell szembenézned: kezelni kell a fejlesztői felhőhitelesítő adatokat, minden laptopra el kell juttatni egy managed-settings.json fájlt MDM-en keresztül, és nem lehet biztosítani a zéró fejlesztői felhasználási attribúciót vagy könnyen érvényesíthető költségkorlátokat. A Claude alkalmazások átjárója áthidalja ezt a rést. Ez egy saját hosztolt szolgáltatás, amely ugyanazzal a claude binárissal érkezik, és közvetlenül a helyi Claude Code klienseid és a Google Cloud között helyezkedik el. Ez a bejegyzés pontosan kifejti, miért érdemes futtatni, és hogyan néz ki egy biztonságos telepítés a Google Cloud-on. (Megjegyzés: Ha közvetlenül a kódra szeretnél ugrani, a teljes útmutató a Claude alkalmazások átjárójában található a Google Cloud dokumentációjában.) Miért kell futtatni az átjárót? Futtasd az átjárót, hogy centralizáld a kormányzást, amelyet a fejlesztők és a platform adminisztrátorok egyedül hordoznak, mint például az azonosság, a politika, a költségek és az irányítás. Íme, hogyan néz ki ez a gyakorlatban. Azonosság. A /login kérelem átirányítódik az azonosságkezelő szolgáltatásodra (IdP) - Google Workspace vagy bármely OIDC/OpenID Connect - és az átjáró a tokent egy rövid élettartamú munkamenetre cseréli. Nincs érzékeny információ a fejlesztő laptopján - mint például a szolgáltatásfiók kulcsai, API kulcsok vagy ANTHROPIC_VERTEX_PROJECT_ID. Az onboarding olyan egyszerű, mint egy felhasználó hozzáadása az IdP csoporthoz; a kiutalás a megszüntetésével történik, és a következő munkamenet frissítése azonnal meghiúsul. Politika. A RBAC (szerekalapú hozzáférés-vezérlés) szabályaid egyszer élnek a gateway.yaml fájlban, csoportonként feloldva és a szerver oldalon érvényesítve. Az átjáró minden egyes /v1/messages híváskor újra ellenőrzi az availableModels-t, így a helyi managed-settings.json módosítása semmit sem változtat - a szabályfrissítések pedig egy órán belül elérik az egész flotta. Telemetria. Minden claude_code.token.usage metrikához a hitelesített email és csoportok a munkamenet JWT-ből (aláírt munkamenet token) származnak, nem a hamisítható ügyfélbeállítású OTEL_RESOURCE_ATTRIBUTES-ből. Az átjáró az OTLP/HTTP-n át elküldi őket egy gyűjtőhöz, amelyet te futtatsz - Cloud Monitoring, Grafana, Datadog, bármi, amit használsz. Költségkeretek. Állíts be napi, heti vagy havi korlátokat felhasználónként, csoportonként vagy szervezetként a rendszergazda API-n keresztül; az átjáró a tokeneket egy Cloud SQL főkönyv alapján méri, és 429-es hibakódot ad vissza a korlát elérésekor. A költségek listaárban vannak, így ezeket runaway-usage védőkorlátnak kell tekinteni, nem számlarekonsziliációnak (a kötött használati kedvezmények és a tárgyalt árak nem jelennek meg). Irányítás. A hívások egyetlen Cloud Run szolgáltatásazonosság alatt mennek ki. Állítsd be a régiót: globális az Agent Platform globális végpontjához, vagy adj hozzá egy második upstreams: bejegyzést, hogy átválts 5xx/429/timeout esetén listás sorrendben. Akárhogy is, az infereció a te GCP projektedben marad - a kvóta, az Adatfeldolgozási megállapodás és a számlázás mind változatlan. Hogy illeszkedik össze Egy fejlesztő helyi vagy telepített claude folyamata HTTPS-en keresztül küld infereciós forgalmat az átjárón keresztül. Az átjáró egy állapotlan konténer a Cloud Run-on, ahogyan az alább látható. Az átjáró érvényesíti a saját munkameneti tokent - a Google Workspace csak bejelentkezéskor és tokenfrissítéskor kerül kapcsolatba - ellenőrzi a politikát, és továbbítja a kérelmet az Agent Platformhoz a Cloud Run szolgáltatásfiókján keresztül. A Cloud SQL tárolja a készülék-kódú bejelentkezési állapotot és a költségnyilvántartást; egy OTLP gyűjtő kapja meg az attribútumozott metrikákat. Telepítés a Google Cloud-on A teljes útmutató, minden gcloud parancs és a teljes gateway.yaml hivatkozás a Claude alkalmazások átjárójában található a Google Cloud dokumentációjában. A rövid verzió: 1. lépés: Létrehozni a GCP alapot Engedélyezd az Agent Platform, Cloud SQL és Secret Manager API-kat; hozz létre egy claude-gateway szolgáltatásfiókot a roles/aiplatform.user szerepkörrel; állíts fel egy kis Cloud SQL Postgres adatbázis példányt az állapothoz. Az átjáró úgy hitelesít az Agent Platformhoz, mint a Cloud Run szolgáltatásazonosság - nem hozol létre szolgáltatásfiók kulcsot. Végül hozz létre egy új OAuth klienst (Webalkalmazás típus) a Google Cloud konzolban: ebben a példában az átjáró a fejlesztőket a Google Workspace ellen hitelesíti OIDC megbízottként, és ez a kliens az, amelyik ügyfél_id-t és ügyfél_secret-et bocsát ki a kézfogáshoz. Ezek az értékek táplálják az oidc: blokkot a következő lépésben. Később hozzá fogod adni az engedélyezett átirányító URI-t, amint az átjáró URL-je ismerttá válik. 2. lépés: Az átjáró konfigurálása Írd meg a gateway.yaml fájlt, amely a Google Workspace OIDC kliensekre, a Postgres kapcsolati karakterláncra és az Agent Platformra mutat, mint upstream. Tárold a Secret Manager-ben, együtt az OIDC kliens titkával, a Postgres URL-jével és a JWT aláíró kulccsal. A kódblokk <ListValue: [StructValue([('code', 'listen:\r\n port: 8080\r\n public_url: https://<your-cloud-run-service-url> # a Cloud Run szolgáltatás URL-je — --ingress=internal mellett ez csak a VPC-den / vállalati hálózatodon belül oldódik\r\noidc:\r\n issuer: https://accounts.google.com # Google Workspace\r\n client_id: <client-id>.apps.googleusercontent.com\r\n client_secret: ${OIDC_CLIENT_SECRET} # a Secret Manager-ből\r\n allowed_email_domains: [yourco.com]\r\n\r\nupstreams:\r\n - provider: vertex\r\n region: us-east5\r\n project_id: <your-project>\r\n auth: {} # ADC a Cloud Run SA-n keresztül, NEM kulcsfájl'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f499861f820>)])]> Majd regisztráld a https://<public_url host>/oauth/callback-ot engedélyezett átirányító URI-ként a Google OAuth kliensnél — ez pontosan meg kell, hogy egyezzen a listen.public_url-lal: 3. lépés: Telepítsd a Cloud Run-ra gcloud run deploy a szolgáltatásfiók csatolásával, a Cloud SQL kapcsolat a VPC-en, és a konfiguráció felszerelésével a Secret Manager-ből. A konténer állapotlan és vízszintesen skálázódik a Cloud Run terheléselosztója mögött. A GKE is jól működik, ha ez már a platformod, és csak a telepítési manifest változik. A kódblokk <ListValue: [StructValue([('code', 'gcloud run deploy claude-gateway \\\r\n --service-account="claude-gateway@${PROJECT_ID}.iam.gserviceaccount.com" \\\r\n --set-secrets=/etc/claude/gateway.yaml=gateway-config:latest \\\r\n --ingress=internal \\ # privát — a fejlesztők a vállalati hálózaton érik el az átjárót (VPN/Interconnect a VPC-be)\r\n --no-invoker-iam-check # az átjáró a SA saját OIDC-jét futtatja; az ügyfelek nem hoznak magukkal GCP tokent'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f499861f100>)])]> A fejlesztők a vállalati hálózaton keresztül csatlakoznak; egy belső Alkalmazás Terheléselosztóval is elérheted a szolgáltatást - lásd a Cloud Run privát rendszerezését. Akár publikus, akár belső, a fejlesztőidnek hozzáférést kell kapniuk ahhoz az URL-hez, amelyet konfigurálsz, vagy támaszkodhatsz a Cloud Run alapértelmezett URL-jére. Az alábbi példában a https://claude-gateway.example.internal URL-t használjuk. 4. lépés: Fejlesztő onboarding Kényszerítsd a forceLoginMethod: "gateway" és a forceLoginGatewayUrl beállításokat a fejlesztői gépekre kezelhető beállításokon keresztül. Így tudja a /login, hol csatlakozzon, manuális URL-beírás nélkül. Szervezeti telepítéshez ez az MDM csatornád. Az első próba kedvéért MDM nélkül a fejlesztő kézzel is létrehozhatja a fájlt /Library/Application Support/ClaudeCode/managed-settings.json macOS-en (vagy /etc/claude-code/managed-settings.json Linuxon), ha van helyi admin joguk: a kódblokk <ListValue: [StructValue([('code', '{\r\n "forceLoginMethod": "gateway",\r\n "forceLoginGatewayUrl": "https://claude-gateway.example.internal"\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f499861f580>)])]> A Claude Code indításakor a fejlesztő ezután megnyomja az Enter-t az előre kitöltött átjáró bejelentkezési képernyőn, hogy megerősítse az URL-t. Erősítsd meg a készülék kódját az átjáró ellenőrzőoldalán a böngészőben, és irányítsd át a Google Workspace-be a bejelentkezéshez. Ezt követően a fejlesztő a böngészőben befejezi a készülék kód folytatását a Google Workspace ellen. Ha a beállítás helyesen zárul, a Cloud Gateway-nek meg kell jelennie a terminál nézetben, ahogyan az alább látható. Mi következik? Ekkor már jobban kell értened, hogyan kell konfigurálni és használni a Claude alkalmazások átjáróját a Google Cloud-on. Íme néhány következő lépés, amelyet érdemes megfontolnod: Teljes konfigurálási hivatkozás: minden gateway.yaml mező a claude-apps-gateway-configban található. Per-IdP beállítás és a GKE nyomvonal a claude-apps-gateway-deploy és claude-apps-gateway-on-gcp dokumentációkban található. Csoport-irányított politikák: állítsd az átjárót egy csoportok képességeivel rendelkező IdP elé, állítsd be a groups_claim-t, és adj hozzá match: { groups: [...] } politikákat a catch-all fölé, hogy különböző csapatoknak különböző modell listákat és eszközengedélyeket adj. Most pedig köszönöm, hogy elolvastad! Ha további kérdéseid vagy észrevételeid vannak, nyugodtan lépj kapcsolatba a közösségi médiában (Roy Arsan - Linkedin, X és Ivan Nardini - LinkedIn, X). Boldog építkezést!