במאמר הזה מתואר איך להגדיר הרשאות לניהול זהויות והרשאות גישה (IAM) במספר תרחישי חיוב לדוגמה. מפורטות כאן הנחיות בנושא תפקידי ה-IAM שאפשר להקצות לעובדים בחברה שעוסקים בחיוב בתרחישים האלה. הדוגמאות האלה מיועדות בעיקר למנהלים ולעובדים שמנהלים בארגון משימות בענייני חיוב.
במסמך הזה לא ניתן הסבר מפורט על התפקידים הקשורים לחיוב ועל ההרשאות לחיוב. תיאור מפורט של התפקידים וההרשאות ב-Billing API אפשר לקרוא בדף בקרת גישה לחיוב.
חברה קטנה שמגדירה הרשאות חיוב
בתרחיש הזה, חברה קטנה מנסה להגדיר חשבונות לחיובGoogle Cloud ולהשתמש בהם. בחברה עובדים מספר מהנדסי תוכנה שמפתחים את האפליקציות שלהם ומתחזקים אותן, אבל אף אחד מהם לא מנהל את החיוב שלהן. יש להם מנהל משרד שאחראי על התאמת התשלומים לחשבוניות, אבל מסיבות של תאימות, מנהל המשרד לא מורשה לקבל גישה למשאבים של Google Cloud בפרויקטים. המנכ"ל מחזיק בפרטי כרטיס האשראי וגם מנהל אותם.
בטבלה הבאה מוסברים תפקידי ה-IAM לענייני חיוב שאותם האדמין הארגוני (המנכ"ל בתרחיש הזה) יכול להקצות לעובדים אחרים בחברה, ורמת המשאב שבה מוקצים התפקידים.
| תפקיד: | אדמין ארגוני | התפקיד 'אדמין ארגוני' מאפשר למנכ"ל להקצות הרשאות למנהל המשרד. |
|---|---|---|
| משאב: | ארגון | |
| חשבון משתמש: | מנכ"ל |
| תפקיד: | אדמין של חשבון לחיוב | תפקיד האדמין של חשבון לחיוב מאפשר למנהל המשרד ולמנכ"ל לנהל תשלומים וחשבוניות בלי שקיבלו הרשאה לצפות בתוכן של הפרויקטים. |
|---|---|---|
| משאב: | ארגון | |
| חשבונות משתמשים: | מנהל המשרד, מנכ"ל |
מדיניות ההרשאה שמצורפת למשאב הארגון בתרחיש הזה אמורה להיראות כך:
{
"bindings": [
{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"user:ceo@example.com"
]
},
{
"role": "roles/billing.admin",
"members": [
"group:finance-admins-group@example.com"
]
}
]
}
השיטה המומלצת היא להשתמש בקבוצות כדי לנהל חשבונות משתמשים. בדוגמה למעלה, בקישור השני, אפשר להוסיף את המנכ"ל ואת מנהל המשרד לקבוצה finance-admins-group. כשצריך לשנות את העובדים שיוכלו לבצע את
הפעולה, פשוט משנים את חברי הקבוצה ללא צורך
בעדכון מדיניות ההרשאה. כך, שני חשבונות נפרדים של משתמשים לא מופיעים בקישורי התפקידים.
צוותי הכספים שמנהלים תקציבים
בתרחיש כזה, ארגון גדול רוצה שצוות הכספים בכל מחלקה יוכל להגדיר תקציבים ולצפות בהוצאות של הצוות במחלקה, אבל שלא תהיה לו גישה ל Google Cloud משאבים. לארגון לא חשוב אם המפתחים יראו את ההוצאות בפרויקטים שהם אחראים עליהם, אבל הם לא צריכים לקבל תמונה מלאה של ההוצאות בארגון.
מקצים את התפקידים שמופיעים בטבלה הבאה למנהל הכספים של כל מחלקה ולמפתחים:
| תפקיד: | אדמין של חשבון לחיוב | התפקיד הזה נותן למנהל הפיננסי של כל מחלקה את ההרשאה להגדיר תקציבים ולצפות בהוצאות של החשבונות לחיוב במחלקות שלהם, אבל לא נותן להם הרשאות לצפות בתוכן של הפרויקטים. |
|---|---|---|
| משאב: | חשבון לחיוב | |
| חשבונות משתמשים: | מנהל הכספים של כל מחלקה |
| תפקיד: | צפייה בחשבון לחיוב | התפקיד 'צפייה בחשבון לחיוב' מאפשר למפתחים לצפות בהוצאות של חשבון לחיוב. |
|---|---|---|
| משאב: | חשבון לחיוב | |
| חשבונות משתמשים: | המפתחים של הפרויקט |
בתרחיש הזה, משתמשים במסוף החיוב כדי להקצות את התפקיד 'אדמין של חשבון לחיוב' למנהלי הכספים בחשבון לחיוב. בנוסף, מקצים למפתחים בחשבון לחיוב את התפקיד 'צפייה בחשבון לחיוב'.
לאחר ביצוע ההקצאות, מדיניות ההרשאה של החשבון לחיוב אמורה להיראות כך:
{
"bindings": [
{
"role": "roles/billing.admin",
"members": [
"group:finance-admins-group@example.com"
]
},
{
"role": "roles/billing.viewer",
"members": [
"group:developers@example.com"
]
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
פורטל שירות עצמי של לקוח, מפתחים לא יכולים לשנות חיובים
בתרחיש הזה, צוות ה-IT המרכזי של הלקוח מספק Google Cloud למפתחים את המשאבים כחלק מפורטל השירות העצמי שלהם. המפתחים מבקשים גישה לפרויקטים ולשירותי ענן מאושרים אחרים דרך הפורטל. Google Cloud מרכז העלויות של המפתח משלם לצוות ה-IT המרכזי על משאבי הענן שנעשה בהם שימוש.
צריך שצוות ה-IT המרכזי יוכל:
- לשייך פרויקטים לחשבונות לחיוב.
- להשבית את החיוב לפרויקטים.
- לצפות בפרטי כרטיס האשראי.
אסור שיהיו לו הרשאות צפייה בתוכן הפרויקטים.
צריך שהמפתחים יוכלו לראות את העלויות בפועל של משאבי Google Cloud שנעשה בהם שימוש, אבל שלא יוכלו להשבית את החיוב, לשייך את החיוב לפרויקטים ולצפות בפרטי כרטיס האשראי.
| תפקיד: | אדמין של חשבון לחיוב | התפקיד 'אדמין של חשבון לחיוב' מקצה למחלקת
ה-IT את ההרשאות לשייך פרויקטים לחשבונות לחיוב,
להשבית את החיוב בפרויקטים ולצפות בפרטי כרטיס האשראי
של החשבונות שהם מפיצים ללקוחות שלהם.
הם לא מקבלים הרשאות לצפייה בתוכן של הפרויקטים. |
|---|---|---|
| משאב: | חשבון לחיוב | |
| חשבון משתמש: | מחלקת IT |
| תפקיד: | משתמש בחשבון לחיוב | התפקיד 'משתמש בחשבון לחיוב' נותן לחשבון השירות את ההרשאות להפעלת חיוב (שיוך פרויקטים לחשבון לחיוב של הארגון בכל הפרויקטים של הארגון), ובכך מאפשר לחשבון השירות להפעיל ממשקי API שדורשים הפעלת חיוב. |
|---|---|---|
| משאב: | ארגון | |
| חשבון משתמש: | חשבון שירות שמשמש לאוטומציה של יצירת פרויקטים. |
| תפקיד: | צפייה בחשבון לחיוב | התפקיד 'צפייה בחשבון לחיוב' מאפשר למפתחים לצפות בהוצאות של חשבון לחיוב. |
|---|---|---|
| משאב: | חשבון לחיוב | |
| חשבונות משתמשים: | המפתחים של הפרויקט |
בתרחיש הזה צריך לבצע שתי פעולות נפרדות כדי להקצות את כללי מדיניות ההרשאה המתאימים, כי הם מצורפים ברמות שונות של ההיררכיה.
משתמשים במסוף החיוב כדי להקצות את התפקיד 'אדמין של חשבון לחיוב' למחלקת ה-IT בחשבון לחיוב. בנוסף, מקצים למפתחים בחשבון לחיוב את התפקיד 'צפייה בחשבון לחיוב'.
לאחר מכן צריך לצרף מדיניות הרשאה ברמת הארגון. מדיניות ההרשאה הזו מקצה לחשבון השירות את התפקיד 'משתמש בחשבון לחיוב'. היא אמורה להיראות כך:
{
"bindings": [
{
"role": "roles/billing.user",
"members": [
"serviceAccount:my-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
}
],
"etag": "BwWKmjvelug=",
"version": 1
}
מפתחים שיוצרים פרויקטים לחיוב
חברה דיגיטלית גדולה רוצה לאפשר לכל המפתחים שלה ליצור פרויקטים לחיוב בחשבון לחיוב של הארגון, בלי לתת להם הרשאות של 'אדמין של חשבון לחיוב'.
כדי לוודא שאפשר להפעיל את ממשקי ה-API מחוץ למצב ברירת המחדל, צריך להפעיל את החיוב בפרויקט. לכן כשמפתחים יוצרים פרויקט, הם צריכים לשייך אותו לחשבון לחיוב כדי להפעיל את ממשקי ה-API.
| תפקיד: | משתמש בחשבון לחיוב | התפקיד 'משתמש בחשבון לחיוב' מאפשר למפתחים לצרף את החשבון לחיוב לפרויקטים חדשים בארגון. |
|---|---|---|
| משאב: | ארגון | |
| חשבונות משתמשים: | מפתחים |
צריך לצרף את מדיניות ההרשאה לתרחיש הזה ברמת הארגון, והיא אמורה להיראות כך:
{
"bindings": [
{
"role": "roles/billing.user",
"members": [
"group:developers@example.com"
]
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
צבירת נתוני עלויות
בתרחיש הזה, חברה רוצה לחשב את העלויות של כל צוות, מחלקה, שירות או פרויקט ולעקוב אחריהן. לדוגמה, לעקוב אחרי העלות של פריסת בדיקה בכל חודש.
אפשר לעקוב אחרי זה באמצעות השיטות הבאות:
- שימוש בפרויקטים לארגון משאבים. העלות מוצגת לכל פרויקט ומזהי הפרויקטים כלולים בייצוא החיובים.
- מוסיפים הערות לפרויקטים עם תוויות שמייצגות מידע נוסף
שמקובץ. לדוגמה,
environment=test. התוויות נכללות בייצוא החיובים כדי לאפשר לכם לנתח את הנתונים עוד יותר. עם זאת, התוויות בפרויקט מקבלות אותן הרשאות כמו שאר המטא-נתונים של הפרויקט, מה שאומר שהבעלים של הפרויקט יכול לשנות אותן. אפשר להנחות את העובדים שלא לשנות דברים מסוימים ולאחר מכן לעקוב (באמצעות יומני הביקורת) או להקצות להם רק הרשאות מפורטות, כדי שהם לא יוכלו לשנות את המטא-נתונים של הפרויקט.
אפשר לייצא ל-JSON ול-CSV, אבל הפתרון המומלץ הוא לייצא ישירות ל-BigQuery. אפשר להגדיר זאת בקלות בקטע של ייצוא החיוב במסוף החיוב.
אם כל מרכז עלויות יצטרך לשלם חשבונית נפרדת או לשלם במטבע נפרד על עומסי עבודה מסוימים, צריך שיהיה חשבון נפרד לחיוב בכל מרכז עלויות. עם זאת, בגישה הזו צריך הסכם שותף עצמאי חתום לכל חשבון לחיוב.