הרשאה ובקרת גישה

בעזרת ניהול זהויות והרשאות גישה (IAM) ב-Google Distributed Cloud (GDC)‎ עם air gap, אתם יכולים לקבוע למי תהיה גישה למשאבים מסוימים ואילו פעולות אפשר לבצע במשאבים האלה.

כדי לנהל את הגישה בצורה יעילה, חשוב להבין איך IAM פועל ב-GDC. כך תוכלו לוודא שלחברים יש את ההרשאות שהם צריכים כדי לבצע את התפקידים שלהם, תוך שמירה על האבטחה של הסביבה עם ה-air gap.

המסמך הזה מיועד למנהלי פלטפורמות ולאופרטורים של אפליקציות (כמו אדמינים ממחלקת IT, מהנדסי אבטחה או מפתחי אפליקציות) שרוצים להבין את ההרשאות ואת בקרת הגישה ב-GDC עם air gap. המסמך הזה גם עוזר למפעילי תשתיות להבין את המושגים הבסיסיים של בקרת גישה. מידע נוסף זמין במאמר קהלים למסמכי תיעוד של GDC עם air gap.

מודל בקרת הגישה

ב-GDC, הגישה מבוססת על שלושה רכיבים עיקריים: חברים (מי), תפקידים (מה) והיקף המשאבים (איפה).

מודל בקרת הגישה

בקרת הגישה מורכבת משני שלבים נפרדים – הוכחת הזהות (אימות) וקביעת הפעולות שאפשר לבצע (הרשאה):

  • אימות: ב-GDC לא מאוחסנים חשבונות משתמשים או סיסמאות. ‫GDC מתחבר לספק הזהויות (IdP) של הארגון, כדי שתוכלו להיכנס באמצעות פרטי הכניסה של הארגון.
  • הרשאה: אחרי האימות, מערכת IAM של GDC בודקת את התפקידים שהוקצו לכם כדי לקבוע לאילו משאבים אתם יכולים לגשת ואילו פעולות אתם יכולים לבצע.

חברים

חבר הוא זהות שאפשר להעניק לה גישה למשאב. ב-GDC, חברי הקבוצה מחולקים לשתי קטגוריות עיקריות, בהתאם למקום שבו אתם מנהלים אותם: זהויות אנושיות וזהויות לא אנושיות.

זהויות אנושיות

זהויות אנושיות הן המשתמשים והקבוצות שנכנסים ל-GDC. במקום לאחסן חשבונות משתמשים או סיסמאות, GDC מתחבר למערכות ההתחברות הקיימות של הארגון או לספקי זהויות (כמו Active Directory,‏ LDAP או Okta) באמצעות פרוטוקולים סטנדרטיים של איחוד שירותי אימות הזהות, כמו OpenID Connect ‏(OIDC) או SAML 2.0.

יש שני סוגים של זהויות אנושיות:

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

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

כשמנהלים את הגישה, GDC מוסיף באופן אוטומטי קידומת ייחודית של IdP לכל שמות המשתמשים והקבוצות החיצוניים:

  • פורמט: idpprefix-username@domain.com (או idpprefix-group-name לקבוצות).
  • דוגמה: אם ה-IdP של הארגון מוגדר עם הקידומת agency-a, ואתם נכנסים בתור alice@example.com,‏ GDC IAM מזהה אתכם בתור agency-a-alice@example.com.

זהויות לא אנושיות

זהויות לא אנושיות נקראות זהויות שירות (או חשבונות שירות). אתם יוצרים ומנהלים אותם ישירות ב-GDC (כמשאבי ProjectServiceAccount) כדי לאפשר לאפליקציות, לסקריפטים או לעומסי עבודה אוטומטיים לקיים אינטראקציה עם ממשקי API בצורה מאובטחת.

חשבונות שירות מנוהלים באופן פנימי על ידי GDC, ולכן הם לא משתמשים בתחיליות של ספקי זהויות. במקום זאת, הם מזוהים לפי הפרויקט והשם שלהם (לדוגמה, serviceAccount:projectName:serviceAccountName כשמשתמשים ב-gdcloud CLI).

למידע נוסף, קראו את המאמר אבטחת מפתחות של חשבונות שירות.

הרשאות ותפקידים

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

ב-GDC יש שני סוגים של תפקידים:

  • תפקידים מוגדרים מראש: חבילות מובנות של הרשאות שנוצרו ומנוהלות על ידי GDC. ב-GDC יש ספרייה מקיפה של תפקידים מוגדרים מראש שמותאמים לתפקידים ולשירותים ספציפיים (החל מתפקידים רחבים כמו "צפייה בפרויקט" ועד לתפקידי שירות פרטניים כמו "אדמין של פרויקט קטגוריה" או "צפייה ב-KMS").
  • תפקידים בהתאמה אישית: חבילות של הרשאות שמוגדרות על ידי המשתמשים, שאפשר ליצור כשהתפקידים הקיימים שהוגדרו מראש לא עונים על הצרכים של הארגון.

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

היקף המשאבים

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

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

  • ארגון: הקונטיינר ברמה העליונה של הסביבה. תפקידים שמוקצים ברמת הארגון חלים על כל הארגון, ועוברים בירושה באופן אוטומטי לכל הפרויקטים והמשאבים שבו.
  • פרויקט: קונטיינר בתוך הארגון שמשמש לקיבוץ משאבים של צוותים או אפליקציות ספציפיים. הפרויקטים משמשים כגבולות אבטחה נוקשים – תפקידים שמוקצים ברמת הפרויקט חלים רק על הפרויקט הספציפי הזה ועל המשאבים שלו (כמו מכונות וירטואליות, מסדי נתונים ואשכולות Kubernetes).

למידע נוסף, ראו היררכיית המשאבים ובקרת הרשאות ליקום עם כמה אזורים.

איך מאשרים גישה

ב-GDC, הגישה מנוהלת ומאושרת בעיקר באמצעות מודל של בקרת גישה מבוססת-תפקידים (RBAC). במודל RBAC, לא מקצים הרשאות ישירות למשתמשים או לעומסי עבודה ספציפיים. במקום זאת, אתם מקצים תפקידים לחברים בהיקף משאבים ספציפי כדי לקבוע את הגישה.

ב-GDC, בקרת הגישה מבוססת התפקידים מיושמת באמצעות המשאבים הבאים בהתאמה אישית של Kubernetes:

  • ‫IAMRole: מגדיר חבילה ספציפית של הרשאות.
  • ‫IAMRoleBinding: מקשר חבר (משתמש אנושי, קבוצה או חשבון שירות) ל-IAMRole בהיקף של ארגון או פרויקט.

כדי לתת גישה למשאבים של הארגון או הפרויקט, אתם יכולים ליצור IAMRoleBinding באמצעות מסוף GDC,‏ gdcloud CLI או על ידי החלת מניפסטים של משאבים בהתאמה אישית (קובצי YAML) באמצעות kubectl CLI.

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

מסוף GDC וה-gdcloud CLI מתחברים למשאבים באופן אוטומטי, אבל כדי לגשת ישירות ל-API באמצעות ה-kubectl CLI צריך לאמת את אשכול Kubernetes הספציפי או את שרת ה-API שמארח את המשאב הזה, על ידי יצירת קובץ kubeconfig. לפרטים, ראו כניסה ויצירה של קובץ kubeconfig.

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

ההבדלים בין IAM ב-GDC עם air gap לבין Google Cloud

אם יש לכם ניסיון בניהול גישה ב- Google Cloud, ב-GDC משתמשים במושגים דומים אבל מיישמים אותם בצורה שונה כדי לפעול בתשתית מבוססת-Kubernetes עם air gap.

בטבלה הבאה מוצגת השוואה בין IAM ב-GDC לבין Google Cloud:

תכונה תיאור GDC עם air gap Google Cloud
זהות המשתמש (אימות) מערכת זהויות שמשמשת לאימות משתמשים אנושיים. מאוחד עם ה-IdP החיצוני באמצעות הקידומות הנדרשות של ה-IdP (לדוגמה, idpprefix-user@domain.com). חשבונות Google (כמו Gmail) או זהויות ארגוניות מאוחדות באמצעות Cloud Identity או Google Workspace.
מנוע הרשאות המערכת הבסיסית שמעריכה ואוכפת את ההרשאות. בעיקר בקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes, שבה בקשות הגישה נבדקות באופן מקומי על ידי שרת ה-API בהשוואה לקישורי התפקידים. אתם יכולים להשתמש במדיניות הארגון כדי להגדיר הגבלות על משאבים. שירות Cloud IAM הגלובלי של Google. הערכה של בקשות API באופן מרוכז, בהתאם למדיניות הגישה שמצורפת בכל רמה בהיררכיית המשאבים.
קישורי תפקידים איך החברים ממופים לתפקידים במשאבים ספציפיים. ‫IAMRoleBinding משאבים בהתאמה אישית. כל קישור הוא אובייקט שמקשר בין חברים לתפקיד אחד. ההרשאות של תפקידי IAM הן מצטברות בלבד (אפשר להגדיר כללי דחייה בנפרד באמצעות מדיניות הארגון). מדיניות גישה אחת של IAM שמצורפת לכל משאב, תיקייה או ארגון. מכילה כמה קישורים שממפים חברים לתפקידים, ותומכת בכללים מותנים או בכללי דחייה.
חשבונות שירות זהויות לא אנושיות שמשמשות אפליקציות ועומסי עבודה אוטומטיים. חשבונות שירות מקומיים שנוצרו בתוך פרויקט ספציפי (ProjectServiceAccount). המפתחות הציבוריים מאוחסנים באשכול, והמפתחות הפרטיים מנוהלים ומאובטחים באופן מקומי על ידי הלקוח. זהויות גלובליות שמנוהלות באופן מרכזי על ידי Google. ‫Google יכולה לנהל את פרטי הכניסה באופן אוטומטי, או שאפשר להוריד אותם כקובצי מפתחות כדי לבצע אימות מכל מקום.
היררכיית המשאבים מבנה של קונטיינר שמשמש לארגון משאבים ולקבלת הרשאות בירושה. היררכיה דו-שלבית: ארגון > פרויקטים היררכיה רב-שכבתית: ארגון > תיקיות > פרויקטים
היקף ההרשאות בכמה אזורים איך ההרשאות נבדקות ומופצות בין אזורי זמינות או אזורים. משתמש ב-Kubernetes RBAC שמנוהל על ידי שרת API גלובלי, שמתאם ומשכפל קישורי תפקידים בין שרתי API אזוריים, כך שהגישה חלה על כל האזורים כברירת מחדל. שימוש בשירות IAM גלובלי שמנוהל באופן מלא. הרשאות שמוקצות בכל רמת משאב הן גלובליות באופן טבעי, והן חלות באופן אוטומטי על כל האזורים והתחומים.
כלי לקוח ממשקים ראשיים, כלי CLI וממשקי API שמשמשים לניהול הגישה. מסוף GDC, ‏gdcloud CLI וממשקי API של KRM. Google Cloud , ה-CLI של gcloud וממשקי ה-API ל-REST או ל-gRPC.
גישה ישירה ל-API איך כלים וסקריפטים מבצעים אימות כדי לנהל משאבים ישירות באמצעות ממשקי API. כדי לגשת ישירות ל-API באמצעות ה-CLI של kubectl, צריך לבצע אימות מול אשכול Kubernetes הספציפי או מול שרת ה-API שמארח את המשאב הזה, על ידי יצירת קובץ kubeconfig. (מסוף GDC ו-gdcloud CLI מתחברים למשאבים באופן אוטומטי). גישה ישירה ל-API באמצעות נקודות קצה של gcloud או REST/gRPC משתמשת בפרטי כניסה מרכזיים (gcloud auth login) שחלים באופן גלובלי על כל השירותים, בלי צורך בכניסה ספציפית לאשכול.

המאמרים הבאים