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

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

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

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

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

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

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

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

חברים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

היקף המשאבים

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

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

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

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

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

‫GDC מטמיע RBAC באמצעות המשאבים המותאמים אישית הבאים של Kubernetes:

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

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

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

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

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

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

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

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

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

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