תרחישים לדוגמה לשימוש באבטחת שירות

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

סקירה כללית על אבטחת שירותים זמינה במאמר בנושא אבטחת שירותים ב-Cloud Service Mesh.

הפעלת TLS בו-זמני (mTLS) לשירותים ברשת

ב-service mesh, אפשר להפעיל TLS הדדי (mTLS) כדי שגם הלקוח וגם השרת בתקשורת יוכיחו את הזהויות שלהם ויצפינו את התקשורת.

אימות Mutual TLS (mTLS) ב-Service mesh (לחצו כדי להגדיל)

בקטע הבא לא נדון במשאבים Mesh, Gateway ו-Route. משאבי ה-API האלה נדרשים כדי ליצור את הרשת ולנתב תנועה, אבל לא צריך לעדכן אותם כדי להפעיל mTLS.

אפשר להשיג את התבנית הקודמת על ידי הגדרת המשאבים הבאים של Compute Engine API. בתרשים הזה נעשה שימוש בשרתי proxy מסוג sidecar, אבל המשאבים שמשמשים להגדרת אפליקציית gRPC ללא proxy עם mTLS הם אותם משאבים.

משאבי Compute Engine API ל-mTLS בתוך רשת (לחצו כדי להגדיל)

כדי ליצור את המודל הזה:

1. יוצרים מדיניות TLS (אבטחת שכבת התעבורה) של לקוח.
2. יוצרים מדיניות TLS לשרת.
3. מעדכנים את השדה securitySettings בשירותי ה-Backend הגלובליים הקיימים כדי להפנות למדיניות ה-TLS החדשה של הלקוח.

4. יוצרים מדיניות של נקודת קצה:

   1. מפנים למדיניות ה-TLS של השרת בשדה server_tls_policy.

   2. מגדירים EndpointMatcher כדי לבחור את הלקוחות של Cloud Service Mesh שצריכים לאכוף אימות על תעבורה נכנסת.

      בחירת לקוחות Cloud Service Mesh מבוססת על תוויות שצוינו בהגדרת האתחול של לקוח Cloud Service Mesh. אפשר לספק את התוויות האלה באופן ידני או לאכלס אותן באופן אוטומטי על סמך תוויות שסופקו לפריסות שלכם ב-Google Kubernetes Engine‏ (GKE).

      בתרשים הקודם, התוויות "mesh-service":"true" מוגדרות במדיניות נקודת הקצה ובלקוחות של Cloud Service Mesh. אתם יכולים לבחור תוויות שמתאימות לפריסה שלכם.

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

בתרשים הבא מוצגים משאבי Compute Engine שאתם מגדירים עבור mTLS, בלי קשר לשאלה אם אתם משתמשים ב-Envoy או באפליקציית gRPC בלי שרת Proxy.

משאבי Compute Engine API ל-mTLS בתוך רשת (לחצו כדי להגדיל)

בתרשים הבא מוצג זרימת התנועה ורשימה של משאבי Compute Engine API שאתם מגדירים כדי להפעיל mTLS. שרת ה-proxy מסוג קובץ עזר חיצוני המקומי שנמצא לצד ה-Pod של שירות ב' ב-GKE הוא נקודת הקצה בתקשורת.

משאבי Compute Engine API וזרימת התנועה עבור mTLS בתוך רשת (לחצו כדי להגדיל)

מדיניות נקודת הקצה מבצעת את הפעולות הבאות:

1. בוחר קבוצה של נקודות קצה באמצעות התאמה של נקודות קצה, ואם רוצים, גם יציאות בנקודות הקצה האלה.

   1. התאמת נקודות קצה מאפשרת לכם לציין כללים שקובעים אם לקוח של Cloud Service Mesh יקבל את ההגדרה. הכללים האלה מבוססים על המטא-נתונים של xDS שישות מישור הנתונים מספקת למישור הבקרה – במקרה הזה, Cloud Service Mesh.

      כך מוסיפים תוויות ללקוח Cloud Service Mesh:

      • אפשר לציין את המטא-נתונים האלה באופן ידני בקובץ האתחול של הלקוח של Cloud Service Mesh.

      • אפשרות אחרת היא לאכלס את המטא-נתונים באופן אוטומטי כשמשתמשים ב-GKE, על ידי הוספת צמדי מפתח/ערך לקטע env בקבצים demo_server.yaml או demo_client.yaml. הערכים האלה מופיעים במדריך ההגדרה של Envoy ובמדריך ההגדרה של gRPC ללא proxy.

        לדוגמה, אם משתמשים רק ב-Envoy, אפשר להוסיף את הקידומת ISTIO_META_ למפתח. שמות של משתני סביבה של שרת proxy שמתחילים ב-ISTIO_META_ נכללים ב-bootstrap שנוצר ונשלחים לשרת xDS.

        - name: ISTIO_META_app
          value: 'review'
        - name: ISTIO_META_version
          value: 'canary'
        

   2. אם מציינים יציאה, המדיניות שאליה מתייחסים במדיניות נקודת הקצה נאכפת רק על בקשות נכנסות שמציינות את אותה יציאה. אם לא מציינים יציאה, המדיניות נאכפת על בקשות נכנסות שמציינות יציאה שמופיעה גם בשדה TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, שמועבר ללקוח Cloud Service Mesh בפרטי האתחול שלו.

2. ההפניות הן ל-TLS של הלקוח, ל-TLS של השרת ולמדיניות ההרשאות שמגדירות את נקודות הקצה שאליהן הבקשות מנותבות.

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

חשוב להבחין בין מדיניות TLS של לקוח לבין מדיניות TLS של שרת שמצורפת לשירות לקצה העורפי גלובלי ולמדיניות של נקודת קצה, בהתאמה:

• מדיניות TLS של הלקוח חלה על שירות הקצה העורפי הגלובלי. הוא מציין ל-Envoy proxy או ללקוח בלי שרת Proxy באיזה מצב TLS, זהות וגישת אימות עמיתים להשתמש כשפונים לשירות.
• מדיניות ה-TLS של השרת מצורפת למדיניות נקודת הקצה. הוא מציין לשרת באיזה מצב TLS, זהות וגישת אימות עמיתים להשתמש עבור חיבורים נכנסים.

הפעלת TLS בשער כניסה

אחרי שמגדירים mTLS לתקשורת בתוך הרשת, יכול להיות שתרצו לאבטח את התנועה שנכנסת לרשת, שנקראת תעבורת נתונים נכנסת (ingress). בעזרת Cloud Service Mesh אפשר להגדיר את מישור הנתונים כך שיידרש שימוש בערוצי תקשורת מוצפנים ב-TLS לתעבורת נתונים נכנסת (ingress).

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

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

בקטע הזה מוסברות שתי האפשרויות.

השירותים ברשת מסיימים את ה-TLS לתעבורת נתונים ממאזן עומסים

אם רוצים להפוך את השירותים לזמינים ללקוחות מחוץ ל-Google Cloud, אפשר להשתמש במאזן עומסים חיצוני של אפליקציות. לקוחות שולחים תעבורה לכתובת ה-IP הווירטואלית (VIP) הגלובלית של Anycast של מאזן העומסים, שמעביר את התעבורה הזו לשירותים ברשת שלכם. המשמעות היא שיש שני חיבורים כשלקוח חיצוני צריך להגיע לשירות ברשת.

TLS לשירות ברשת (לחצו כדי להגדיל)

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

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

1. מאבטחים את החיבור בין הלקוח למאזן העומסים באמצעות מאזן עומסים חיצוני של אפליקציות (ALB).
2. מגדירים את מאזן העומסים כך שישתמש בפרוטוקולים HTTPS או HTTP/2 כשהוא מנסה ליצור חיבור עם שירותים ברשת.
3. מגדירים את Cloud Service Mesh כך שלקוחות Cloud Service Mesh יסיימו את ה-HTTPS ויציגו אישורים ללקוח, שבמקרה הזה הוא מאזן העומסים.

מידע נוסף על שלבים 1 ו-2 זמין במאמר הגדרת מאזן עומסים חיצוני מסוג HTTPS מבוסס-תוכן במספר אזורים.

כשמגדירים את האבטחה של Cloud Service Mesh, מגדירים משאבים שונים של Compute Engine API. המשאבים האלה נפרדים מהמשאבים שמגדירים עבור מאזן העומסים. יוצרים קבוצה של משאבי Compute Engine API (כלל העברה גלובלי, שרת proxy ליעד, מפת URL ושירותים גלובליים לקצה העורפי) עבור מאזן העומסים ומגדירים את Cloud Service Mesh באמצעות ממשקי ה-API לניתוב שירותים. בנוסף, במשאב של שירות הקצה העורפי, למאזן העומסים יש את סכמת איזון העומסים INTERNAL_MANAGED ול-Cloud Service Mesh יש את סכמת איזון העומסים INTERNAL_SELF_MANAGED.

בשלב 3, מגדירים את Cloud Service Mesh כך שהלקוחות של Cloud Service Mesh יסיימו את ה-HTTPS ויציגו אישורים ללקוחות.

משאבי Compute Engine API ל-TLS בשירות ב-mesh (לחצו כדי להגדיל)

במודל הזה:

1. יוצרים serverTlsPolicy: מגדירים את serverCertificate במשאב serverTlsPolicy.
2. יוצרים מדיניות של נקודת קצה:
   1. מפנים למדיניות ה-TLS של השרת בשדה authentication.
   2. מגדירים EndpointMatcher כדי לבחור את ישויות מישור הנתונים של xDS שצריכות לאכוף אימות על תנועה נכנסת.
   3. אפשר להגדיר TrafficPortSelector שיחיל את כללי המדיניות רק כשמתבצעות בקשות נכנסות ליציאה שצוינה בלקוח Cloud Service Mesh.

מאחר שמאזן העומסים החיצוני של אפליקציות (ALB) כבר מוגדר ליזום חיבורי TLS לשירותים ברשת, Cloud Service Mesh צריך רק להגדיר את הלקוחות של Cloud Service Mesh לסיים את חיבורי ה-TLS.

שער הכניסה מסיים את ה-TLS עבור תעבורת נתונים ממאזן עומסים לפני העברת תעבורת הנתונים לשירותים ברשת ה-mesh

אם רוצים לחשוף רק שער כניסה למאזן העומסים (LB), אפשר להשתמש בתבנית הפריסה של שער הכניסה. בדפוס הזה, מאזן העומסים לא פונה ישירות לשירותים ברשת. במקום זאת, שרת proxy אמצעי נמצא בקצה של רשת ה-mesh ומנתב את התעבורה לשירותים בתוך רשת ה-mesh, על סמך ההגדרה שהוא מקבל מ-Cloud Service Mesh. שרת ה-proxy האמצעי יכול להיות שרת proxy של Envoy שפרסתם במכונות וירטואליות (VM) בקבוצת מופעים מנוהלת ב-Compute Engine.

TLS לשער Ingress עם mTLS בתוך רשת (לוחצים להגדלה)

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

מבחינת הגדרות, אתם מבצעים את הפעולות הבאות:

1. מגדירים את Service mesh ומפעילים mTLS לתקשורת בתוך ה-Service mesh (כפי שמוסבר קודם).
2. מגדירים את מאזן העומסים לניתוב תעבורה לשער הכניסה וליצירת חיבורים באמצעות פרוטוקול HTTPS (כפי שמוסבר קודם).
3. יוצרים קבוצה של משאבי Compute Engine API שמייצגים את שער הכניסה ואת מדיניות ה-TLS של השרת שלו.

בשלב השלישי, מגדירים את Cloud Service Mesh להפסקת HTTPS ולהצגת אישורים באופן הבא:

1. יוצרים משאב Mesh כדי לייצג את הרשת.

2. יוצרים משאב Route שמפנה לשירותי ה-Backend הגלובליים הנכונים ומקשרים את משאב Route למשאב Mesh.

3. יוצרים מדיניות TLS לשרת: מגדירים את serverCertificate.

4. יוצרים משאב Gateway שמייצג את שער הכניסה המנוהל של Cloud Service Mesh.

5. מצרפים את משאב מדיניות ה-TLS של השרת למשאב Gateway.

דפוס שער ה-Ingress שימושי במיוחד בארגונים גדולים שמשתמשים ב-VPC משותף. במקרה כזה, יכול להיות שצוות יאפשר גישה לשירותים שלו רק דרך שער כניסה. בתרשים שלמעלה, כשמגדירים את כלל ההעברה הגלובלי למאזן העומסים, מציינים כתובת IP שונה (בדוגמה הזו, 10.0.0.2) מזו שצוינה כשמגדירים את הרשת (בדוגמה הזו, כתובת הרשת היא 10.0.0.1). לקוחות שמתקשרים דרך ישות של מישור נתונים xDS שהוגדרה ב-Cloud Service Mesh יכולים להשתמש בכתובת הזו כדי לגשת לשער הכניסה.

לדוגמה, נניח את הפרטים הבאים:

• שני פרויקטים של שירות (1 ו-2), שניהם מצורפים לאותה רשת VPC משותפת.

• פרויקט שירות 1 מכיל רשת שירות שהוגדרה על ידי Cloud Service Mesh.

  בפרויקט שירות 1 הוגדרו רשת ושער כניסה. אפשר להגיע לשער הכניסה הזה בכתובת 10.0.0.2 או ב-VIP.

• פרויקט שירות 2 מכיל רשת שירות שהוגדרה על ידי Cloud Service Mesh.

  יכול להיות שלפרויקט שירות 2 יש שער כניסה משלו, אבל זה לא תנאי הכרחי.

• ‫Cloud Service Mesh מגדיר את הלקוחות של Cloud Service Mesh בכל פרויקט שירות. הלקוחות מופעלים כדי להשתמש באותה רשת.

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

מגבלות

אבטחת שירותים ב-Cloud Service Mesh נתמכת רק ב-GKE. אי אפשר לפרוס אבטחת שירות באמצעות Compute Engine.

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

• במאמר הגדרת אבטחת שירותים ב-Cloud Service Mesh באמצעות Envoy מוסבר איך מגדירים אבטחת שירותים ב-Cloud Service Mesh באמצעות שרתי proxy של Envoy.
• כדי להגדיר אבטחת שירותים ב-Cloud Service Mesh באמצעות אפליקציות gRPC בלי שרת Proxy, אפשר לעיין במאמר הגדרת אבטחת שירותים ב-Cloud Service Mesh באמצעות gRPC בלי שרת Proxy.