ניהול דיירים (ארגונים וחברים)

פריסה יחידה של AgentEye משרתת מספר ארגונים מבודדים לחלוטין (דיירים), כך שאפשר להנחות שם צוותים נפרדים, יחידות עסקיות או לקוחות ללא חשיפת נתונים של דייר אחד לאחר. כל שורה של נתונים (אירועים, הערכות, סשנים, לוחות בקרה, שאילתות שמורות, התראות, מפתחות API וחברים) שייכת לבדיוק ארגון אחד. בידוד ראשוני מיושם בקוד היישום: כל בקשה מוגבלת לארגון שלה עם תחזוקי org_id מפורשים. ב-ClickHouse — שם האירועים וההערכות בנפח גבוה משתהים — זה מסובב על ידי אכיפה חזקה ברמת המנוע: כל ארגון מקבל משתמש ClickHouse ייעודי לקריאה בלבד עם מדיניות שורות לכל ארגון, כך שאפילו SQL אנליטיקה לא מהימנה לא יכולה לעולם לקרוא שורות של דייר אחר. בפוסטגרס, אבטחה ברמת השורה מוסיפה הגנה במעומק על נתיב השאילתה לקריאה בלבד (/queries/run), מצמצמת מה שנתיב זה יכול לראות גם אם מסנן ברמת היישום היה חסר אי פעם; חיבור הכתיבה שלעצמו של השרת פועל בתור בעל הטבלה ולכן פועל דרך אותה יישום-ברמת org_id scoping. מחזור החיים של הדייר נשלט על ידי המפעיל, בעוד שהכל שחברים עושים ביום-יום נשאר שירות עצמי בלוח הבקרה. ארגונים וחברותם שלהם נוצרים ומנוהלים באמצעות ה-CLI agenteye-orgctl, המגיע בתוך תמונת השרת ופועל בתוך תרמיל השרת הקיים. יצירת ומחיקת דיירים נשמרו בכוונה מחוץ ללוח הבקרה וממשק ה-HTTP: אין ממשק HTTP ולא כפתור בלוח בקרה למחזור חיים של דייר, כך שהוא מנעול מאחורי גישת shell של cluster/pod ולא על המשטח היישום. בתוך ארגון, חברים עובדים כולם בלוח הבקרה וב-API: הם נכנסים, עברים בין הארגונים שהם שייכים להם, מנהלים את המפתחות API שלהם, בונים לוחות בקרה ושאילתות שמורות, ומגדירים התראות לארגון שלהם. החלוקה נקייה: מפעילים מפקחים ומפחיתים דיירים וחברים שלהם דרך ה-CLI; חברים מפעילים הכל בתוך דייר דרך ממשק המשתמש.

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

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

לפני שאתה יוצר את הארגון השני שלך (הארגון default המובנה לא צריך שום דבר):

PostgreSQL 15+. סכימת חברות הארגון משתמשת במפתח זר של ON DELETE SET NULL ברשימת עמודות הדורש PostgreSQL 15+. שדרג את PostgreSQL לפני הפקת ארגון שני.
ORG_CH_SECRET חזק ויציב. סיסמת ClickHouse של כל ארגון נגזרת כ-HMAC(ORG_CH_SECRET, org_id), כך שברירת ברירת הפיתוח המובנית הידועה לציבור תניב credentials לכל ארגון שניתן לגזור לציבור. agenteye-orgctl org create מסרב לפעול בזמן ORG_CH_SECRET הוא ללא הגדרה או משמאל לברירת ברירת הפיתוח המובנית. קבע את הערך שלך תחילה (ראה Deployment → environment variables ובקוברנטס, §2.6 של מדריך Kubernetes). שמור עליו זהה בכל רפליקות השרת ואל תסובב אותו בשפיות; סיבוב שלו יוצר יתמים כל משתמש ClickHouse של ארגון עד שהיום הבא של סטארט-אפ מחדש מחדש אותם.

הרצת ה-CLI

agenteye-orgctl משונה בתוך אותה תמונה כמו השרת (לצד agenteye-server). אתה לא מפריס תרמיל, עבודה או פריסה נפרדת עבורה; אתה exec אותה בתוך תרמיל השרת שכבר פועל, כך שהוא קורא את אותו DATABASE_URL, CLICKHOUSE_URL ו-ORG_CH_SECRET שהשרת משתמש. Kubernetes:

kubectl -n agenteye exec deploy/server -- agenteye-orgctl <args>

Docker Compose:

docker compose exec server agenteye-orgctl <args>

הדוגמאות להלן מציגות את ה-agenteye-orgctl <args> חשוף בקצרות; הקדמה כל אחת עם אי מהשתיים למעלה שתאים להפריסה שלך.

הפניה לפקודה

ארגונים

פקודה	מה היא עושה
`org create --slug <slug> --name <name>`	יצירת ארגון חדש. מסרב לפעול בזמן `ORG_CH_SECRET` הוא ללא הגדרה או משמאל לברירת ברירת הפיתוח המובנית (קבע את שלך תחילה, ראה דרישות מוקדמות). מפקח משתמש ClickHouse לקריאה בלבד של הארגון + מדיניות שורות.
`org list`	רשימה של כל הארגונים (slug, שם, ומצב מחזור החיים).
`org rename --slug <slug> --name <new name>`	שנה את שם התצוגה של ארגון. ה-slug (המשמש בכתובות URL ומפתחות) אינו משתנה.
`org delete --slug <slug>`	מחיקה רכה של הארגון והורדת משתמש ClickHouse שלו. הנתונים יישמרו. זה מבטל גישה ומשחרר את ה-credential ClickHouse לכל ארגון, אבל לא מוחק אירועים. הפיך על ידי ops; צעד בטוח ראשון לפני טיהור.
`org purge --slug <slug>`	מחיקת נתונים בלתי הפיכה. הארגון חייב להיות כבר `delete`d. לא מותר אי פעם בארגון `default` המובנה. השתמש רק כשאתה בטוח שנתוני הדייר צריכים להיהרס.

חברים

פקודה	מה היא עושה
`member add --org <slug> --email <email> [--set <permission-set>] [--add perm1,perm2] [--remove perm3] [--protected]`	הוסף חבר לארגון. אופציונלי התחל מסט הרשאות מובנה, ואז הוסף/הסר הרשאות בודדות. `--protected` תופסים את החבר כך שלוח הבקרה לא יכול להסיר או להדחיק אותם (ראה להלן). החבר החדש מקבל OTP בהתחברות הלוח הראשונה שלהם.
`member list --org <slug>`	רשימה של חברי הארגון. עמודות הפלט הן `EMAIL`, `SET` (סט ההרשאות המובנה שהחבר התחיל מהם, או `-`), `PROT` (האם החבר מוגן), ו-`PERMISSIONS` (ההרשאות האפקטיביות שלהם). דוא”ל המוצג עם `*` סיום היא מנהל מופע; יש להם גישה לכל ארגון.
`member update --org <slug> --email <email> [--set ...] [--add ...] [--remove ...] [--protected \| --unprotect]`	שנה הרשאות של חבר ו/או דגל מוגן. `--set` מחליף מסט מובנה; `--add` / `--remove` התאמות הרשאות בודדות; `--protected` / `--unprotect` החלף הגנה. העברת רק `--protected`/`--unprotect` (ללא דגלי מענק) שינויים הגנה לבד והשארת הרשאות קיימות ללא נגע.
`member remove --org <slug> --email <email>`	הסר חבר מהארגון. מסרב אם החבר מוגן; `--unprotect` אותם קודם. (אדם יכול להיות חבר בכמה ארגונים; זה משפיע רק על הארגון בשם.)

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

חברים מוגנים (מנהל ארגון בלתי ניתן להסרה)

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

עמוד המשתמשים: כרטיס לכל משתמש של לוח בקרה עם הדוא"ל שלהם, הרשאות שהוקצו, ובקרות עריכה/השבתה.

כדי למנוע זאת, סימן חבר אחד מוגן:

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member add --org acme --email owner@acme.example --set admin --protected

חבר מוגן לא יכול להיהסר או להדחיק דרך לוח הבקרה; פעולות אלו מחזירות שגיאה. רק מפעיל יכול לשנות אותם, וזה רק דרך CLI זה: הרץ member update --org acme --email owner@acme.example --unprotect קודם, ואז להסיר או להדחיק. זה מבטח שכל ארגון שומר על פחות ממנהל אחד חברים משלהם לא יכולים לנעול, תוך שמירה על שליטה בדייר רק של מפעיל. הגנה היא לכל ארגון; הגנה על מישהו בארגון אחד אין השפעה על חברותו בארגון אחר.

סטים הרשאות מובנים

--set מקבל אחד משלושת סטים מובנים, מיושם לכל ארגון:

סט	מיועד ל
`admin`	גישה מלאה בתוך הארגון, כולל ניהול מפתחות ומשתמשים API של הארגון.
`standard`	שימוש יום-יומי: קרא + הרץ שאילתות, בנה לוחות בקרה, הכר אירועים.
`read-only`	גישת תצוגה בלבד לנתונים ולוחות בקרה של הארגון.

התחל מסט עם --set, ואז בדוק בעדיניות באמצעות --add / --remove באמצעות אסימוני ההרשאה הבודדים המופיעים ב-API Keys. אסימוני ההרשאה עצמם זהים לאלה המשמשים למפתחות API.

דוגמה עבודה

ספק דייר acme חדש, הוסף את המנהל הראשון שלו, אפשר להם למטבע מפתח, ואז להסיר את הארגון מההפעלה. 1. יצור את הארגון (ORG_CH_SECRET חייב להיות כבר מוגדר לערך חזק ויציב, לא ללא הגדרה או ברירת ברירת הפיתוח המובנית):

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org create --slug acme --name "Acme Corp"

2. הוסף את החבר הראשון כמנהל ארגון:

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member add --org acme --email alice@acme.example --set admin

אליס מקבלת OTP בפעם הראשונה שהיא נכנסת ללוח הבקרה. מאז הלאה היא עובדת כולה בממשק ברמת תחיית הארגון שלה (למשל /acme/sessions). 3. מטבע מפתח API לכל ארגון (בלוח הבקרה): המפעיל לא מטבעות מפתחות נתונים לכל ארגון מה-CLI. אליס (או כל חבר ארגון עם keys:create) יוצרת אספן / מפתחות לוח בקרה לארגון acme מעמוד המפתחות של לוח הבקרה. כל מפתח שהיא יוצרת מוטבע באופן אוטומטי עם הארגון שלה ויכול לעולם לקרוא או לכתוב נתוני acme בלבד. ראה API Keys. 4. התאם חבר מאוחר יותר:

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member update --org acme --email alice@acme.example --add alerts:write

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member list --org acme

5. מחיקה רכה של הארגון (מבטל גישה + מורידה משתמש ClickHouse שלו; נתונים שמורים):

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org delete --slug acme

6. טיהור הארגון (בלתי הפיך; רק אחרי מחיקה רכה; לא ממש הארגון default):

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org purge --slug acme

ב-Docker Compose, החלף כל קידומת kubectl -n agenteye exec deploy/server -- עם docker compose exec server.

חלוקת אחריות

הכל חבר ארגון צריך ביום-יום הוא שרות עצמי בלוח הבקרה וב-API, מוגבל באופן אוטומטי לארגון הנוכחי שלהם:

מפתחות API לכל ארגון נוצרים ומנוהלים על ידי חברי ארגון בלוח הבקרה (או דרך API המפתחות עם מפתח שנושא keys:create). ה-CLI לא מטבעות נתונים מפתחות. ראה API Keys.
החלפת ארגון מובנה בלוח הבקרה; חברים משתנים בין הארגונים שהם שייכים להם מה-org switcher, ודפי scoped של ארגון משתהים תחת /<org-slug>/….
לוחות בקרה, שאילתות שמורות, התראות, וכל נתוני השימוש קורים כולם בממשק ה-UI וב-API, scoped לארגון הנוכחי של החבר.

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

ראה גם

Deployment: ORG_CH_SECRET והשאר סביבת השרת.
Kubernetes Deployment: §2.6 יוצר את agenteye-org-ch-secret Secret לפני הארגון הרב-דייר הראשון שלך.
API Keys: דגם מפתחות לכל ארגון ואסימוני ההרשאה המשמשים על ידי --add / --remove.
Troubleshooting: בעיות הפקת ruleulti-tenant והבדל ClickHouse.

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

​הרצת ה-CLI

​הפניה לפקודה

​ארגונים

​חברים

​חברים מוגנים (מנהל ארגון בלתי ניתן להסרה)

​סטים הרשאות מובנים

​דוגמה עבודה

​חלוקת אחריות

​ראה גם