IAM¶

IAM שולט מי יכול לעשות מה בחשבון: זהויות קונסול (משתמשים + קבוצות + מדיניות), Roles/Policies של data-plane, ו-Access Keys ל-CLI/SDK/Terraform.

פריט	ערך
Console	IAM → משתמשים (יצירה / עריכה) · חשבון → משתמשים (תצוגה לקריאה בלבד)

שתי שכבות (אל תערבבו אותן)¶

1. גישת קונסול (אנשים) — קבוצות ומדיניות (ADR-053)¶

אנשים מקבלים הרשאות מצירופי מדיניות ומחברות בקבוצות, לא ממטריצת ארבעה תפקידים. עמודת הגישה בקונסול מציגה את הצירופים האמיתיים. account_role נשאר ב-API לתאימות ולא משמש לתצוגה.

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

קבוצת מערכת	מדיניות מנוהלת	שימוש טיפוסי
`AccountOwners`	`SystemAccountOwners` (`Action: *`)	ניהול מלא של החשבון; פעולות קטלוג חדשות נכנסות אוטומטית
`AccountAdmins`	`SystemAccountAdmins` (`Action: *`)	חבילת מנהל; פעולות קטלוג חדשות נכנסות אוטומטית
`Builders`	`SystemBuilders`	בנייה / הפעלת עומסים (`service:*` כשהשירות ניתן במלואו)
`Readers`	`SystemReaders`	קריאה בלבד

שמות ו-ARN ישנים של ConsoleSystem* עדיין נפתרים אחרי שינוי השם. ה-* שמור בשורת גרסת המדיניות (זה מה שמנוע ההרשאות קורא). הקונסול לא ממיר רשימת פעולות ארוכה ל-* רק לתצוגה. פעולות קונסול ששמורות לבעלים (מחיקת חשבון, העברת בעלות) נשארות מאחורי תפקיד הבעלים.

קבוצות ומדיניות מותאמות חיים תחת IAM → Groups / Policies. הערכה: Deny > Allow > Deny מרומז. הענקה לאחרים דורשת CanDelegate: תת-קבוצה של פעולות קונקרטיות שאפשר לבצע. חבילות בעלים/מנהל שומרות Action: * לביצוע (פעולות קטלוג חדשות נכנסות אוטומטית). הכוכב הזה לא מאפשר למנהל להעניק * או so:* — רק בעלים (או מי שכבר מחזיק את ה-wildcard) יכול להעניק wildcards.

יוצרים משתמשים תחת IAM → משתמשים (הזמנה במייל או שם משתמש/סיסמה). הרשאות ביצירה אופציונליות — משתמש בלי שיוך מתחבר אבל אין לו גישה עד שמשיכים לו קבוצה או מדיניות. פתיחת משתמש מציגה קבוצות ומדיניות ישירה בטאבים. ה-breadcrumb מציג את שם המשתמש, לא את המזהה הפנימי. בכל טאב יש פעולת הוספה למעלה וטבלה של השיוכים הקיימים מתחתיה. החיפוש מסנן את הטבלה (וגם את רשימת ההוספה). לדיבאג השתמשו ב-IAM → אבחון: קודם הסימולטור, ואז כרטיסי גישה אפקטיבית לפי שירות.

פתיחת קבוצה מציגה טבלת חברים כמו IAM → משתמשים: שם, אימייל, גישה, סטטוס, ותפריט ⋮ (פתיחת המשתמש או הסרה מהקבוצה). בחירה מרובה והסרה מהקבוצה עובדים גם בקבוצות מותאמות וגם בחבילות מובנות. הסרה מ-Builders (או מכל חבילה) נשארת — הקונסול כבר לא מחזיר את המשתמש מ-account_role בבקשה הבאה.

Root של החשבון¶

ל-root יש גישה מלאה מובנית (אין צורך במסמך מדיניות). אין חובה לשים אותו בשום קבוצה.

פעולה	מותר?
השבתה, מחיקה או שינוי תפקיד	לא
צירוף או ניתוק מדיניות למשתמש	לא — `403 identity.root_permissions_immutable`
הוספה או הסרה מקבוצה	כן

דף המשתמש מסתיר צירוף/ניתוק ל-root. צירופים קיימים נשארים לקריאה בלבד.

הבילדר הוויזואלי צובר statements בין שירותים (לא מחליף את המסמך בהחלפת שירות). פתיחת מדיניות לא משנה אותה; מעבר Visual ↔ JSON לא יוצר מסמך חדש. הקונסול מקבץ לתצוגה לפי שירות גם כשמסמך אחד מכיל כמה שירותים. כרטיסי ההרשאות מסודרים ברשת של ארבעה בשורה; לחיצה בכל מקום על הכרטיס פותחת את הפרוסה.

יצירת מדיניות נפתחת כמגירה מלמטה. השם למעלה. הוסף מ־ הוא בחירה אחת (תבניות מנוהלות והמדיניות שלך); בחירה ממזגת את ה-statements למה שכבר הוספת — לא מחליפה עבודה ידנית ולא כופלת statement זהה. אותו אפקט + אותו משאב מאחד פעולות; אותו אפקט + אותן פעולות מאחד משאבים. זוגות פעולה/משאב שונים נשארים statements נפרדים כדי שהמיזוג לא ירחיב הרשאה (Get על דלי A ו-Put על דלי B לא הופכים ל-Get+Put על שניהם). Allow רחב (so:* על *) מעלים צר יותר. בחירת הכל לשירות (mq:*) מחליפה כל Allow אחר של אותו שירות. Deny לא מתמזג עם Allow. כפתור היצירה נשאר כבוי עד שיש שם ולפחות הרשאה אחת. ההרשאות שנבחרו נשארות ברשימת שירותים קומפקטית (תגיות כמו קריאה / כתיבה — לא כל פעולה). הרשימה גוללת לבד — לא את כל הגיליון. בטלפון הכרטיסים למטה עם גלילה הצידה. לחיצה על שירות פותחת את הפרוסה: אפקט, כמה שורות משאב, פעולות, ו־JSON של הפרוסה (Sid / Condition). הכל כותב {service}:* ומשבית את הצ'קבוקסים הבודדים; כיבוי מנקה אותם כדי לבחור פעולות ספציפיות. שדה המשאב הוא טקסט חופשי עם הצעות מהקטלוג תוך הקלדה (בלי #). עריכת statement מעורב מעדכנת רק את השירות הזה; שינוי משאב או אפקט מפצל אותו כדי לא לדרוס אחים.

קטלוג workspace¶

הקונסול מציג שירותים מ-GET /api/v1/accounts/{id}/catalog (קטלוג ששוחרר ∩ IAM). מוצרים שלא שוחררו מושמטים. שירות ששוחרר אבל לא הוענק נפתח כ-workspace ריק.

2. IAM של data-plane (אוטומציה)¶

אובייקט	מטרה
Policies	מסמכי `service:Action` + ARN (`Deny` גובר על `Allow`)
Roles	זהויות שניתן להניח (Functions משתמשות ב-Role ARN כ-`execution_role`)
Access Keys	אישורים ארוכי־חיים למשתמש; ההרשאות ממדיניות/קבוצות

מזהי חשבון ב-ARN הם מספר החשבון בן 12 ספרות.

Access Keys (credentials-first)¶

יצירה והחלפה תחת IAM → Users (המפתח שייך ליוזר). מלאי מנהל: IAM → Access Keys. מדריך מלא: Access Keys.

מפתחות משתמש יכולים לקרוא ל-APIs ניהוליים (רשימת buckets, תורים, …) ב-SigV1 כשהמדיניות Allow — בלי JWT של קונסול. homecloud login לדפדפן ול-step-up נדיר. ראו אימות CLI ו-ארכיטקטורת אימות.

Roles יכולים גם לסמוך על GitHub Actions OIDC. Terraform אז משתמש ב-HC_ROLE_ARN במקום מפתח ארוך־חיים. ראו Terraform — GitHub OIDC.

מדיניות¶

פתחו Policies → צרו או שכפלו starter מנוהל.
צרפו את המדיניות למשתמש, קבוצה או Role.

Roles ו-Functions¶

Functions חייבות להשתמש ב-Role ARN (לא בשם Access Key).

אבחון¶

פתחו IAM → אבחון.

סימולטור (למעלה) — האם service:Action מותר על ARN בלי לבצע את הפעולה.
גישה אפקטיבית (מתחת) — כרטיסים לפי שירות עם תגיות קריאה / כתיבה / יצירה. לחיצה על תג או +N מציגה את שמות הפעולות המדויקות.

הסימולטור עונה על השאלה שבשמה הגעתם. הכרטיסים מסכמים מה משויך אחרי ש-Deny גובר.