📘 תיעוד 110

שער אפליקציות Claude עבור Amazon Bedrock, Claude Platform on AWS, Google Cloud ו-Microsoft Foundry

הרץ את Claude Code דרך Amazon Bedrock, Claude Platform on AWS, Google Cloud או Microsoft Foundry מאחורי שער באחסון עצמי עם כניסה ב-SSO, גישה למודלים לפי קבוצה וטלמטריה ב-OTLP.

[!NOTE]

שער אפליקציות Claude מיועד לארגונים שחייבים, או מעדיפים, לנתב הסקה דרך ספק הענן שלהם, למשל כדי לעמוד בדרישות תושבות נתונים. אם אין לך דרישה זו, ואתה רוצה גישה ליכולות אחרות כמו הקצאה ב-SCIM או Claude Code באינטרנט ובמובייל, Claude Enterprise עשוי להתאים יותר. ראה את עמוד זמינות היכולות להשוואה מלאה של כל שיטות הפריסה.

Claude Code משתמש בכניסה אחת בכל פעם: כניסה לשער תופסת את מקומה של כניסה ל-Claude for Teams או ל-Enterprise. הפעלות שער לא שולפות את ההגדרות שמנוהלות בשרת שהגדרת בקונסולת הניהול של claude.ai, ולכן מסור אותן מבלוק managed של השער. השאר את forceLoginMethod ואת forceLoginOrgUUID מחוץ לבלוק הזה, או חלק מההפעלות המחוברות יוצאות בהפעלה. ראה זמינות ומגבלות לגבי מה שהפעלות שער מאבדות.

שער אפליקציות Claude הוא שירות באחסון עצמי שיושב בין לקוחות Claude Code של המפתחים שלך לבין ספק המודל שלך. מפתחים נכנסים עם ספק הזהויות הארגוני (IdP) שלך במקום להחזיק מפתחות API או אישורי ענן. השער מחזיק את אישור ה-upstream, אוכף גישה למודלים והגדרות מנוהלות לפי קבוצת IdP, ומעביר טלמטריית שימוש למחסנית התצפיתיות שלך.

הוא כלול בקובץ ההרצה claude, כך שאותו קובץ הרצה שמריץ את Claude Code על מחשב נייד מריץ את שרת השער עם claude gateway --config gateway.yaml.

עמוד זה מכסה:

• למה שער אפליקציות Claude, מה הוא מוסיף על הרצה משלך, ומתי משהו אחר מתאים יותר
• התחלה מהירה עם דרישות מוקדמות שלוקחת שער מאפס עד מפתח מחובר
• חיבור מפתחים, כולל הגדרת כתובת השער דרך הגדרות מנוהלות
• זמינות ומגבלות שמכסות אילו יכולות של Claude Code עובדות דרך השער ומה השרת תומך

עמודי לוואי מעמיקים יותר. מדריך התצורה מכסה כל אפשרות בקובץ ה-YAML שההתחלה המהירה כותבת, ומדריך הפריסה מכסה הגדרה לפי IdP, פריסה ב-Kubernetes וב-Cloud Run, ותפעול.

#למה שער אפליקציות Claude

סקירת השער מכסה מה שער עושה ולמה כדאי להריץ אחד. שער אפליקציות Claude הוא השער של Anthropic עצמה, בנוי בתוך קובץ ההרצה claude ונבדק לצד כל גרסה של Claude Code, כך שהוא מעביר את ערכי anthropic-beta ואת שדות הבקשה ש-Claude Code שולח בלי שמפעילים יתחזקו רשימת היתר נפרדת. אחרי הפריסה הוא נותן לך:

• אישורים: מפתח ה-API של ה-upstream או אישור הענן חיים רק בתשתית שלך. מפתחים מאמתים עם SSO ארגוני ומקבלים אסימוני bearer קצרי חיים, כך שהסרת משתמש מתבצעת ב-IdP שלך. בטל הקצאה של משתמש והגישה שלו לשער תפוג בתוך משך חיי ההפעלה, שעה אחת כברירת מחדל.
• בקרת גישה: קבוצות ה-IdP שלך ממופות לרשימות היתר של מודלים, למדיניות הגדרות מנוהלות, ול-upstreams. השער אוכף גישה למודלים בצד השרת, דוחה בקשות למודלים שלא הוענקו, ובוחר את מדיניות ההגדרות המנוהלות של כל קבוצה, שה-CLI מחיל בשכבת ההגדרות המנוהלות. צוותים שונים מקבלים מודלים, כלים והרשאות שונים, ומפתח לא יכול לעקוף את מה שהמדיניות שלו נועלת.
• מסירת הגדרות: השער מוסר הגדרות מנוהלות ללקוחות מחוברים בעצמו, ותופס את מקומן של הגדרות שמנוהלות בשרת מקונסולת הניהול של claude.ai.
• טלמטריה: כל יעד מוגדר מקבל מדדי OpenTelemetry Protocol (OTLP) עם ספירת אסימונים, מודל, זהות משתמש וזמן השהיה כברירת מחדל, עם יומנים ועקבות כהצטרפות לפי יעד.
• ניתוב upstream: לקוחות מדברים ב-Anthropic Messages API אל השער, והשער מתרגם לכל upstream, בין אם Amazon Bedrock, Claude Platform on AWS, Agent Platform של Google Cloud, Microsoft Foundry או Anthropic API, עם failover ביניהם. אפשר לשנות אזורים, ספקים או סדר failover בלי שהמפתחים יבחינו או יגדירו מחדש.

[!NOTE]

מישור הנתונים של השער עצמו לא שולח דבר לתשתית של Anthropic אלא אם Anthropic API הוא upstream מוגדר. אתה שולט לאן הולכים טלמטריה, יומני ביקורת, הגדרות מנוהלות וזהות ה-IdP של המפתחים שלך, והשער לא שולח אף אחד מהם אל Anthropic. לתעבורה הנותרת שתהליך ה-CLI יכול לשלוח ולאיך לסגור אותה, ראה עמדת ציות.

לגבי אילו יכולות של Claude Code עובדות דרך השער ומה השרת עצמו תומך, ראה זמינות ומגבלות למטה. להחלטות כמו עלות, עקיפה, הרצת כמה שערים ופלטפורמות serverless, ראה את מדריך הפריסה.

#מימושי שער אחרים

אם אתה כבר מריץ שער LLM או שער API שעונה על הצרכים שלך, המשך להשתמש בו. שערי LLM אחרים מכסה הגדרת Claude Code מולו.

מדריך תאימות השער מתעד מה Claude Code מצפה מכל שער: נקודות הקצה שהוא קורא להן, הכותרות ושדות הגוף להעברה, ומה מפסיק לעבוד כשמסירים אותם. שער אפליקציות Claude שרץ מגיש גם את מדריך הפרוטוקול שלו ב-GET /protocol, שמתאר את נקודות הקצה שהוא חושף ללקוחות Claude Code: כניסה ב-SSO, הסקה, מסירת הגדרות מנוהלות, גילוי מודלים וטלמטריה. שלוף אותו עם curl https://claude-gateway.internal.example.com/protocol מכל שער שנפרס, כמו זה שההתחלה המהירה למטה מייצרת.

שינויים שוברים בפרוטוקול מוכרזים מראש, אבל תאימות לאחור ללא הגבלת זמן אינה מובטחת.

[!NOTE]

אסימון כניסה לשער מזהה את המפתח שאישר את הכניסה, לא את התוכנית שמשתמשת בו. Claude Code נכנס בלי מזהה לקוח או סוד משלו, כך שלשער אין דרך לאמת איזו תוכנית נכנסת. כל לקוח יכול להגדיר User-Agent ושדות בקשה אחרים, לכן השתמש בהם לניתוב או למדדים, לא כהוכחה שבקשה מגיעה מ-Claude Code.

#התחלה מהירה

ההתחלה המהירה הזו עוברת את המסלול המינימלי: רישום לקוח OAuth ב-IdP, כתיבת gateway.yaml, הרצת ה-gateway לצד Postgres עם Docker Compose, ואימות כניסה מקצה לקצה. היא משתמשת ב-upstream של Amazon Bedrock. Claude Platform on AWS, Agent Platform של Google Cloud, Microsoft Foundry, ו-Anthropic API נתמכים באותה מידה על ידי החלפת בלוק upstreams כפי שמוצג ב-מדריך ההגדרות. בסוף יש gateway שמפתח יכול לבצע אליו /login.

[!NOTE]

פרוס ברשת הפרטית שלך. Claude Code מתחבר רק ל-gateway שהכתובת שלו פרטית. זהו מנגנון אבטחה, כי gateway מהימן יכול לדחוף הגדרות שמריצות פקודות על מכונות מפתחים. שים את ה-gateway מאחורי מאזן עומסים פנימי או VPN, ותן לו שם מארח שמתורגם רק לכתובות IP פרטיות. אם הרשת הפנימית שלך ממוספרת ממרחב IPv4 ציבורי שהארגון שלך מחזיק, ראה אפשר gateway במרחב כתובות ציבורי שבבעלותך.

#דרישות מוקדמות

ודא שהפריטים האלה קיימים לפני שמתחילים:

#שלבים

1. רישום לקוח OAuth ב-IdP

החלט קודם על שם המארח של ה-gateway, כי ה-redirect URI חייב להתאים לו. צור יישום אינטרנט OIDC חדש והגדר את ה-redirect URI ל-https://claude-gateway.<your-domain>/oauth/callback, כאשר המארח הוא אותו ערך שתגדיר כ-listen.public_url בשלב 3. רשום את client_id ואת client_secret. הוראות לפי IdP נמצאות ב-הגדרת ספק זהויות.

2. הקצאת מסד נתונים PostgreSQL

השתמש ב-PostgreSQL 11 או חדש יותר. הרמה המנוהלת הקטנה ביותר מספיקה. ה-gateway מריץ את מיגרציות הסכמה שלו בעת האתחול, ולכן תפקיד מסד הנתונים צריך הרשאות ליצור ולשנות טבלאות. ראה store.

3. כתיבת gateway.yaml

סודות נקראים באמצעות הרחבת ${ENV_VAR} כדי שהקובץ עצמו יוכל לחיות בבקרת גרסאות. השתמש בשם מארח public_url שמתורגם ל-IP פרטי ברשת שלך, כי /login דוחה כתובות ציבוריות. להגדרה המינימלית יש חמישה סעיפים, ולכל שדה אחר יש ברירת מחדל:

listen:
  host: 0.0.0.0
  port: 8080
  # Required unless host is a loopback address. Used for the IdP
  # redirect_uri and the discovery document.
  public_url: https://claude-gateway.internal.example.com

oidc:
  issuer: https://login.example.com        # must serve /.well-known/openid-configuration
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]        # reject id_tokens outside your org
  userinfo_fallback: true                  # for IdPs whose id_token omits email/groups; harmless otherwise

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
  ttl_hours: 1                             # also bounds revocation latency on IdP deprovision

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}    # add ?sslmode=require for managed Postgres

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}                               # empty: AWS default credential chain
                                           # (IRSA, EC2/ECS task role, env vars, ~/.aws)

# Models are translated per upstream automatically. The built-in catalog
# maps claude-opus-4-8 to us.anthropic.claude-opus-4-8 and so on for every
# Bedrock-supported Claude model. Set false and add a `models:` list to
# expose only specific models.
auto_include_builtin_models: true

ההגדרה הזו מספיקה ללולאת כניסה עובדת עם קטלוג המודלים של Amazon Bedrock כברירת מחדל. אחרי שהיא רצה, הוסף RBAC לפי קבוצה והגדרות מנוהלות דרך managed.policies, פיזור טלמטריה דרך telemetry, ו-failover של כמה upstreams, ARN של provisioned throughput, או אזורים שאינם בארה"ב דרך models.

[!NOTE]

ה-upstream של Amazon Bedrock צריך principal של AWS עם bedrock:InvokeModel ו-bedrock:InvokeModelWithResponseStream גם על ARN של inference-profile/us.anthropic.* וגם על ARN הבסיסיים של foundation-model/anthropic.*. הוא גם צריך שטופס ה-use case החד פעמי של Anthropic הוגש עבור החשבון מקטלוג המודלים במסוף Bedrock.

ספק את פרטי הגישה עם IRSA על EKS, תפקיד משימה של ECS, או פרופיל מופע EC2, במקום מפתחות סטטיים. ל-מדריך upstreams יש את פרטי ה-IAM המלאים, את מטריצת פרטי הגישה בין עננים, ואת בלוקי auth של הספקים האחרים.

4. הרצה

בנה תמונת קונטיינר סביב הבינארי claude שעומדת ב-דרישות התמונה, ואז הרץ אותה לצד Postgres. קובץ ה-Compose מתייחס לתמונה כ-registry.example.com/claude-gateway:2.1.198. החלף ב-registry ובתג התמונה שלך:

services:
  gateway:
    image: registry.example.com/claude-gateway:2.1.198
    ports: ["8080:8080"]
    volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
    environment:
      OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
      GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
      GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
      # AWS credentials: in production, omit these and use an instance
      # role. For local Compose testing, pass through your own:
      AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
      AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
    depends_on:
      postgres:
        condition: service_healthy
  postgres:
    image: postgres:16-alpine
    environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U gw"]
      interval: 5s
    volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

ה-gateway הוא בינארי Linux יחיד שקורא את ההגדרה, מתחבר ל-Postgres ומחיל את מיגרציות הסכמה, מריץ גילוי OIDC מול ה-IdP, בונה לקוחות upstream, ומתחיל להאזין.

האתחול הוא fail-closed עבור ההגדרה, חיבור Postgres, גילוי OIDC, ובניית לקוחות ה-upstream. אם אחד מאלה לא נגיש או מוגדר לא נכון, ה-gateway יוצא עם שגיאה במקום לשרת תעבורה במצב פגום.

אתחול מוצלח אינו מאמת את נתיב ההסקה, כי פרטי הגישה של מופע Amazon Bedrock ושל Agent Platform של Google Cloud נפתרים בבקשה הראשונה, לא באתחול.

צפה ב-stderr לרצף האתחול. שורות לוג משתמשות בתבנית [gateway] <timestamp> <level> <message>, אירועי ביקורת הם JSON בשורה אחת עם שדה evt, ובאנר אתחול, שמושמט למטה, מודפס בין שורות המיגרציה לבין שורות ההאזנה. מסד נתונים חדש מדפיס שורת migration N applied אחת לכל מיגרציית סכמה. מסד נתונים שכבר עבר מיגרציה אינו מדפיס אף שורה. אמור לראות, לפי הסדר:

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.395Z info waiting for migration lock (another replica may be migrating; check pg_locks for key 6775156 if this persists)
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
…
[gateway] 2026-06-10T17:03:21.431Z info migration 6 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

ה-gateway גם רושם אזהרה ש-access_control.allow_cidrs ריק. זה צפוי כאן, כי דבר אינו מגביל אילו כתובות לקוח ה-gateway משרת עד שתגדיר רשימת היתר. ל-מדריך access_control יש את הטווחים המומלצים.

אם האתחול יוצא לפני השורה claude gateway listening on, השורה האחרונה ב-stderr מציינת את הבעיה:

• Postgres לא נגיש
• תפקיד Postgres בלי הרשאת DDL
• מסמך גילוי OIDC לא נגיש או לא תקין
• הפרת סכמת הגדרה עם נתיב השדה הפוגע

תקן והפעל מחדש.

אם כבר יש לך ingress שמסיים TLS, דלג על Compose והרץ את הבינארי ישירות עם claude gateway --config gateway.yaml. הגדר את public_url ל-origin של ה-ingress וקשור את listen לכתובת loopback או לכתובת פנימית לאשכול.

5. אימות משטח האימות

שלוש בדיקות מאשרות שה-gateway יכול לאמת משתמש אמיתי לפני שתשתף אותו עם מפתח.

הדוגמאות משתמשות ב-URL הציבורי של ה-gateway. עבור הגדרת Compose מקומית בלי ingress, החלף ב-http://localhost:8080 בשתי הבדיקות הראשונות. הבדיקה השלישית פותחת את verification_uri_complete, שנבנה מ-public_url, ולכן עבור Compose מקומי הגדר public_url: http://localhost:8080 ב-gateway.yaml, והוסף את http://localhost:8080/oauth/callback כ-redirect URI שני על לקוח ה-OAuth משלב 1, כי ה-gateway בונה את redirect_uri של ה-IdP מ-public_url. קישור האימות נפתח אז בדפדפן המקומי שלך.

ב-Windows PowerShell, הרץ curl.exe. ה-curl החשוף הוא כינוי ל-Invoke-WebRequest ודוחה את הדגלים האלה.

ראשית, הבא את מסמך הגילוי, שמאשר שה-gateway פעיל, שההגדרה תקינה, ושכל בדיקות האתחול עברו:

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

{
  "issuer": "https://claude-gateway.internal.example.com",
  "device_authorization_endpoint": "…/oauth/device_authorization",
  "token_endpoint": "…/oauth/token",
  "grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"]
}

התשובה כוללת שדות נוספים, כגון response_types_supported ו-scopes_supported.

שנית, בקש אישור מכשיר, שמאשר שזרימת כניסת המכשיר עובדת וש-Postgres נגיש וניתן לכתיבה:

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
  "device_code": "…",
  "user_code": "WDJB-MJHT",
  "verification_uri": "https://claude-gateway.internal.example.com/device",
  "verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
  "expires_in": 600,
  "interval": 5
}

שלישית, בדוק את רגל הדפדפן על ידי פתיחת verification_uri_complete בדפדפן ואישור הקוד. אתה אמור להיות מופנה לדף הכניסה של ה-IdP, ואחרי הכניסה לחזור ל-gateway עם אישור שנכנסת.

השתמש בבדיקה הכושלת הראשונה כדי לאתר את הבעיה:

• הבדיקה הראשונה נכשלת: האתחול לא הושלם. בדוק את stderr
• הבדיקה השנייה נכשלת: Postgres אינו נגיש מה-gateway או שהתפקיד אינו יכול לכתוב. בדוק את מחרוזת החיבור ואת ההרשאות
• הבדיקה השלישית אינה מגיעה ל-IdP: בדוק שה-redirect URI של ה-IdP תואם בדיוק ל-https://<gateway>/oauth/callback
• הבדיקה השלישית מגיעה ל-IdP אבל חוזרת עם שגיאה: קרא את לוג הביקורת של ה-gateway, שרושם כל דחיית אימות עם הסיבה, כגון email domain not allowed

6. כניסת מפתח

השלב האחרון הזה מתרחש על מכונת מפתח, לא על השרת. הגדר את forceLoginMethod ל-"gateway", את forceLoginGatewayUrl ל-public_url של ה-gateway שלך, ואת parentSettingsBehavior ל-"merge" ב-קובץ ההגדרות המנוהלות של המכונה הזו, ואז הרץ /login, לחץ Enter במסך Cloud gateway, והשלם את הכניסה בדפדפן. הגדרת כתובת ה-gateway למטה מכסה את שלושת המפתחות ואת הפצתם לכל מכונת מפתח.

#חיבור מפתחים

מפתחים מתחברים מהמחשבים הניידים שלהם עם כניסה אחת בדפדפן, באמצעות חשבון העבודה הארגוני שלהם. הם אינם צריכים חשבון claude.ai, מפתח API, או מנוי, כי בקשות למודל עוברות דרך ה-gateway באמצעות פרטי הגישה של ה-upstream של הארגון. החיבור מונע על ידי ההגדרות המנוהלות בצד הלקוח שאתה דוחף דרך MDM, והסעיף הזה מכסה את מה שמנהל המערכת מגדיר.

ה-CLI לוקח טביעת אצבע של אישור העלה TLS של ה-gateway בחיבור הראשון ונועל אותה לפי שם מארח. הוא בודק את הנעילה שוב במהלך הכניסה, ברענוני סשן שקטים, ובהבאות של הגדרות מנוהלות, בעוד בקשות הסקה משתמשות באימות TLS רגיל בלי הנעילה. בקשות שמנותבות דרך פרוקסי HTTPS מדלגות על בדיקת הנעילה, לכן הוסף את מארח ה-gateway ל-NO_PROXY כדי להשאיר אותן ישירות.

פרסם את טביעת האצבע SHA-256 הצפויה לצד כתובת ה-gateway כדי שלמפתחים יהיה משהו להשוות אליו. ההנחיה של /login מציגה את 16 התווים הראשונים של טביעת האצבע כהקסדצימלי באותיות קטנות בלי נקודתיים. כדי להדפיס את טביעת האצבע המלאה בצורה הזו מקובץ האישור, הרץ:

openssl x509 -noout -fingerprint -sha256 -in cert.pem | cut -d= -f2 | tr -d : | tr 'A-F' 'a-f'

כשהאישור מתחלף, כל מפתח רואה שוב את הנחיית האמון, לכן התייחס להחלפות כאירוע מתוכנן ופרסם מחדש את טביעת האצבע. אם מדיניות ה-gateway כוללת הגדרות שדורשות אישור, המפתח רואה גם את תיבת האישור הזו שוב אחרי קבלת האישור החדש, כי Claude Code קושר את זיכרון האישור לאישור הנעול.

gateway יכול להחזיר את השדה האופציונלי email בתשובת הטוקן כדי לנקוב בחשבון שכניסה השתמשה בו. כשהוא עושה זאת, המפתח מאשר את החשבון לפני ש-Claude Code שומר את פרטי הגישה. אחרי כניסה שאושרה, /status מציג את החשבון.

האישור דורש Claude Code בגרסה v2.1.275 או חדשה יותר על מכונת המפתח. לקוח מתחת לגרסה הזו מתעלם מהשדה. שרת ה-gateway בבינארי claude אינו מחזיר את השדה, ולכן הכניסות שלו מסתיימות בלי האישור.

אחרי שהמפתח נכנס, בורר המודלים מציג את המודלים ברשימת ההיתר availableModels שלהם. הגדרות מנוהלות חלות באתחול ומתרעננות מדי שעה, והטלמטריה מנותבת לאספן שלך.

סשנים מתרעננים בשקט לפני תפוגת ttl_hours. כשרענון נכשל אחרי הסרת הקצאה ב-IdP, Claude Code מבקש מהמפתח להיכנס שוב.

#הגדרת כתובת השער

שלושה מפתחות נכנסים לקובץ ההגדרות המנוהלות לפי מערכת ההפעלה שאתם פורסים דרך MDM או ישירות על הדיסק. למחשב בלי הגדרות מנוהלות, ראו במקום זאת הגדרת כתובת השער בהגדרות המשתמש. forceLoginMethod ו-forceLoginGatewayUrl פותחים את /login ישירות במסך Cloud gateway כשהכתובת ממולאת, ו-parentSettingsBehavior: "merge" מאפשר ל-Claude Desktop להעביר את רשימת ההיתר של יציאת השער להפעלות Claude Code שהוא מפעיל, כפי שמוסבר בהעברת מדיניות להפעלות Claude Desktop:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge"
}

המפתח לוחץ Enter כדי להתחבר. הבקשה לטביעת אצבע TLS בחיבור הראשון עדיין מופיעה. אחרי שהקובץ נמצא על מחשב, מפתח שעדיין לא השלים את הכניסה לשער רואה אחת מההודעות המתוארות תחת Administrator policy requires a Cloud gateway sign-in. מפתחים שבוחרים ספק ענן דרך משתנה סביבה כגון CLAUDE_CODE_USE_BEDROCK לא צריכים את הכניסה לשער.

לבוחר הכניסה אין אפשרות שער, ובהגדרות מנוהלות forceLoginMethod לבדו, בלי כתובת, משאיר את המפתח בהודעה "Contact your IT administrator". מפתחות הכניסה שייכים לקובץ שאתם דוחפים למחשבים, לא לבלוק managed.policies[].cli של השער, שמגיע רק ללקוחות שכבר מחוברים.

#הגדרת כתובת השער בהגדרות המשתמש

במחשבים בלי הגדרות מנוהלות, בקשו מכל מפתח להוסיף את forceLoginMethod ואת forceLoginGatewayUrl לקובץ הגדרות המשתמש שלו, ~/.claude/settings.json. זה דורש Claude Code בגרסה v2.1.295 או חדשה יותר על מחשב המפתח. הדוגמה הזו מציינת שער בכתובת claude-gateway.internal.example.com:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}

כשהמפתח מריץ /login בשורת Claude Code, מסך Cloud gateway נפתח בכתובת הזו והוא לוחץ Enter כדי להתחבר. הבקשה לטביעת אצבע TLS בחיבור הראשון עדיין מופיעה. המגבלות האלה חלות על מפתחות שמוגדרים בדרך הזו:

• הגדרות משתמש בלבד: Claude Code קורא את שני המפתחות מ-~/.claude/settings.json, לא מ-.claude/settings.json או מ-.claude/settings.local.json של פרויקט.
• הגדרות מנוהלות מכבות אותם: ברגע שהגדרות של מנהל מגיעות למחשב דרך קובץ הגדרות מנוהלות, plist של macOS או מדיניות HKLM של Windows, או עוזר מדיניות, Claude Code מתעלם משער שצוין בהגדרות המשתמש.

#התרת שער במרחב כתובות ציבורי שבבעלותכם

חלק מהארגונים ממספרים את הרשת הפנימית שלהם מבלוק IPv4 ציבורי שבבעלותם, כגון מרחב הכתובות של ספק תקשורת עצמו או /8 ישן, כך שלשער שלהם אין כתובת פרטית. ציינו את הבלוקים האלה בהגדרה המנוהלת gatewayInternalNetworks. אז /login מקבל שער בתוך בלוק שברשימה כשמחשב המפתח מתחבר אליו מכתובת בתוך אותו בלוק. זה דורש Claude Code בגרסה v2.1.268 או חדשה יותר על מחשב המפתח. גרסאות קודמות מתעלמות מהמפתח ומחילות את כלל הכתובת הפרטית.

[!WARNING]

gatewayInternalNetworks מיועד לרשתות פנימיות שבמקרה ממוספרות ממרחב כתובות ציבורי. הוא לא הופך לחשיפת שער לאינטרנט לבטוחה: שער מהימן יכול לדחוף הגדרות שמריצות פקודות על מחשבי מפתחים.

השאירו את השער בלתי נגיש מחוץ לרשת שלכם באמצעות כללי חומת האש או מאזן העומסים. הגדירו את access_control.allow_cidrs של השער לאותם בלוקים שאתם מצהירים כאן, כדי שהשער עצמו יסרב ללקוחות מכל מקום אחר. מאחורי מאזן עומסים או ingress, הגדירו גם את listen.trusted_proxies לחזית הזו, כי אחרת השער משווה את allow_cidrs מול הכתובת של החזית עצמה ולא מול הכתובת של המפתח.

הוסיפו את המפתח לאותו מקור הגדרות מנוהלות כמו מפתחות הכניסה: קובץ ההגדרות המנוהלות, פרופיל MDM, או מדיניות הרישום. Claude Code מתעלם ממנו בהגדרות משתמש, בהגדרות פרויקט, ובהגדרות מנוהלות בשרת.

הדוגמה הזו מצהירה על בלוק אחד. החליפו את 203.0.113.0/24 בבלוק שלכם. זה טווח תיעוד, ו-Claude Code מסרב לטווחים כאלה.

{
  "gatewayInternalNetworks": ["203.0.113.0/24"]
}

Claude Code מאמת את הרשימה ב-/login לפני שהוא פונה לכל שער:

• כל רשומה היא בלוק IPv4 שנכתב ככתובת הראשונה שלו וקידומת מ-/8 עד /32.
• הרשימה מחזיקה לכל היותר ארבעה בלוקים, ואין שני בלוקים חופפים.
• אף בלוק לא חופף למרחב כתובות פרטי: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, ו-100.64.0.0/10. /login כבר מקבל שער שם בלי המפתח הזה.
• אף בלוק לא חופף למרחב שלעולם אינו רשת של ארגון: 198.18.0.0/15 ו-192.0.0.0/24, שלקוחות VPN ו-NAT64 מחזיקים ככתובות מקומיות. טווחי התיעוד 192.0.2.0/24, 198.51.100.0/24, ו-203.0.113.0/24. והטווחים השמורים 0.0.0.0/8, 192.88.99.0/24, ו-multicast 224.0.0.0/4. אפשר להצהיר על בלוקים בתוך 240.0.0.0/4, שחלק מהרשתות הגדולות משתמשות בו כמרחב unicast פנימי.

בלוקים מ-managed-settings.json ומקבצי ה-drop-in שלו ב-managed-settings.d/ מתאחדים לרשימה אחת, והמגבלות האלה חלות על הרשימה המשולבת. כדי לצמצם בלוק, החליפו את הרשומה שלו במקום להוסיף רשומה שנייה חופפת ב-drop-in. /login מסרב לחפיפה.

אם רשומה שוברת כלל, או שהערך אינו רשימה של מחרוזות, Claude Code מסרב לכל כניסה חדשה לשער במחשב הזה ומציין את הבעיה בהודעה. גם כניסה לשער בכתובת פרטית נכשלת, וכניסות קיימות ממשיכות לעבוד. נסו את הערך על מחשב אחד לפני שאתם פורסים אותו. Claude Code גם מציין ערך מסוג שגוי בין ההגדרות המנוהלות הלא תקינות שהוא מדווח.

עם רשימה תקינה, /login מפעיל שלוש בדיקות על שער שכתובתו בתוך בלוק שברשימה:

• כל כתובת ששם המארח של השער מפוענח אליה נמצאת בתוך הבלוק האחד הזה. Claude Code מסרב לשם שיש לו גם רשומות מחוץ לו, כולל כתובות פרטיות וכתובות IPv6.
• מחשב המפתח מתחבר מתוך אותו בלוק. Claude Code מסרב למחשב מאחורי NAT, בתוך קונטיינר או WSL2, או על VPN שמאגר הכתובות שלו נמצא מחוץ לבלוק, ומציין את הכתובת שממנה המחשב התחבר.
• החיבור ישיר. אם HTTPS_PROXY חל על מארח השער, /login מסרב ומציין את רשומת NO_PROXY שצריך להוסיף.

כשכל שלוש עוברות, בקשת האמון מוסיפה שורה שמציינת את כתובת המחשב, את כתובת השער, ואת הבלוק המוצהר שמכיל את שתיהן.

המפתח הזה לא משנה דבר לשערים אחרים: כניסה לשער בכתובת פרטית עובדת כמו קודם, וכניסה לשער בכתובת ציבורית מחוץ לכל בלוק שברשימה נדחית כמו קודם.

בלוק מוצהר מצמצם מי יכול להיכנס אבל לא מוכיח היכן מחשב נמצא, אז הצהירו רק על מרחב כתובות שהארגון שלכם שולט בו. בלוק שמשותף עם דיירים אחרים, כגון טווח ציבורי של ספק ענן, מאפשר לכל מי שנמצא בו לעבור את אותה בדיקה.

#העברת מדיניות להפעלות Claude Desktop

Claude Desktop מריץ את הלשוניות Cowork ו-Code שלו, ובנוסף את Chat כשאתם מפעילים אותו, על הפעלות Claude Code מוטמעות, ושולח את בקשות המודל שלהן דרך השער. הוא מעביר מדיניות לכל אחת מההפעלות האלה, שנבנית מהתצורה שהשער מגיש לו ב-/user/bootstrap: רשימת ההיתר של המודלים, הכלים המושבתים, ורשימת היתר היציאה שנגזרת מבלוק cli או code של המדיניות התואמת, ובנוסף שכבת העל desktop.

שאר המפתחות של הבלוק, כגון hooks, env, וכללי הרשאה תחומים כמו Bash(npm *), מגיעים ללקוחות שנכנסים דרך /login. תחת code, הם מגיעים גם להפעלה של לשונית Code כשהתנאים ללשונית Code מתקיימים. הם לא מגיעים להפעלות Cowork או Chat. Claude Desktop קורא את כתובת השער מהתצורה המנוהלת שלו ונכנס בזרימה משלו, בנפרד ממפתחות forceLoginMethod ו-forceLoginGatewayUrl בהגדרת כתובת השער.

הגדרות שתהליך מפעיל מעביר הן הגדרות הורה. Claude Code מתעלם מהגדרות הורה בכל מחשב שיש לו מקור מנוהל שנפרס על ידי מנהל, אלא אם המקור שמעביר את המדיניות מגדיר parentSettingsBehavior: "merge".

#אילו מחשבים צריכים את ההצטרפות

מחשבים שמריצים רק את Claude Desktop צריכים אותה. Claude Desktop מחיל בעצמו את רשימת המודלים ואת רשימת הכלים המושבתים על הפעלות מוטמעות, אבל רשימת היתר היציאה מגיעה אליהן רק כהגדרות הורה, בצורה של כללי דומיין של WebFetch וכללי רשת של sandbox. בלי ההצטרפות, ההפעלות האלה רצות בלי הגבלת היציאה, ודבר לא מזהיר אתכם. השער עדיין דוחה בקשות הסקה למודלים שהמדיניות לא מעניקה.

רשימת היתר של שוק תוספים מגיעה גם היא להפעלות מוטמעות רק כהגדרות הורה. כשאתם מכבים שוקי תוספים שהמשתמש הוסיף בתצורה המנוהלת של Claude Desktop, Claude Desktop בגרסה 2.16120.0 או חדשה יותר מסתיר שווקים שהארגון שלכם לא סיפק, ומסרב להתקנות מהם. כדי לעצור הפעלות מוטמעות מטעינת תוספים שכבר הותקנו מהשווקים האלה, הוא שולח להן רשימת strictKnownMarketplaces כהגדרות הורה. בלי ההצטרפות, Claude Code מתעלם מהרשימה הזו, והתוספים האלה ממשיכים להיטען.

מחשבים שבהם מפתחים נכנסים דרך /login לא צריכים אותה. כל הפעלת Claude Code מביאה את המדיניות שלה מהשער.

ציים ש-policyHelper שלהם מספק הגדרות מנוהלות לא יכולים להשתמש בה: Claude Code אף פעם לא ממזג הגדרות הורה בציים האלה, כי הוא קורא הגדרות מנוהלות מהפלט של העוזר בלבד.

#הגדרת ההצטרפות

פרסו את קטע ההגדרות המנוהלות מהגדרת כתובת השער, שקפו אותו לכל מקור בצד הלקוח שמדרג מעל הקובץ, ואז אמתו.

1. פריסת ההצטרפות בקובץ ההגדרות המנוהלות

הקטע למעלה כבר כולל parentSettingsBehavior: "merge", כך שהקובץ שאתם דוחפים למחשבים נושא אותו.

2. שיקוף הקטע לכל מקור שמדרג מעל הקובץ

Claude Code קורא את parentSettingsBehavior רק מהמקור הנבחר. הוספת מפתח מדיניות כלשהו למקור יכולה להפוך את המקור הזה לנבחר, לכן במקור בצד הלקוח, שקפו את כל הקטע ולא את parentSettingsBehavior לבדו. הגדרות מנוהלות בצד הלקוח מכסות ציים שמעבירים מדיניות דרך Group Policy או פרופילי תצורה. plist של העדפות מנוהלות ב-macOS או מדיניות HKLM ב-Windows מדרגים מעל קובץ managed-settings.json, וההגדרות המנוהלות המרוחקות של השער עצמו מדרגות מעל שניהם, לכן במחשבים שנכנסים לשער, הגדירו גם את parentSettingsBehavior בבלוק cli או code של מדיניות השער.

3. בדיקה איזה מקור נבחר

במחשב שמריץ רק את Claude Desktop, קראו ל-resolveSettings() של Agent SDK וקראו את policyOrigin ברשומת managed ברשימת sources שלו. הערך מציין את המקור הנבחר בצד הלקוח, plist, hklm, או file, וזה המקור שחייב לשאת את הקטע.

הפעלות Cowork ו-Chat לא מביאות את מדיניות השער, לכן הבלוק של השער אינו המקור הנבחר עבורן.

הפעלה של לשונית Code מביאה אותה כשההגדרות של המדיניות נמצאות תחת code והתנאים ללשונית Code מתקיימים. הגדרות code של השער הן אז המקור הנבחר עבור ההפעלה הזו.

#הגבלת הגדרות אב

אחרי שפורסים parentSettingsBehavior: "merge", כל תהליך מארח שמפעיל את Claude Code יכול לספק הגדרות אב, לא רק Claude Desktop אלא גם יישום Agent SDK או הרחבת IDE.

Claude Code מסנן הגדרות אב מול רשימת היתר של מפתחות מגבילים, אבל חלק מהמפתחות המותרים יכולים להעניק גישה במקום להגביל אותה. אלא אם מגדירים את נעילות allowManaged*Only, כללי allow של הרשאות ורשימות היתר של sandbox שהמארח מספק עדיין חלים. כללי deny ו-ask של המדיניות נשארים בתוקף בכל מקרה. הם מוערכים לפני כל כלל allow.

Claude Code מעביר רשומות sandbox.credentials שסופקו על ידי האב בצורה מצומצמת:

• רשומות deny: מועברות רק עם path או name שלהן ועם המצב.
• רשומות קובץ עם mode: mask: מועברות כ-sentinel בלבד, כמסכה של הקובץ כולו ש-injectHosts שלה היא הרשימה הריקה, כך שהפרוקסי לעולם לא מחליף את הערך האמיתי עבור רשומה שסופקה על ידי האב, בכל פלטפורמה. גם כל שדות המיסוך המובנה מושמטים, כך שתבנית חילוץ שסופקה על ידי האב לא יכולה לדחוק מסכה מחמירה יותר שמקור אחר מגדיר לאותו נתיב.
• רשומות envVars עם mode: mask: לא מועברות. deny הוא ההגבלה היחידה שערוץ האב יכול לבטא דרך רשומות envVars.
• awsPairs ו-sigv4: מועברים כהגבלה בלבד. מ-sigv4 נשמרים רק ערכי deny, והורה שמגדיר בלוק sigv4 בכלל מצמיד את שלוש צורות הבקשה, streaming, presigned ו-sigv4a, ל-deny. זוג awsPairs לעולם לא מועבר בצורה שיכולה לחתום מחדש. זוג שמציין אחד ממשתני AWS המקובלים מוחלף ברשומה אינרטית ששומרת על דיכוי הצימוד האוטומטי של AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY ו-AWS_SESSION_TOKEN.

#פריסת הנעילות

כדי לשמור את הגדרות האב קרובות ככל שהמסנן תומך להגבלה בלבד, הוסיפו את כל חמש נעילות allowManaged*Only, ואת רשימות ההיתר שהן שולטות בהן, לאותם מקורות כמו ההצטרפות למיזוג:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.internal.example.com/*" }],
  "sandbox": {
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "filesystem": {
      "allowManagedReadPathsOnly": true,
      "denyRead": ["~/"],
      "allowRead": ["~/projects"]
    }
  }
}

מדיניות מערכת הפעלה, כגון מדיניות רישום HKLM או plist של managed-preferences, גוברת על הקובץ הזה, לכן מסרו את כל הקטע דרכה במקום דרך הקובץ. הגדרות מנוהלות מרוחקות של השער גוברות על מדיניות מערכת ההפעלה ועל מקורות הקובץ, אבל מגיעות רק ללקוחות מחוברים. שקפו את הנעילות, את רשימות ההיתר ואת ההצטרפות למיזוג לתוך בלוק cli או code של המדיניות, והשאירו את הקובץ הזה פרוס, כי מכונות שלעולם לא מתחברות מקבלות את המדיניות שלהן מהקובץ בלבד.

#התנהגות הנעילות בין מקורות

הגדרת נעילה אחת לא מגבילה את האחרות. כל מפתח מתועד בהפניה להגדרות.

ממקור מנהל שנמצא מתחת לזוכה, שתי נעילות ה-sandbox עדיין חלות, ו-allowManagedPermissionRulesOnly עדיין חוסם כללי allow שסופקו על ידי האב וגם additionalDirectories. ב-Claude Code v2.1.273 ומעלה, נעילת שרת MCP חלה גם ממקור שמתחת לזוכה, וכל עוד היא פעילה, רשימת allowedMcpServers המנוהלת מגיעה ממקור המנהל בעל העדיפות הגבוהה ביותר שמגדיר רשימה כזו.

נעילת ה-hooks וההשפעה של allowManagedPermissionRulesOnly על הכללים של המפתח עצמו דורשות את המקור הזוכה כברירת מחדל. תחת ההצטרפות למיזוג של managedSourcesBehavior באיך Claude Code משלב מקורות מנוהלים, Claude Code מחיל את הערך המחמיר ביותר שכל מקור מגדיר עבור כל נעילה. בציי policyHelper, Claude Code קורא את הנעילות מפלט העוזר בלבד.

כל נעילה גורמת ל-Claude Code להתעלם מהרשומות של המפתח עצמו עבור אותה הגדרה, לכן כללו את רשימות ההיתר של הארגון ליד הנעילות:

• דומיינים ברשת: נעילה עם רשימת דומיינים מנוהלת ריקה חוסמת את כל התעבורה היוצאת בתוך sandbox.
• שרתי MCP: נעילה בלי allowedMcpServers בשום מקור מנהל או בהגדרות שסופקו על ידי האב טוענת כל שרת ש-deniedMcpServers לא חוסם.
• נתיבי קריאה: רשומות allowRead מתירות מחדש רק נתיבים בתוך אזורי denyRead, לכן צמדו אותן ל-denyRead מנוהל.

#הגדרות שהנעילות לא מכסות

ההגדרות האלה שסופקו על ידי האב עוברות את המסנן גם כשכל חמש הנעילות מוגדרות:

• forceLoginOrgUUID: Claude Code מכבד ערך שסופק על ידי האב כשההגדרות המנוהלות שהוא מחיל לא מגדירות UUID של ארגון. כניסה דרך השער לא בודקת את המפתח הזה. UUID של ארגון בהגדרות המנוהלות ש-Claude Code מחיל חוסם את ערך האב, והוא ה-UUID של הארגון ש-Claude Code אוכף. אם הצי שלכם מצמיד ארגון Anthropic, ראו איזה מקור מנוהל מספק מפתחות כניסה לגבי המקום שבו מגדירים את forceLoginOrgUUID.
• allowedMcpServers: Claude Code מכבד רשימת היתר שסופקה על ידי האב כשאין רשימת מנהל בתוקף. allowManagedMcpServersOnly לא חוסם אותה, כי הנעילה אוכפת את הרשימה שזוכה כערך המנוהל, כולל רשימה שסופקה על ידי האב כשאף מקור מנהל לא מספק רשימה. רשימה במקור המנהל בעל העדיפות הגבוהה ביותר חוסמת את רשימת האב, והיא הרשימה ש-Claude Code אוכף, לכן הגדירו שם את allowedMcpServers, ליד הנעילה. לפני v2.1.223, ערך לאחד משני המפתחות בכל מקור מנהל חסם את ערך האב.
• availableModels: Claude Code מכבד רשימת מודלים שסופקה על ידי האב כשהמקור המנוהל הזוכה לא מגדיר רשימה. אם הצי שלכם מגביל מודלים, הגדירו את availableModels במקור הזוכה.
• allowedProviders: Claude Code מכבד רשימת היתר של ספקי API שסופקה על ידי האב כשהמקור המנוהל הזוכה לא מגדיר רשימה. אם הצי שלכם מגביל אילו ספקי API מפתחים יכולים להשתמש בהם, הגדירו את allowedProviders במקור הזוכה. דורש Claude Code v2.1.285 ומעלה.
• strictKnownMarketplaces: Claude Code מכבד רשימת היתר של שוקי תוספים שסופקה על ידי האב כשהמקור המנוהל הזוכה לא מגדיר רשימה. Claude Desktop 2.16120.0 ומעלה שולח רשימה כזו כשהתצורה המנוהלת שלו מכבה שוקי תוספים שהמשתמש הוסיף. אם הצי שלכם מגביל שווקים, הגדירו את strictKnownMarketplaces במקור הזוכה. דורש Claude Code v2.1.282 ומעלה.
• blockedMarketplaces: רשימת חסימה של שווקים שסופקה על ידי האב עוברת ומצטרפת לכל רשימת חסימה שמקור מנוהל מגדיר, כי רשימת חסימה יכולה רק להגביל עוד. דורש Claude Code v2.1.282 ומעלה.
• strictPluginOnlyCustomization: המפתח הזה עובר את המסנן בלי קשר לכל נעילה, והוא גורם ל-Claude Code להתעלם מההתאמה האישית של המפתח עצמו, כולל hooks מגנים. אף נעילה לא חוסמת אותו.

אם מגדירים את managedSourcesBehavior ל-"merge", בדקו איזה ערך של איזה מקור חל לכל סוג מפתח.

#איך מפתחות hook ו-skill בהגדרות אב נכנסים לתוקף

מפתחות שהיישום מעביר באפשרות managedSettings של Agent SDK הם הגדרות אב. במכונה שבה מנהל פורס הגדרות מנוהלות, Claude Code מתעלם מהגדרות אב אלא אם המנהל מאפשר למארח מטמיע להוסיף מדיניות.

אם מעבירים disableAllHooks: true ב-managedSettings:

• עצירה: hooks של משתמש, פרויקט ומקומיים, וגם hooks שמוצהרים ב-frontmatter של סוכן או באפשרות settings של ה-SDK.
• ממשיכים לרוץ: callback-ים של hook ב-SDK של היישום, ו-hooks של מנהל מהגדרות מנוהלות. היישום לא יכול לכבות את ה-hooks של המנהל.

העברת המפתחות האלה ב-managedSettings דורשת Claude Code v2.1.309 ומעלה, או TypeScript Agent SDK v0.3.309 ומעלה.

#חיבור Claude Desktop

Claude Desktop מתחבר לאותו שער דרך מפתח MDM אחר: הגדירו את bootstrapUrl בתצורה המנוהלת של Claude Desktop ל-<listen.public_url>/user/bootstrap, והצטרפו למדיניות המשתמש עם מפתח desktop. שכבת Claude Desktop מכסה את שני החלקים. דורש Claude Code v2.1.203 ומעלה בשרת השער.

Claude Desktop מחבר את המפתח דרך ספק הזהות של השער באותו שלב SSO בדפדפן, ואז מביא את התצורה שלו מהשער במקום מ-Anthropic. גישה למודלים ומדיניות עוקבות אחרי אותם כללים לפי קבוצה כמו ב-CLI. מפתח שמשתמש גם ב-CLI וגם ב-Claude Desktop נכנס לכל אחד בנפרד. סשן השער לא משותף ביניהם.

אחרי החיבור, Claude Desktop שולח בקשות מודל מכל לשונית מופעלת דרך השער. הוא מציג כברירת מחדל את לשוניות Cowork ו-Code. כדי שגם Chat יהיה זמין, הגדירו את chatTabEnabled ל-true בבלוק desktop של המדיניות, בשער שמריץ Claude Code v2.1.227 ומעלה. כש-Cowork פעיל, Claude Desktop מציג אז את Chat ואת Cowork יחד בלשונית אחת.

#צינורות CI ומכונות מרוחקות

אין זרימת service-token לצינורות לא מאוישים. כניסה לשער תמיד מריצה את זרימת המכשיר בדפדפן, ולכן עבודת CI בלי מפתח שיאשר את הכניסה לא יכולה לבצע אימות. הגדירו את אלה מול הספק ישירות. פרסו את forceLoginMethod ואת forceLoginGatewayUrl למכונות של מפתחים, והשאירו אותם כבויים על רצי CI. במכונה שההגדרות המנוהלות שלה מגדירות אותם, סשן שמבצע אימות עם ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN או apiKeyHelper יוצא בהפעלה.

אחרי שמפתח נכנס, כל סשן Claude Code באותה מכונה משתמש בסשן השער, כולל הרצות claude -p לא אינטראקטיביות וסשנים ש-Agent SDK מתחיל. Claude Code מחיל את מדיניות השער על כל אחד מהם.

זרימת המכשיר מפרידה בין ה-CLI שבודק לבין הדפדפן המאשר, ולכן מכונת פיתוח מרוחקת בלי תצוגה עדיין עובדת: המפתח מריץ /login דרך SSH במכונה המרוחקת ופותח את קישור האימות בדפדפן במחשב הנייד שלו.

#מה נאכף על מפתחים

הערבויות האלה חלות על כל סשן שנכנס דרך /login. הסשנים המוטמעים ש-Claude Desktop מפעיל מקבלים את המדיניות שלהם כפי שמתואר במסירת מדיניות לסשנים של Claude Desktop, וסעיף הטלמטריה אומר לאן הייצוא שלהם הולך.

• גישה למודלים: בקשות למודלים שהמדיניות לא מעניקה מחזירות 400, ובורר /model מסונן לרשימת ההיתר availableModels של המדיניות. זה כולל את המודל שסשן מתחיל עליו לפני שהמפתח בוחר אחד. ראו התחלת סשנים על מודל שהמדיניות מתירה.
• יעד טלמטריה: בסשנים שנכנסו דרך /login, ה-CLI שולח את ייצואי OTLP/HTTP שלו לשער במקום ל-OTEL_EXPORTER_OTLP_ENDPOINT שהוגדר מקומית, אלא אם מדיניות מציינת את האספן שלכם כנקודת הקצה. השער מעביר הלאה את הייצוא שהוא מקבל ליעדים ב-telemetry.forward_to.
  • בסשנים המוטמעים שClaude Desktop מפעיל, ה-CLI שולח את הייצוא שלו ל-OTEL_EXPORTER_OTLP_ENDPOINT שהוגדר. ה-CLI מצרף את אסימון סשן השער לייצוא הזה רק כשנקודת הקצה הזו מצביעה על השער עצמו.
  • כשאין יעד מוגדר עבור אות, השער מקבל ומשליך אותו.
  • אם כבר אוספים טלמטריה של Claude Code ישירות, הוסיפו את האספן כיעד forward_to, או ציינו אותו במדיניות כדי לדלג על ההעברה.
• אישורים: אסימון השער הוא האישור היחיד של הסשן. פרופילי Anthropic וכל כניסה קודמת ל-claude.ai מתעלמים מהם בזמן החיבור, ולכן מפתחים לא צריכים להתנתק מ-claude.ai קודם. עבור אישור ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN או apiKeyHelper שהוגדר, או מפתח API שנשמר על ידי כניסה קודמת ל-Claude Console, ראו מדיניות מנהל דורשת כניסה לשער Cloud.
• הגדרות מנוהלות: מפתחות נעולים לא ניתנים לדריסה מקומית. ה-CLI מחיל את המדיניות בהפעלה ומחיל שינויים בכל סקר שעתי, מלבד השינויים שחלים רק בהפעלה הבאה.
• הפעלה כשהשער לא נגיש: סשנים שנכנסו יוצאים בהפעלה עם שגיאה אחרי כ-10 שניות, במקום להתחיל בלי ההגדרות שלהם.
• הפעלה אחרי שהשער מסיים את הסשן: ראו אכיפת הפעלה סגורה בכישלון לגבי ההפעלות שנפתחות כשהמשתמש מנותק מהשער, ואלה שיוצאות כשהשער עונה עם 401.
• ביטול הקצאה: סשן שהמשתמש שלו מושבת ב-IdP פג תוקף בתוך ttl_hours כשהרענון הבא נכשל.
• התנתקות: /logout מוחק את אישור השער ממכונת המפתח.
  • כשמסמך הגילוי של השער מפרסם revocation_endpoint על הסכמה, המארח והפורט של כתובת השער עצמה, /logout גם שולח את האסימונים השמורים לנקודת הקצה הזו כדי שהשער יוכל לסיים את הסשן בצד שלו. הבקשה היא במאמץ מיטבי, ולכן ההתנתקות מסתיימת במכונת המפתח בין אם נקודת הקצה עונה ובין אם לא. הביטול דורש Claude Code v2.1.275 ומעלה במכונת המפתח.
  • שרת השער בקובץ הבינארי claude לא מפרסם אף אחד, ולכן התנתקות ממנו מסיימת את הסשן במכונת המפתח בלבד. כדי לכפות יציאת סשנים בצד השרת, ראו רוטציית סוד JWT.

#מה הארגון יכול לראות

טלמטריית השימוש נושאת את זהות המפתח, ספירות אסימונים, מודל והשהיה אל האספן של הארגון. השער לא רושם ולא שומר תוכן של prompt או completion. אם נאספת טלמטריה עשירה יותר כגון לוגים ועקבות, שיכולה לכלול פקודות ונתיבי קבצים, זו בחירה לפי יעד של הארגון.

#זמינות ומגבלות

הטבלה מכסה אילו יכולות של Claude Code פועלות כשמפתחים מתחברים דרך השער, ומה שרת השער עצמו תומך בו. כשמשהו אינו נתמך, עמודת ההערות נותנת את החלופה.

השער מעביר את ערכי anthropic-beta שה-CLI שולח לכל upstream, כך שמפעילים לא מתחזקים רשימת היתר של beta. עבור Amazon Bedrock, שמתעלם מהכותרת, השער מעביר את הערכים לשדה anthropic_beta בגוף הבקשה. שאר ה-upstreams מקבלים את הכותרת כפי שנשלחה.

#הצעדים הבאים

ה-quickstart משאיר אתכם עם תצורה מינימלית שרצה תחת Docker Compose. כדי להמשיך הלאה:

• הרחיבו את gateway.yaml מעבר לתצורה המינימלית, למשל כדי להוסיף RBAC לפי קבוצה, failover של כמה upstreams, או יעדי טלמטריה. הפניית התצורה מכסה כל אפשרות.
• עברו מ-Compose לפריסת ייצור ב-Kubernetes או ב-Cloud Run, הגדירו את ה-IdP כראוי, וסקרו את מודל האבטחה. מדריך הפריסה והתפעול מכסה הגדרה לפי IdP, דרישות image של קונטיינר, בדיקות health ופתרון בעיות.
• שימו תקרות הוצאה על מפתחים בודדים או על קבוצות כדי שעומס שיצא משליטה לא יצרוך את כל ההתחייבות שלכם. מגבלות הוצאה מכסה את ה-API לניהול ואת אופן האכיפה.
• לדוגמה מעובדת מלאה ב-AWS, עם ECS Fargate או EKS, Amazon RDS ו-Secrets Manager, ראו פריסה ב-AWS.
• לדוגמה מעובדת מלאה ב-Google Cloud, עם Cloud Run, Cloud SQL ו-Secret Manager, ראו פריסה ב-Google Cloud.