הדף הזה מיועד לאדמינים ולמפעילים של פלטפורמות ולמהנדסי אבטחה שרוצים לצמצם את הסיכונים שקשורים לזהות זהה בציים.
לפני שקוראים את הדף הזה, חשוב להכיר את המושגים שמוסברים במאמר מידע על Fleet איחוד זהויות של עומסי עבודה.
הסברים על המונחים
בדף הזה נעשה שימוש במינוחים הבאים:
- איחוד זהויות של עומסי עבודה ל-GKE: תכונה שמספקת זהויות לעומסי עבודה ב-GKE בפרויקט Google Cloud יחיד.
- איחוד זהויות של עומסי עבודה ב-Fleet: תכונה שמרחיבה את איחוד הזהויות של עומסי עבודה ל-GKE לעומסי עבודה בכל ה-Fleet, כולל מחוץ ל- Google Cloudובכמה פרויקטים.
- מאגר זהויות של עומסי עבודה: ישות שמספקת זהויות לעומסי עבודה בפורמט שתואם לניהול זהויות והרשאות גישה (IAM). כל אשכול הוא ספק זהויות במאגר זהויות של כוח עבודה.
זהות זהה בציים
מאגרי זהויות של עומסי עבודה הם ישויות שמספקות זהויות לעומסי עבודה בפורמט ש-IAM יכול להשתמש בו כשמבצעים אימות והרשאה של בקשות. באיחוד זהויות של עומסי עבודה ל-GKE, לכל פרויקט יש כברירת מחדל מאגר זהויות של עומסי עבודה קבוע שמנוהל על ידי Google, והוא ייחודי לפרויקט הזה.
באיחוד זהויות של עומסי עבודה ב-Fleet, מאגר הזהויות של עומסי עבודה שמנוהל על ידי Google בפרויקט המארח של ה-Fleet הוא מאגר הזהויות של עומסי עבודה שמוגדר כברירת מחדל לכל האשכולות שאתם רושמים ב-Fleet, בלי קשר לשאלה אם האשכולות נמצאים בפרויקטים אחרים או בעננים אחרים. אפשר גם להגדיר מאגר זהויות של כוח עבודה בניהול עצמי לשימוש באשכולות ספציפיים במקום במאגר ברירת המחדל.
גם באיחוד זהויות של עומסי עבודה ב-Fleet וגם באיחוד זהויות של עומסי עבודה ל-GKE, משתמשים במדיניות הרשאות של IAM כדי להקצות תפקידים במשאבים ספציפיים Google Cloudלישויות באשכולות, כמו חשבונות שירות של Kubernetes או Pods. במדיניות ההרשאות, אתם מתייחסים לישויות האלה באמצעות מזהה חשבון ראשי, שהוא תחביר שמות ש-IAM יכול לקרוא. מזהה הגורם המורשה כולל את השם של מאגר הזהויות של עומס העבודה שבו האשכול משתמש, ומידע נוסף שבוחר את הישויות הספציפיות באשכול. לדוגמה, המזהה הראשי הבא בוחר חשבון שירות של Kubernetes במרחב שמות:
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT
בדוגמה הזו, השדות הבאים מכילים מידע על הגורם העיקרי:
-
PROJECT_NUMBER: מספר הפרויקט של פרויקט המארח של ה-Fleet. -
WORKLOAD_IDENTITY_POOL_NAME: השם של מאגר הזהויות של עומסי העבודה. -
NAMESPACE: השם של מרחב השמות. -
SERVICEACCOUNT: השם של Kubernetes ServiceAccount.
בקשות ל-APIs מאומתות באמצעות אסימוני גישה לטווח קצר מסוג OAuth 2.0 שנוצרים על ידי אשכולות. Google Cloud אסימוני הגישה האלה כוללים את מזהה חשבון המשתמש של הישות שיצרה את הבקשה. מערכת IAM משתמשת במזהה של חשבון המשתמש כדי לוודא שמדיניות ההרשאות מאשרת לישות לבצע את הפעולה המבוקשת.
השלכות של זהות זהה על צי של מכשירים עם ריבוי דיירים
מזהה החשבון הראשי מוביל לזהות זהה, כלומר כל ישות בסביבה שתואמת למזהה חשבון ראשי ספציפי נחשבת על ידי IAM לאותו הדבר. באיחוד זהויות של עומסי עבודה ל-GKE בפרויקט יחיד, הזהות זהה לכל הישויות שחולקות מזהה ישות מורשית באותו פרויקט. עם זאת, באיחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet, הזהות זהה לכל הישויות שמשתפות מזהה ראשי בכל ה-Fleet, ללא קשר לפרויקט של האשכול.
לדוגמה, עם מזהה חשבון המשתמש בקטע הקודם, בקשות מ-Pods שמשתמשים באותו ServiceAccount, באותו מרחב שמות ובאותו מאגר זהויות של עומסי עבודה מקבלות את אותו מזהה חשבון משתמש, ללא קשר לאשכול או לפרויקט.
אם ה-Fleet שלכם מריץ רק אשכולות בפרויקט המארח של ה-Fleet, ההשלכות של הזהות זהות הן כמו במקרה של איחוד זהויות של עומסי עבודה ל-GKE. עם זאת, אם ב-Fleet יש אשכולות שפועלים בפרויקטים אחרים, הזהות האחידה חלה על כל האשכולות הרשומים ב-Fleet.
דוגמאות למורכבויות של זהות זהה בצי
בתרחישים לדוגמה הבאים מתוארות בעיות פוטנציאליות של זהות זהה שיכולות להתרחש כשמטמיעים איחוד זהויות של עומסי עבודה ב-Fleet. בכל תרחיש מוצגות דרכים אפשריות לצמצום הסיכונים, שיעזרו לכם להתמודד עם המורכבות הזו.
Fleet בפרויקט יחיד עם כל האשכולות שרשומים בו ואותו מאגר זהויות של עומסי עבודה
כדאי להביא בחשבון את הגדרת הצי הבאה:
- כל האשכולות החברים ב-Fleet נמצאים בפרויקט המארח של ה-Fleet.
- כל האשכולות בפרויקט הם חברים ב-Fleet.
- כל האשכולות משתמשים באותו מאגר זהויות של עומסי עבודה.
בתרחיש הזה, כל האשכולות החברים ב-Fleet נמצאים בפרויקט המארח של ה-Fleet, וכל האשכולות בפרויקט הזה הם חברים ב-Fleet.
כפי שמתואר בקטע ההשלכות של זהות זהה על צי GKE, שימוש באיחוד זהויות של עומסי עבודה ב-Fleet בתרחיש הזה זהה לשימוש באיחוד זהויות של עומסי עבודה ל-GKE, ואין סיכון נוסף.
צי עם פרויקט יחיד שחלק מהאשכולות רשומים בו ואותו מאגר זהויות של כוח עבודה
כדאי להביא בחשבון את הגדרת הצי הבאה:
- ה-Fleet מכיל שני אשכולות, שניהם פועלים בפרויקט המארח של ה-Fleet.
- פרויקט המארח של ה-Fleet מכיל אשכול שלישי שלא שייך ל-Fleet.
- בנוסף, באשכול שלא שייך ל-Fleet מופעל איחוד זהויות של עומסי עבודה ל-GKE.
- כל האשכולות בפרויקט משתמשים באותו מאגר זהויות של עומסי עבודה
במסגרת ההגדרה הזו, כל התפקידים שמקצים לישות באחד מהאשכולות בפרויקט חלים על ישויות אחרות בפרויקט שתואמות למזהה העיקרי. יכול להיות שבגלל זה תוענקנה הרשאות שלא במכוון לישויות שלא נכללות בצי. לדוגמה, להענקת תפקיד למזהה של חשבון משתמש שבוחר חשבון שירות ספציפי במרחב שמות יש את ההשלכות הבאות:
- עומסי עבודה שפועלים במרחב השמות שצוין ומשתמשים בחשבון השירות שצוין באשכולות של חברי ה-Fleet, חולקים את הגישה.
- גם עומסי עבודה שפועלים באשכול השלישי שאינו חבר בארגון, שמשתמשים באותו מרחב שמות ובאותו שם של חשבון שירות, מקבלים את אותה הגישה.
ההצעות הבאות יכולות לעזור לכם להתמודד עם המורכבות הזו:
- מגדירים את אשכולות החברים ב-Fleet כך שישתמשו במאגר זהויות של כוח עבודה בניהול עצמי. כך מוודאים שלישויות באשכולות החברים ב-Fleet יש מזהים שונים של ישויות מורשות מאלה של האשכול שלא חבר ב-Fleet. מידע נוסף מופיע במאמר בנושא אימות לממשקי Google Cloud API מעומסי עבודה של Fleet עם רמות אמון שונות.
יוצרים פרויקט ייעודי לאירוח Fleet ומשתמשים במדיניות ארגונית כדי למנוע הפעלה של אשכולות בפרויקט הייעודי לאירוח Fleet. כך מפרידים בין דומיין האמון של מאגר הזהויות של עומסי העבודה ברמת ה-Fleet לבין דומייני האמון ברמת הפרויקט ב-GKE. רק אשכולות רשומים משתפים את מאגר הזהויות של עומסי העבודה בכל צי האשכולות.
ההצעות האלה רלוונטיות לאשכולות ב- Google Cloud ולאשכולות שמצורפים ל- Google Cloud .
צי עם כמה פרויקטים, שחלק מהאשכולות רשומים בו ויש בו מאגר זהויות זהה של עומסי עבודה
כדאי להביא בחשבון את הגדרת הצי הבאה:
- ה-Fleet מכיל אשכולות חברים שפועלים בשני פרויקטים:
project-1ו-project-2. Google Cloud -
project-1הוא פרויקט המארח של ה-Fleet. כל האשכולות ב-project-1הם חברים ב-Fleet. -
project-2מכיל אשכול אחד של חברי Fleet ואשכול אחד לא רשום. - כל האשכולות ב-
project-1משתמשים במאגר הזהויות של עומסי העבודה שמנוהל על ידי Google בפרויקט, שהוא גם מאגר הזהויות של עומסי העבודה שמוגדר כברירת מחדל בכל צי האשכולות. - האשכול שהוא חבר ב-Fleet ב-
project-2משתמש במאגר הזהויות של כוח העבודה בכל ה-Fleet.
בתרחיש הזה, כל ההרשאות שנותנים לישויות בפרויקט המארח של Fleet חלות גם על ישויות באשכול החברים מ-project-2, כי לכולן יש אותו מאגר זהויות של עומסי עבודה.
כדי לנסות לפתור את המורכבות הזו, יוצרים פרויקט ייעודי Google Cloud שישמש כפרויקט המארח של Fleet. אשכולות חברים ב-Fleet ב-project-1 וב-project-2 משתפים את מאגר הזהויות של עומסי העבודה של הפרויקט הייעודי כברירת מחדל. לאחר מכן תוכלו להעניק גישה בהיקף הפרויקט לאשכולות ב-project-1 באמצעות מאגר הזהויות של עומסי העבודה עבור project-1 במזהה העיקרי.
מניעת יצירה של זהויות דומות
כדי להבטיח זהות זהה בציים, צריך להטמיע בקפידה בקרת גישה כדי למנוע יצירה מכוונת או לא מכוונת של זהויות דומות. לדוגמה, נניח שאתם מעניקים גישה לכל ה-Pods שמשתמשים ב-ServiceAccount מסוים במרחב שמות. אם מישהו יוצר את מרחב השמות ואת ServiceAccount באשכול אחר של חבר ב-Fleet, ל-Pods באשכול הזה תהיה אותה גישה.
כדי להקטין את הסיכויים להיתקל בבעיה הזו, כדאי להשתמש במנגנון הרשאה שיאפשר רק לקבוצה מהימנה של משתמשים ליצור, לעדכן או למחוק מרחבי שמות וחשבונות שירות של Kubernetes.
ב-IAM, ההרשאות הבאות מספקות את הגישה הזו:
container.namespaces.*container.serviceAccounts.*
בקרת הגישה מבוססת-תפקידים (RBAC) ב-Kubernetes, והתפקידים הבאים באשכול מגדירים גישה מיוחדת לאינטראקציה עם משאבי Kubernetes האלה:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: namespace-admin rules: - apiGroups: [""] resources: ["namespaces"] verbs: ["create","delete","update","patch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: serviceaccount-admin rules: - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["create","delete","update","patch","impersonate"]