מידע על איחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet

בדף הזה מתואר איחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet, שהוא מנגנון לאימות בקשות מעומסי עבודה ב-Fleet אל ממשקי Google Cloud API. בדף הזה מוסבר על זהות זהה לעומסי עבודה, על איחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet ועל שיטות מומלצות לניהול של איחוד שירותי אימות הזהות של עומסי עבודה בהיקף גדול.

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

לפני שקוראים את הדף הזה, חשוב להכיר את המושגים הבאים:

מידע על זהויות מאוחדות של עומסי עבודה ב- Google Cloud

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

איחוד זהויות של עומסי עבודה ל-GKE הוא הטמעה של איחוד זהויות של עומסי עבודה שספציפית ל-GKE. הוא מספק מאגר זהויות של עומסי עבודה שמנוהל על ידי Google ברמת הפרויקט, שממנו אפליקציות שפועלות באשכולות GKE מקבלות זהויות. איחוד זהויות של עומסי עבודה ב-Fleet מרחיב את איחוד הזהויות של עומסי עבודה ל-GKE לכל האשכולות החברים ב-Fleet, בלי קשר לשאלה אם האשכולות נמצאים בפרויקטים שונים או מחוץ ל- Google Cloud. באמצעות איחוד זהויות של עומסי עבודה ב-Fleet, אשכולות רשומים שמופעל בהם איחוד זהויות של עומסי עבודה בחברות ב-Fleet מקבלים זהויות באמצעות מאגר זהויות של עומסי עבודה בניהול Google ברמת ה-Fleet. מאגר משותף כזה מאפשר לכם להגדיר אימות לממשקי API ולשירותים אחרים בכל הצי שלכם, גם בפרויקטים שונים. Google Cloud

בנוסף, סוגים מסוימים של אשכולות יכולים להשתמש באיחוד זהויות של עומסי עבודה ב-Fleet כדי לבצע אימות ל- Google Cloud כחלק מהחברות ב-Fleet. האיחוד הזה נדרש כדי להשתמש בתכונות מסוימות של GKE שפועלות בפרויקטים שונים, כמו Cloud Service Mesh.

מידע על מאגרי זהויות של עומסי עבודה

מאגר זהויות של עומסי עבודה הוא ישות שמנהלת באופן מרכזי את הזהויות של האפליקציות שלכם. כשמפעילים איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE באשכולות, פרויקט האשכול מקבל מאגר זהויות של עומסי עבודה שמנוהל על ידי Google, עם שם קבוע שספציפי לפרויקט. אפליקציות באשכולות מקבלות זהויות ממאגר הזהויות של עומסי עבודה שמנוהל על ידי Google, כדי לאמת קריאות ל-API. Google Cloud למאגר הזהויות של עומסי העבודה שמנוהל על ידי Google יש את התחביר PROJECT_ID.svc.id.goog, כאשר PROJECT_ID הוא מזהה הפרויקט של האשכול.

באיחוד שירותי אימות הזהויות של עומסי עבודה ב-Fleet, מאגר הזהויות של עומסי העבודה שמנוהל על ידי Google בפרויקט המארח של ה-Fleet הוא גם מאגר הזהויות של עומסי העבודה של כל האשכולות שאתם רושמים ב-Fleet, בלי קשר לשאלה אם האשכולות האלה נמצאים בפרויקטים אחרים או מחוץ ל- Google Cloud. כל אשכול ב-Fleet משתמש במאגר הזהויות של עומסי העבודה FLEET_HOST_PROJECT_ID.svc.id.goog, כאשר FLEET_HOST_PROJECT_ID הוא מזהה הפרויקט של פרויקט המארח של ה-Fleet.

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

כל אפליקציה בצי מקבלת זהות מאוחדת נפרדת ממאגר הזהויות של עומסי עבודה של הצי, והאפליקציה יכולה להשתמש בה כדי לבצע אימות ל-Google Cloud ולשירותים אחרים שאתם מפתחים. האפליקציות מקבלות מזהה ראשי ש-IAM יכול לזהות. משתמשים במזהה הזה לפי התחביר הבא:

PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/SELECTOR

התחביר הזה כולל את השדות הבאים:

  • ‫PREFIX: principal או principalSet, בהתאם לסוג המשאב של Kubernetes שבוחרים בשדה SELECTOR.
  • ‫FLEET_PROJECT_NUMBER: מספר הפרויקט של פרויקט המארח של הצי.

  • ‫WORKLOAD_IDENTITY_POOL_NAME: מאגר הזהויות של כוח העבודה עבור הצי. הערך הזה תלוי במאגר הזהויות של עומסי העבודה שהגדרתם בכל אשכול, באופן הבא:

    • מאגר זהויות של עומסי עבודה בניהול Google: FLEET_HOST_PROJECT_ID.svc.id.goog

    • מאגר זהויות של עומסי עבודה בניהול עצמי (גרסת Preview): ‫POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, כאשר POOL_HOST_PROJECT_NUMBER הוא מספר הפרויקט שבו יצרתם את מאגר הזהויות של עומסי עבודה בניהול עצמי.

  • ‫SELECTOR: בוחר המשאבים. רשימת הסלקטורים הנתמכים מופיעה בקטע מזהים נתמכים של חשבונות משתמשים. לדוגמה, subject/ns/NAMESPACE/sa/SERVICEACCOUNT בוחר חשבון שירות ספציפי של Kubernetes במרחב שמות ספציפי.

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

מידע על זהות זהה

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

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

לדוגמה, נניח שיש אפליקציה עם קצה עורפי שפריסתו מתבצעת בכמה אשכולות באותו צי. אם מקצים תפקיד למזהה של גורם מרכזי שבוחר את default Kubernetes ServiceAccount במרחב השמות של backendKubernetes, כל אפליקציה במרחב השמות הזה שמשתמשת ב-ServiceAccount הזה מקבלת את אותה גישה.

אם צי האשכולות מריץ רק אשכולות בפרויקט המארח של הצי, ההשלכות של הזהות זהות הן כמו במקרה של איחוד זהויות של עומסי עבודה ל-GKE. עם זאת, אם ב-Fleet שלכם יש אשכולות שפועלים בפרויקטים אחרים או מחוץ ל-Google Cloud, הזהות הזהה המרומזת הזו חלה על כל האשכולות הרשומים ב-Fleet.

זהות זהה בסביבות מרובות דיירים או בסביבות עם רמות אמון שונות

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

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

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

מודל הזהויות הזהות בצי משתנה באופן הבא, בהתאם לכך אם אתם משתמשים רק במאגר הזהויות של עומסי העבודה שמנוהל על ידי Google או מגדירים מאגר זהויות של עומסי עבודה שמנוהל על ידכם:

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

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

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

מתי כדאי להשתמש במאגרי זהויות של כוח עבודה בניהול עצמי

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

אנחנו ממליצים להגדיר מאגר זהויות של עומסי עבודה בניהול עצמי עבור צי הרכבים בתרחישים כמו אלה:

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

איך פועל איחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet

בקטעים הבאים מוסבר איך איחוד שירותי אימות הזהות של עומסי עבודה פועל ב-Fleet, כולל זרימת פרטי הכניסה לאימות ומזהי הגורמים המורשים (principal) הנתמכים ב-IAM.

תהליך העברת פרטי הכניסה

כדי לאפשר לאפליקציות במרחב שמות ספציפי לבצע אימות באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet, מבצעים את הפעולות הבאות:

  1. פורסים ConfigMap במרחב השמות הזה עם הפרטים הבאים:

    • מאגר הזהויות של עומסי עבודה וספק הזהויות של האשכול.
    • הנתיב בכל Pod שבו Kubernetes מטמיע אסימון ServiceAccount. האסימון הזה הוא אסימון JWT (‏JSON Web Token) חתום.

    ה-ConfigMap הזה פועל כקובץ Application Default Credentials‏ (ADC) עבור עומסי עבודה.

  2. יוצרים מדיניות הרשאה ב-IAM שמעניקה גישה למשאביGoogle Cloud ספציפיים למזהה החשבון הראשי של החשבון הראשי באשכולות, כמו ServiceAccount במרחב השמות.

  3. מוודאים שעומס העבודה במרחב השמות כולל את ההגדרות הבאות במפרט ה-Pod:

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

כשעומס העבודה מבצע קריאה ל-API, השלבים הבאים מתרחשים: Google Cloud

  1. ספריות האימות של Google Cloud משתמשות ב-Application Default Credentials ‏ (ADC) כדי למצוא פרטי כניסה. ‫ADC בודק את הנתיב שציינתם במשתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS כדי לחפש אסימון אימות.
  2. ספריית האימות ADC משתמשת בנתונים ב-ConfigMap כדי להחליף את ה-JWT של ServiceAccount שהעליתם ל-Pod באסימון גישה מאוחד לטווח קצר מ-Security Token Service, שמפנה למזהה העיקרי של עומס העבודה.
  3. ‫ADC כולל את אסימון הגישה המאוחד בבקשת ה-API.
  4. מדיניות ההרשאות ב-IAM מאשרת למזהה של חשבון המשתמש לבצע את הפעולה המבוקשת במשאב Google Cloud .

מזהי ישויות נתמכים לאיחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet

בטבלה הבאה מפורטים הסלקטורים שבהם אפשר להשתמש בכללי מדיניות הרשאה ב-IAM כדי להפנות לחשבונות משתמשים בציים:

סוג המזהה של חשבון המשתמש תחביר
כל קבוצות ה-Pod שמשתמשות בחשבון שירות ספציפי של Kubernetes בוחרים את חשבון השירות לפי שם: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫NAMESPACE: מרחב השמות של Kubernetes.
  • ‫SERVICEACCOUNT: השם של Kubernetes ServiceAccount.
Select the ServiceAccount by UID: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט של הצי.
  • ‫SERVICEACCOUNT_UID: ה-UID של אובייקט ServiceAccount בשרת ה-API.

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