📘 תיעוד 4

פריסות ארגוניות

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

#דרישות רשת

כל החיבורים משתמשים ב-HTTPS (פורט 443).

#נדרש

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

אם משתמשים ב-OIDC ארגוני, יש לאפשר גם את הדומיין של ה-IdP (לדוגמה login.microsoftonline.com).

#נוסף

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

המארחים x.ai ו-storage.googleapis.com נדרשים רק למתקין סקריפט המעטפת ול-grok update מתוך האפליקציה. אם הסביבה משתמשת ב-npm להפצה (npm install -g @xai-official/grok), אף אחד מהמארחים האלה לא נדרש.

#TLS

כל החיבורים משתמשים ב-TLS 1.2 או TLS 1.3, שנאכפים על ידי rustls (בלי תלות ב-OpenSSL). אישורי שורש נטענים מחנות האמון של מערכת ההפעלה. אין אפשרות לבטל TLS. עבור פרוקסי שמבצעים בדיקת TLS, יש להתקין את אישור ה-CA של הפרוקסי בחנות האמון של מערכת ההפעלה.

#תמיכה בפרוקסי

ה-CLI מכבד משתני סביבה סטנדרטיים של פרוקסי (HTTPS_PROXY, HTTP_PROXY, NO_PROXY). מאגר חיבורי HTTP שומר חיבורים לא פעילים פתוחים למשך 90 שניות כברירת מחדל (GROK_POOL_IDLE_TIMEOUT_SECS), ובקשות הסקה משתמשות בסטרימינג SSE שבו זמן ההמתנה ללא פעילות לכל מקטע הוא 600 שניות כברירת מחדל. יש להגדיר זמני המתנה ללא פעילות של הפרוקסי ל-10 דקות לפחות כדי למנוע ניתוקים מוקדמים במהלך תשובות ארוכות של המודל.

#הגדרות

Grok טוען הגדרות מחמש שכבות, מהעדיפות הנמוכה ביותר לגבוהה ביותר:

הגדרות ב-requirements.toml לא ניתנות לדריסה על ידי שכבות נמוכות יותר, הגדרות מרוחקות או הגדרות משתמש. יש להשתמש בהן למדיניות קריטית לעמידה בדרישות. כל השכבות תומכות ב-[[version_overrides]] לתיקונים מותני גרסה ובהרחבת $VAR.

#מדיניות ברמת המערכת ל-MDM ולפריסות מנוהלות

שכבת ההגדרות בעדיפות הגבוהה ביותר היא /etc/grok/requirements.toml. זה המנגנון המומלץ לארגונים שמנהלים את Grok בקנה מידה גדול דרך Mobile Device Management (MDM), תמונות זהב, כלי ניהול הגדרות או סקריפטי קליטה.

דפוסי פריסה נפוצים:

• MDM / ניהול נקודות קצה: לדחוף את קבצי ה-TOML ישירות אל /etc/grok/ בתחנות עבודה מנוהלות.
• תמונות זהב / AMIs: לאפות את קבצי המדיניות בתמונות בסיס שמשמשות למחשבי מפתחים או ל-CI runners.

ערכים שנעוצים ב-requirements.toml משתמשים במנגנון pin מסוג fail-closed: אי אפשר לדרוס אותם דרך config.toml של המשתמש, משתני סביבה, הגדרות מרוחקות או שכבות בעדיפות נמוכה יותר. זה הופך את /etc/grok/requirements.toml למקור הסמכות למדיניות קריטית לעמידה בדרישות, כמו ביטול טלמטריה, אכיפת פרופילי sandbox, הגבלת כלים או נעיצת דגלי תכונות ספציפיים.

#תאימות ל-Claude Code (אופציונלי)

ארגונים שכבר משתמשים ב-Claude Code ופרסו את הקובץ managed-settings.json שלו דרך MDM יכולים להמשיך להסתמך על הקובץ הזה. Grok קורא ממנו תת-קבוצה של מדיניות (כללי הרשאות, רשימות היתר של שרתי MCP, כמה דגלי טלמטריה ומשוב, והגבלות marketplace) לצורך תאימות.

הקובץ /etc/grok/requirements.toml של Grok תמיד גובר על הקובץ managed-settings.json של Claude. שכבת התאימות ל-Claude רלוונטית רק לסביבות מעורבות של Claude ו-Grok. פריסות Grok טהורות צריכות להשתמש ב-requirements.toml + config.toml.

#אימות

Grok Build תומך בארבע שיטות אימות סשן:

כשיש כמה פרטי התחברות זמינים, Grok פותר אותם לפי מודל: model.api_key > model.env_key > טוקן הסשן הפעיל > XAI_API_KEY.

#OIDC ארגוני

ארגונים עם ספק זהות ארגוני (Entra ID, Okta, Auth0 וכו') יכולים להגדיר את Grok להתאמת ישירות מולו:

[auth.oidc]
issuer = "https://login.yourcompany.com"
client_id = "your-client-id"

או דרך הסביבה: GROK_OIDC_ISSUER ו-GROK_OIDC_CLIENT_ID. הזרימה משתמשת ב-PKCE ותומכת במענקי refresh_token לחידוש אוטומטי.

#ספק אימות חיצוני

יש לכוון את Grok לקובץ הרצה שמייצר טוקן ב-stdout:

[auth]
auth_provider_command = "/usr/local/bin/your-auth-provider"

הפקודה חייבת להדפיס מחרוזת טוקן גולמית או JSON: {"access_token": "...", "refresh_token": "...", "expires_in": 3600} (refresh_token ו-expires_in הם אופציונליים).

Grok מריץ את הפקודה לפי שני חוזים ומגדיר את GROK_AUTH_EXPIRED כדי להבדיל ביניהם. הערך הוא 1 ברענון ברקע על פרטי התחברות ש-Grok כבר מחזיק: אף אחד לא צופה, ולפקודה יש כמה שניות לפני ש-Grok הורג אותה. לכן יש להנפיק טוקן בשקט או לצאת עם קוד שונה מאפס, ולעולם לא לחכות לקלט. הוא לא מוגדר בהתחברות, שבה משתמש מצורף, stderr של הפקודה מוצג לו, ויש עד 300 שניות לסבב דפדפן או ל-device code. פקודה שיוצאת במהירות כש-GROK_AUTH_EXPIRED=1 במקום לבקש קלט היא מה שהופך את המעבר למסך ההתחברות למהיר.

#מפתח API

עבור CI/CD ואוטומציה ללא ממשק גרפי, יש להגדיר את משתנה הסביבה XAI_API_KEY. אין צורך בקובץ הגדרות:

export XAI_API_KEY="xai-..."
grok -p "Review this diff" --output-format json --always-approve

בתחנות עבודה קבועות של מפתחים, אפשר במקום זאת לקשור מפתח למודל ספציפי ב-~/.grok/config.toml:

[model.grok-build]
api_key = "xai-..."

[models]
default = "grok-build"

ראו ללא ממשק גרפי וסקריפטינג לפורמטי פלט ולדגלי CLI.

#Device code

עבור סביבות בלי דפדפן (SSH, קונטיינרים, devboxes בענן), התחברות עם device code פועלת לפי RFC 8628:

grok login --device-auth

Grok מדפיס URL וקוד משתמש קצר. יש להשלים את ההתחברות בכל מכשיר עם דפדפן.

#הגבלת שיטות התחברות

שתי מדיניות שולטות באופן שבו משתמשים מתאמתים. יש להגדיר אותן ב-requirements.toml כדי ש-config.toml של משתמש, משתנה סביבה או הגדרה מרוחקת לא יוכלו לדרוס אותן.

disable_api_key_auth כופה התחברות IdP אינטראקטיבית. השיטה xai.api_key כבר לא מוצעת ולא מתקבלת, ובזמן הבקשה מפתח API של xAI מצד ראשון מוחלף בטוקן הסשן של ה-IdP, כך שמפתח XAI_API_KEY שנשאר או מפתח לפי מודל לא יכולים לדלג על SSO. נקודות קצה של צד שלישי (BYOK) ממשיכות לעבוד, כי ה-base_url שלהן לא נמצא ב-x.ai. יש להגביל אותן דרך IAM של הספק שלכם.

[grok_com_config]
disable_api_key_auth = true

force_login_team_uuid נועץ את ההתחברות לצוות. ה-principal של הצוות בטוקן חייב להתאים לערך שהוגדר, כך שהתחברות אישית או התחברות לצוות הלא נכון נדחות עם שגיאה ושום דבר לא נכתב ל-auth.json. אפשר להגדיר UUID של צוות אחד או רשימה, ובמקרה כזה כל צוות ברשימה מותר. רשימה ריקה דוחה כל התחברות. הגדרת זה גם מפעילה את disable_api_key_auth, כי מפתח API גולמי לא נושא חברות בצוות.

[grok_com_config]
force_login_team_uuid = "<your-team-uuid>"
# Or allow several teams:
# force_login_team_uuid = ["<team-a-uuid>", "<team-b-uuid>"]

הערך הוא ה-UUID של הצוות, שה-access token נושא כ-login principal שלו. האכיפה חלה בכל פעם שסשן מונפק או בשימוש חוזר, כולל טוקנים במטמון ורענונים שקטים. סשן שכבר לא עומד בדרישות מנוקה, כך שהמשתמש צריך להתחבר שוב. יש להריץ grok inspect כדי לבדוק איזו מדיניות התחברות נטענה.

אם עוברים מ-Claude Code, forceLoginMethod ממופה ל-disable_api_key_auth, ו-forceLoginOrgUUID ממופה ל-force_login_team_uuid, שמקבל UUID של צוותים.

#בקרות אבטחה

הרשאות יומיומיות (מצבים, כללי allow/deny) ופרופילי sandbox חלים על מכונות בודדות וגם על פריסות מנוהלות. הסעיף הזה מכסה מדיניות ארגונית בלבד: נעיצה, מצבים ללא ממשק גרפי, ונעילת always-approve.

#Sandbox

פרופילים, sandbox.toml מותאם, ואופן הקשר בין ה-sandbox להרשאות נמצאים תחת Sandbox. יש לנעוץ פרופיל ב-requirements.toml:

[sandbox]
profile = "workspace"

#הרשאות

Ask, auto ו-always-approve, בנוסף לדגלי CLI --allow / --deny ולכללי הגדרות, נמצאים תחת הרשאות. עבור הרצות CI והרצות ללא ממשק גרפי, שני מצבים נוספים חשובים:

דוגמה להרצה ללא ממשק גרפי:

grok -p "Review the API changes" \
  --permission-mode dontAsk \
  --allow 'Bash(git *)' \
  --allow 'Bash(gh *)' \
  --allow 'Read' \
  --allow 'Grep' \
  --deny 'Bash(rm -rf *)' \
  --sandbox strict

נעילת מצב bypass-permissions

יש להגדיר disable_bypass_permissions_mode = true תחת [ui] כדי לכבות always-approve (bypass-permissions) בכל הפריסה. זה חוסם כל דרך להפעיל אותו מחדש: הדגלים --yolo ו---permission-mode bypassPermissions, המתגים בתוך הסשן (Ctrl+O, /always-approve, ומחזור המצבים ב-Shift+Tab), הגדרות yolo שמגיעות מהלקוח, וכללי allow כוללניים כמו * או **. כללי deny עדיין חלים, וההתנהגות לא משתנה כשאין נעילה.

[ui]
disable_bypass_permissions_mode = true

כדי להתנגד לשיבוש, הנעילה מכובדת רק ממקורות בבעלות root (/etc/grok/requirements.toml או שכבת המערכת), לא מ-~/.grok/requirements.toml שניתן לכתיבה על ידי המשתמש. disableBypassPermissionsMode: "disable" ב-managed-settings.json של Claude Code לא מוחל על always-approve של grok. grok מכבד את כללי ההרשאות, רשימות ההיתר של MCP והגבלות marketplace בקובץ הזה, אבל --yolo / [ui] permission_mode / מתג בזמן ריצה של מפתח עדיין נכנסים לתוקף. זה מונע מ-grok לרשת נעילה של Claude Code במארח (לדוגמה אשכולות משותפים שהוקשחו על ידי AppSec). כדי לבטל always-approve ב-grok, יש להגדיר disable_bypass_permissions_mode = true ב-requirements.toml של grok עצמו.

#פרטיות ומחזור החיים של הנתונים

#מחזור החיים של הנתונים

סשן מעביר נתונים דרך שישה שלבים:

1. קלט משתמש: prompt ותוכן קבצים מורכבים מקומית.
2. תעבורה: נשלחים ב-TLS 1.2/1.3 לפרוקסי ההסקה.
3. הסקה: הפרוקסי מעביר למודל. ארגוני ZDR מנותבים דרך זהות שירות ייעודית שמדלגת על רישום.
4. הרצת כלים: מתרחשת מקומית בסביבת ה-sandbox של המשתמש.
5. תשובה: זורמת חזרה על אותו חיבור TLS.
6. סיום סשן: אין שמירה של prompts, קוד או תשובות בשכבת ההסקה עבור ארגוני ZDR. היסטוריית הסשן המקומית נשמרת ב-~/.grok/.

#Zero Data Retention

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