היררכיית המשאבים ב- Google Cloud מספקת דרך מובנית לארגון משאבי הענן. לכל המשאבים, מלבד המשאב ברמה הגבוהה ביותר בהיררכיה, יש בדיוק הורה אחד. ההיררכיה מורכבת מהארגון (root) בחלק העליון, ואחריו תיקיות (אופציונלי) לקיבוץ, ואז פרויקטים, שמכילים את משאבי השירות בפועל, כמו מכונות וירטואליות של Compute Engine וקטגוריות אחסון.
היתרונות של שימוש בהיררכיה מובנית:
- בעלות: קושרת את מחזור החיים של משאב להורה הישיר שלו. הפרויקטים שייכים לארגון, ולא לעובד שיצר אותם. אם עובד עוזב את החברה, הפרויקט נשאר פעיל ומאובטח.
- ירושה: היררכיית המשאבים מספקת נקודות חיבור לבקרת גישה ולמדיניות הארגון, שמועברות לאורך ההיררכיה. אפשר להקצות תפקידים ברמה גבוהה (כמו הארגון או תיקייה). כל משאבי הצאצא יורשים את התפקידים האלה, כך שלא צריך להגדיר ידנית הרשאות לכל פרויקט בנפרד.
בתרשים הבא מוצגת היררכיית המשאבים של Google Cloud .
משאב הארגון
משאב הארגון מייצג ישות (למשל חברה) ומשמש כצומת הבסיסי (root) בהיררכיית המשאבים שלGoogle Cloud . הוא מספק את הפונקציות העיקריות הבאות:
- הארגון משמש כהורה לכל משאבי התיקיות והפרויקטים.
- כללי מדיניות של בקרת גישה (כמו תפקידים בניהול הזהויות והרשאות הגישה (IAM)) ומדיניות ארגונית שמוחלים ברמה הזו עוברים בירושה לכל משאב בארגון.
- משאב Organization לא נדרש לכל המשתמשים ב- Google Cloud , אבל הוא נחוץ כדי להשתמש בתכונות מסוימות של מנהל המשאבים.
שיוך לחשבונות Google Workspace או Cloud Identity
כדי לקבל גישה למשאב הארגון, צריך חשבון Google Workspace או Cloud Identity.
- כל חשבון של Google Workspace או של Cloud Identity יכול להיות משויך למשאב ארגון אחד בלבד.
- כשמשתמש עם חשבון Google Workspace או חשבון Cloud Identity יוצר משאב פרויקט, מוקצה לו באופן אוטומטי משאב ארגון. Google Cloud
בתמונה הבאה מוצג הקשר בין חשבון Google Workspace, Cloud Identity והיררכיית המשאבים. Google Cloud
הסופר-אדמין ב-Google Workspace הוא האדם שאחראי על אימות הבעלות על הדומיין ועל הקשר במקרה של שחזור. לכן, כברירת מחדל, לסופר-אדמין ב-Google Workspace יש אפשרות להקצות תפקידי IAM. התפקיד העיקרי של סופר-אדמין ב-Google Workspace בנוגע ל- Google Cloud הוא להקצות את תפקיד האדמין הארגוני ב-IAM למשתמשים המתאימים בדומיין. כך תיצור הפרדה בין Google Workspace לבין אחריות הניהול שהמשתמשים בדרך כלל מחפשים. Google Cloud
כללים ליצירת פרויקטים למשתמשים מנוהלים
אחרי שיוצרים משאב ארגון לדומיין, חלים כללים מחמירים על יצירת פרויקטים:
- משתמשים מנוהלים (חברים בדומיין של החשבון) צריכים ליצור פרויקטים בארגון. בחשבונות שמשויכים למשאב ארגון, אי אפשר ליצור משאבי פרויקט שלא משויכים למשאב ארגון.
- כברירת מחדל, פרויקטים חדשים שייכים לארגון שאליו משויך המשתמש.
- אם למשתמש יש את ההרשאות המתאימות, הוא יכול לציין משאב ארגוני אחר במהלך יצירת הפרויקט. אחרת, ברירת המחדל היא הארגון הביתי שלו.
היתרונות של משאב הארגון
כשמשתמשים במשאב ארגוני, המשאבים של הפרויקט שייכים לארגון, ולא לעובד שיצר אותם. כלומר, הארגון שלכם שומר על משאבי הפרויקט כשעובד עוזב את החברה. מחזור החיים של משאבי הפרויקט ב- Google Cloudזהה לזה של משאב הארגון.
בנוסף, אדמינים של הארגון שולטים בכל המשאבים באופן מרכזי. הם יכולים לראות ולנהל את כל משאבי הפרויקט בחברה שלכם. כך נמנעים פרויקטים לא רשמיים או אדמינים לא מורשים.
אפשר גם להעניק תפקידים ברמת הארגון, שכל המשאבים של הפרויקטים והתיקיות שמתחת למשאב הארגון יורשים. לדוגמה, אתם יכולים להקצות לצוות הרשת את התפקיד אדמין רשת ברמת הארגון, וכך לאפשר לו לנהל את כל הרשתות בכל משאבי הפרויקט בחברה, במקום להקצות את התפקיד לכל משאב פרויקט בנפרד.
משאב ארגוני מוגדר על ידי המאפיינים הבאים:
- מזהה משאב של ארגון, שהוא מזהה ייחודי של ארגון.
- שם לתצוגה, שנוצר משם הדומיין הראשי ב-Google Workspace או ב-Cloud Identity.
- השעה שבה נוצר המשאב הארגוני.
- הזמן שבו בוצע השינוי האחרון במשאב הארגון.
- הבעלים של משאב הארגון, שהוא מזהה הלקוח ב-Google Workspace מתוך Directory API. אתם מציינים את הבעלים כשאתם יוצרים את משאב הארגון, ואי אפשר לשנות אותו.
בקטע הקוד הבא מוצג המבנה של משאב ארגון:
{
"creationTime": "2020-01-07T21:59:43.314Z",
"displayName": "my-organization",
"lifecycleState": "ACTIVE",
"name": "organizations/34739118321",
"owner": {
"directoryCustomerId": "C012ba234"
}
}
מדיניות ההרשאות הראשונית למשאב ארגוני חדש מעניקה את התפקידים 'Project Creator' ו-'Billing Account Creator' לכל הדומיין של Google Workspace. כלומר, המשתמשים יכולים להמשיך ליצור משאבי פרויקט וחשבונות לחיוב כמו לפני שהיה משאב ארגוני. לא נוצרים משאבים אחרים כשיוצרים משאב ארגוני. מדיניות הרשאות, מדיניות דחייה ומדיניות ארגון עוברות בירושה בהיררכיה. המדיניות שחלה בפועל על כל משאב בהיררכיה היא תוצאה של המדיניות שחלה ישירות על המשאב ושל המדיניות שעוברת בירושה מישויות האב שלו.
משאב התיקייה
משאבי תיקיות הם מנגנון קיבוץ אופציונלי בין משאבי ארגון למשאבי פרויקט. כדי להשתמש בתיקיות, צריך משאב מסוג Organization. משאבי התיקיות ומשאבי הפרויקטים שהם צאצאים שלהם נמצאים תחת משאב הארגון.
משאבי תיקיות יכולים לספק גבולות הפרדה בין פרויקטים. הם פועלים כארגוני משנה בתוך משאב הארגון. אפשר להשתמש במשאבי תיקיות כדי להגדיר ישויות משפטיות, מחלקות וצוותים שונים בתוך החברה. לדוגמה, רמה ראשונה של תיקיות יכולה לייצג את המחלקות הראשיות בארגון שלכם. מכיוון שתיקיות יכולות להכיל פרויקטים ותיקיות אחרות, כל תיקייה יכולה לכלול תיקיות משנה שמייצגות צוותים שונים. כל תיקיית צוות יכולה להכיל תיקיות משנה נוספות שמייצגות אפליקציות שונות. איך יוצרים תיקיות?
אם למשאב הארגון יש משאבי תיקיות ויש לכם הרשאות צפייה מתאימות, תוכלו לראות אותם במסוף Google Cloud . הוראות מפורטות נוספות זמינות במאמר הצגה, עדכון ומחיקה של תיקיות.
משאבי התיקיות מאפשרים להעניק הרשאות ניהול. לדוגמה, אתם יכולים להעניק לכל ראש מחלקה בעלות מלאה על כל Google Cloud המשאבים במחלקה שלו. באופן דומה, משאבי תיקיות יכולים להגביל את הגישה למשאבים, מה שאומר שמשתמשים במחלקה אחת יכולים לגשת למשאבים וליצור אותם רק בתוך משאב התיקייה הזה. Google Cloud
בקטע הקוד הבא מוצג המבנה של משאב תיקייה:
{
"createTime": "2030-01-07T21:59:43.314Z",
"displayName": "Engineering",
"lifecycleState": "ACTIVE",
"name": "folders/634792535758",
"parent": "organizations/34739118321"
}
בדומה למשאבי ארגון ופרויקט, משאבי תיקייה משמשים כנקודת העברה בירושה של מדיניות הרשאות, דחייה ומדיניות ארגונית. תפקידי IAM שניתנים למשאב תיקייה עוברים בירושה לכל משאבי הפרויקט והתיקייה בתיקייה הזו.
משאב הפרויקט
משאב הפרויקט הוא הישות המארגנת הבסיסית. משאבי ארגון ותיקייה יכולים להכיל כמה פרויקטים. כדי להשתמש ב- Google Cloud, צריך משאב מסוג פרויקט. הוא חיוני ליצירה, להפעלה ולשימוש של כל שירותיGoogle Cloud , וגם לניהול ממשקי API, להפעלת החיוב, לניהול ההרשאות, להוספת שותפי עריכה ולהסרה שלהם.
כל משאבי הפרויקט כוללים את הרכיבים הבאים:
- שני מזהים:
- מזהה משאב הפרויקט, שהוא מזהה ייחודי של משאב הפרויקט.
- מספר משאב הפרויקט, שמוקצה באופן אוטומטי כשיוצרים את הפרויקט. הוא לקריאה בלבד.
- שם תצוגה אחד שניתן לשינוי.
- מצב מחזור החיים של משאב הפרויקט, למשל ACTIVE או DELETE_REQUESTED.
- אוסף של תוויות שאפשר להשתמש בהן לסינון פרויקטים.
- השעה שבה נוצר משאב הפרויקט.
בקטע הקוד הבא מוצג המבנה של משאב פרויקט:
{
"createTime": "2020-01-07T21:59:43.314Z",
"lifecycleState": "ACTIVE",
"name": "my-project",
"parent": {
"id": "634792535758",
"type": "folder"
},
"projectId": "my-project",
"labels": {
"my-label": "prod"
},
"projectNumber": "464036093014"
}
כדי ליצור אינטראקציה עם רוב Google Cloud המשאבים, צריך לספק את מזהי משאבי הפרויקט בכל בקשה. יש שתי דרכים לזהות משאב בפרויקט: לפי מזהה המשאב בפרויקט או לפי מספר המשאב בפרויקט. בקטע הקוד, אלה הערכים projectId ו-projectNumber.
מזהה משאב של פרויקט הוא השם המותאם אישית שבוחרים כשיוצרים פרויקט. אם מפעילים API שנדרש לו פרויקט, אפשר ליצור פרויקט חדש או לבחור פרויקט קיים באמצעות מזהה משאב הפרויקט. מחרוזת name שמופיעה בממשק המשתמש, אבל היא לא זהה למזהה משאב הפרויקט.
Google Cloud נוצר באופן אוטומטי מספר משאב של הפרויקט. אפשר לראות את מזהה משאב הפרויקט ואת מספר הפרויקט בלוח הבקרה של הפרויקט במסוףGoogle Cloud . מידע על קבלת מזהים של פרויקטים ומשימות ניהול אחרות של משאבי פרויקט זמין במאמר יצירת פרויקטים.
מדיניות ה-IAM הראשונית של משאב הפרויקט שנוצר לאחרונה מעניקה את תפקיד הבעלים ליוצר הפרויקט.
כל המשתמשים, כולל משתמשים בגרסת ניסיון בחינם, משתמשים בתוכנית חינמית ולקוחות של Google Workspace ו-Cloud Identity, יכולים ליצור משאבי פרויקט. משתמשים בGoogle Cloud תוכנית החינמית יכולים ליצור רק משאבי פרויקט ומשאבי שירות בתוך פרויקטים. משאבי פרויקט יכולים להיות בראש ההיררכיה, אבל רק אם הם נוצרו על ידי משתמשים בתקופת ניסיון בחינם או משתמשים בתוכנית חינמית. ללקוחות Google Workspace ו-Cloud Identity יש גישה לתכונות נוספות של Google Cloud היררכיית המשאבים, כמו משאבי ארגון ותיקיות. מידע נוסף זמין בסקירה הכללית על Cloud Identity. למשאבי פרויקט שנמצאים בראש ההיררכיה שלהם אין משאבי הורה, אבל אפשר להעביר אותם למשאב Organization אחרי שהוא נוצר לדומיין. פרטים נוספים על העברת משאבי פרויקט זמינים במאמר העברת פרויקטים בין משאבי ארגון.