סקירה כללית של mTLS בקצה העורפי עם ניהול זהויות של עומסי עבודה

אפשר להשיג mTLS בבק-אנד עם זהות מנוהלת של עומס עבודה או בלי. מידע נוסף על mTLS בבקאנד ללא ניהול זהויות של עומסי עבודה זמין במאמר סקירה כללית על TLS מאומת בבקאנד ו-mTLS בבקאנד.

במסמך הזה מפורטת סקירה כללית של השימוש בזהות מנוהלת של עומס עבודה כדי להשיג TLS הדדי (mTLS) בין מאזן עומסים של אפליקציות לבין הקצה העורפי שלו. זהויות מנוהלות של עומסי עבודה מקצות ומנהלות באופן אוטומטי אישורי ‎X.509 משירות Certificate Authority Service.

המידע במסמך הזה מבוסס על מושגים שהוצגו במסמכים הבאים:

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

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

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

אתם יכולים להקצות זהות מנוהלת – שמיוצגת על ידי מזהה SPIFFE – לשירות לקצה העורפי של מאזן עומסים. ‫Google Cloud Certificate Authority Service מקצה באופן אוטומטי אישור X.509 למזהה SPIFFE. אישור X.509 הזה של מזהה SPIFFE נקרא גם מסמך זהות שניתן לאימות של SPIFFE‏ (SVID). השירות לקצה העורפי של מאזן העומסים והקצוות העורפיים שלו משתמשים ב-SVID כדי לאמת אחד את השני באמצעות אימות mTLS.

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

‫mTLS בשרת העורפי באמצעות זהויות מנוהלות של עומסי עבודה.
mTLS בשרת העורפי באמצעות Workload Identity מנוהל (לחצו כדי להגדיל).

הדוגמה הבאה היא של X.509-SVID שמשמש כעטיפה למזהה SPIFFE. מזהה SPIFFE, שמיוצג כ-URI, מקודד בשם החלופי של בעלים (subject) (SAN) באישור X.509.

Issuer:
    C=US
    O=Example Inc.
    CN=Example CA

Validity:
    Not Before: Jun 14 00:00:00 2025 GMT
    Not After : Jun 16 00:00:00 2025 GMT

Subject (Distinguished Name):
    C=US
    O=Example Inc.
    OU=Production
    CN=api.example.com

Subject Public Key Info:
    Public Key Algorithm: RSA Encryption
    RSA Public-Key: (2048 bit)

X.509v3 Extensions:
    Subject Alternative Name (SAN):
        DNS: api.example.com
        URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

הפלט הזה כולל את הערכים הבאים:

  • ‫WORKLOAD_IDENTITY_POOL_ID: המזהה של מאגר הזהויות של עומסי העבודה
  • ‫PROJECT_NUMBER: מספר הפרויקט שלGoogle Cloud הפרויקט
  • ‫NAMESPACE_ID: מזהה מרחב השמות
  • ‫MANAGED_IDENTITY_ID: המזהה של הזהות המנוהלת

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

אלה כמה מהיתרונות של שימוש ב-Workload Identity מנוהל עבור mTLS של קצה עורפי:

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

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

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

  • ניהול מרכזי: מאגרי זהויות של עומסי עבודה מספקים נקודת בקרה מרכזית. אדמינים יכולים להגדיר דומיינים מהימנים וליצור מדיניות אימות כדי לקבוע אילו עומסי עבודה יכולים לקבל אישור X.509 לזהות המנוהלת.

ארכיטקטורה של mTLS בבק-אנד באמצעות זהות מנוהלת של עומס עבודה

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

  • שירות לקצה העורפי של מאזן העומסים (Compute Engine API)
  • תחום מהימן לניהול זהויות והרשאות גישה (Identity and Access Management API)
  • מאגר רשויות אישורים (Certificate Authority Service API)
  • הגדרת אימות בקצה העורפי (Network Security API)
  • הגדרת אמון ב-Certificate Manager ‏ (Certificate Manager API)
  • אישור זהות מנוהל של Certificate Manager (Certificate Manager API)

בתרשים הבא מוצגת זהות מנוהלת בשירות לקצה העורפי של מאזן העומסים, שמאפשרת למאזן העומסים לאמת את עצמו בקצה העורפי. בתרשים, שלבים 1-3 מייצגים משאבים שנוצרו באופן מפורש, בעוד ששלבים 4-5 מייצגים משאבים שנוצרו באופן אוטומטי.

  1. מגדירים מאגר CA של Certificate Authority Service להנפקת אישורים לזהויות מנוהלות של עומסי עבודה.
  2. מגדירים דומיין מהימן על ידי יצירת מאגר זהויות של עומסי עבודה. מאגר כזה דורש מרחב שמות, זהות מנוהלת, מדיניות אימות, משאב להגדרת הנפקת אישורים מוטמעת ומשאב להגדרת אמון מוטמעת.
  3. מגדירים את שירות הקצה העורפי של מאזן העומסים באמצעות הזהות המנוהלת.

  4. התכונה 'זהות מנוהלת של עומס עבודה' יוצרת באופן אוטומטי את האישור של הזהות המנוהלת ב-Certificate Manager ואת הגדרת האמון ב-Certificate Manager.

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

  5. התכונה 'ניהול זהויות של עומסי עבודה' יוצרת באופן אוטומטי את הגדרת האימות של ה-Backend.

    הגדרת האמינות של Certificate Manager מצורפת להגדרת האימות של ה-Backend. אישור הזהות המנוהל (X.509-SVID) של Certificate Manager מצורף גם להגדרת האימות של הקצה העורפי, שמשמשת לאימות מול הקצה העורפי.

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

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

משאבים שנוצרו במהלך mTLS בשרת העורפי באמצעות זהות מנוהלת

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

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

משאבים שנוצרו באופן מפורש

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

מאגר רשויות אישורים

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

אפשר להשתמש במאגרי CA Service כדי להגדיר את ההיררכיה הזו.

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

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

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

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

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

מרחב שמות

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

זהות מנוהלת של עומס עבודה

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

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

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

הערך של זהות מנוהלת הוא מזהה SPIFFE שצוין באופן מלא, שחייב להיות בפורמט הבא:

spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

TRUST_DOMAIN_NAME מורחב כך:

WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog

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

spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

מדיניות האימות

מדיניות אימות מכילה כללים שבאמצעותם Google Cloud IAM יכול לוודא אם שירות לקצה העורפי עומד בדרישות לקבלת אישור X.509 עבור הזהות המנוהלת.

אם האימות של מדיניות האימות עובר בהצלחה, IAM מבקש אישור X.509 עבור הזהות המנוהלת מ-Certificate Authority Service. אישור X.509 נוצר במאגר ה-CA שמקושר לזהות המנוהלת. שירות ה-CA מקצה את האישור באמצעות שיקוף הזהות, שבו מזהה ה-SPIFFE שהוגדר משתקף באישור X.509.

הגדרת הנפקת אישורים מוטבעת

כשמגדירים מאגר זהויות של עומסי עבודה, מגדירים הגדרת הנפקת אישורים מוטבעת. בהגדרה הזו מציינים באיזה מאגר של רשויות אישורים מתוך מופע Certificate Authority Service יש להשתמש כדי ליצור אישורי X.509 לזהויות במאגר הזהויות של עומסי עבודה. קובץ התצורה מציין גם את משך החיים של האישור, את אחוז חלון הרוטציה ואת אלגוריתם המפתח.

מאגר הרשות שמנפיקה את האישורים מנפיק אישורי X.509 לזהויות מנוהלות של Workload Identity אחרי שהאכיפה של מדיניות האימות (attestation) מצליחה.

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

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

הגדרת האמון המוטמעת מכילה קבוצה של ישויות עוגן אמינות שזהות מנוהלת של עומס עבודה משתמשת בהן כדי לאמת אישורי עמיתים. הגדרת האמון של Certificate Manager כוללת מאגר אישורים של SPIFFE, שנשאר מסונכרן עם הגדרת האמון המוטמעת של מאגר הזהויות של עומס העבודה.

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

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

היררכיית משאבים מנוהלת של זהויות של עומסי עבודה.
היררכיית משאבים מנוהלת של Workload Identity (לוחצים כדי להגדיל).

שירות לקצה העורפי (Compute Engine API)

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

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

  • אם מגדירים את המאפיין identity, אי אפשר להגדיר באופן ידני את השדות הבאים במאפיין tlsSettings:

    • tlsSettings.sni
    • tlsSettings.subjectAltNames
    • tlsSettings.authenticationConfig

  • אפשר להקצות את השדה identity רק במהלך יצירת שירות לקצה העורפי.

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

משאבים שנוצרו באופן אוטומטי

אחרי שמגדירים את המאפיין identity (backendService.tlsSettings.identity) בשירות לקצה העורפי של מאזן העומסים, הזהות המנוהלת של כוח העבודה יוצרת באופן אוטומטי את המשאבים הבאים ב-Certificate Manager API וב-Network Security API.

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

הגדרת אמון ב-Certificate Manager ‏ (Certificate Manager API)

הגדרת האמון של Certificate Manager נוצרת באופן אוטומטי ואי אפשר לערוך או למחוק אותה ישירות.

הגדרת האמון ב-Certificate Manager מכילה שדה שנקרא spiffeTrustStores. השדה spiffeTrustStores מכיל את חבילת האמון שמשויכת לדומיין האמון של מאגר הזהויות של עומס העבודה, וכל חבילות אמון נוספות שצוינו בשדה additionalTrustBundles בהגדרת האמון המוטמעת של מאגר הזהויות של עומס העבודה.

כדי לאמת אישורי SPIFFE, השדה spiffeTrustStores בהגדרת האמון של Certificate Manager מופעל באופן אוטומטי כשמשתמשים בזהות מנוהלת של עומס עבודה. אם השדה spiffeTrustStores מופעל, השדה trustStores נשאר ריק.

השדה spiffeTrustStores הוא מבנה נתונים של מפה שבו צמד המפתח/ערך הוא כדלקמן:

  • המפתח יכול להיות דומיין מהימן שקשור למאגר זהויות של עומסי עבודה (בפורמט שמסתיים ב-.workload.id.goog), או דומיין מהימן נוסף.
  • הערך הוא אובייקט TrustStore. האובייקט הזה מכיל אוסף של אישורי בסיס מהימנים (שנקראים חבילת אמון) שמשמשים לאימות אישורי SPIFFE מאותו דומיין אמון ספציפי.

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

אישור מנוהל של זהות מנוהלת ב-Certificate Manager (Certificate Manager API)

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

לאישור הזהות המנוהלת של Certificate Manager יש מאפיין managedIdentity שמזהה אותו כאישור של זהות מנוהלת. משאב האישור של הזהות המנוהלת ב-Certificate Manager מאחסן את ה-X.509-SVID בפורמט PEM. ה-X.509-SVID הזה מכיל את מזהה SPIFFE שמקודד כ-URI בשדה SAN. מזהה ה-SPIFFE הזה תואם לזהות המנוהלת במאגר הזהויות של עומסי העבודה.

ההיקף של אישור הזהות המנוהל של Certificate Manager הוא CLIENT_AUTH, מה שמציין שהאישור הזה משמש כאישור לקוח ב-mTLS של קצה עורפי.

הגדרת אימות בקצה העורפי (Network Security API)

הגדרת האימות של ה-Backend נוצרת באופן אוטומטי על ידי אימות הזהויות של עומסי העבודה המנוהל. הגדרת האימות של ה-backend היא לקריאה בלבד, ואי אפשר לערוך או למחוק אותה ישירות באמצעות Network Security API.

הגדרת האמון של Certificate Manager מצורפת להגדרת האימות של ה-Backend.

אישור הזהות המנוהלת של Certificate Manager מצורף גם להגדרת האימות של ה-backend, ומשמש כ-X.509-SVID בבקשות mTLS של ה-backend בין מאזן העומסים לבין עומסי העבודה של היעד.

מגבלות

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

  • אין תמיכה ב-mTLS של קצה עורפי עבור קצוות עורפיים של NEG באינטרנט הגלובלי.

  • אם מקצים זהות מנוהלת לשירות הקצה העורפי (backendService.tlsSettings.identity), אי אפשר להגדיר באופן ידני את השדות הבאים במאפיין tlsSettings של שירות הקצה העורפי:

    • backendService.tlsSettings.sni
    • backendService.tlsSettings.subjectAltNames
    • backendService.tlsSettings.authenticationConfig

  • אפשר להקצות זהות מנוהלת רק בזמן יצירת שירות לקצה העורפי.

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

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