הפעלת תכונות אופציונליות במישור הבקרה המנוהל

הערה: מדריך זה תומך רק ב-Cloud Service Mesh עם ממשקי API של Istio ואינו תומך Google Cloud ממשקי API. מידע נוסף זמין במאמר סקירה כללית על Cloud Service Mesh.

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

שימו לב: יש בעיה ידועה בהטמעה של מישור הבקרה TRAFFIC_DIRECTOR. אם אתם משתמשים בהטמעה הזו, אתם צריכים לבצע שינויים ב-istio-asm-managed-rapid configmap, גם אם אתם משתמשים בערוץ שאינו מהיר.

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

תמונת proxy ללא הפצה

• אשכולות שהועלו ישירות (אשכולות המצורפים ישירות למערכת המנוהלתTRAFFIC_DIRECTOR מישור הבקרה ): רק ה-distroless סוג התמונה נתמך. אי אפשר לשנות את זה. אין תמיכה בתמונה default.

• אשכולות שהועברו (אשכולות שהועברו ממישור הבקרה ISTIOD למישור הבקרה TRAFFIC_DIRECTOR): סוג התמונה מוגדר כברירת מחדל לתמונה default (המכילה קבצים בינאריים של ניפוי שגיאות). כדי לשפר את האבטחה, אתם יכולים להביע הסכמה מפורשת לשימוש בתמונות distroless.

מומלץ להשתמש בסוג התמונה Distroless כדי לשפר את האבטחה. השיטה המומלצת היא להגביל את התוכן של זמן ריצה של קונטיינר רק לחבילות הנדרשות. הגישה הזו משפרת את האבטחה ואת יחס האות לרעש של סורקי חשיפות ופגיעויות נפוצות (CVE). ‫Istio מספק תמונות של שרת proxy שמבוססות על תמונות בסיסיות ללא הפצה.

תמונת ה-proxy ללא הפצה לא מכילה קבצים בינאריים מלבד ה-proxy. לכן אי אפשר exec מעטפת או להשתמש ב-curl, ב-ping או בכלי ניפוי באגים אחרים בתוך הקונטיינר. עם זאת, אפשר להשתמש בקונטיינרים זמניים כדי להתחבר ל-Pod של עומס עבודה שפועל, לבדוק אותו ולהריץ פקודות מותאמות אישית. לדוגמה, ראו איסוף יומנים של Cloud Service Mesh.

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

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: istio-release-channel
       namespace: istio-system
     data:
       mesh: |-
         defaultConfig:
           image:
             imageType: distroless

אפשר לבטל את ההגדרה של imageType באמצעות הערת ה-Pod הבאה. שימו לב שבקלאסטרים עם מישור הבקרה המנוהל TRAFFIC_DIRECTOR, רק distroless נתמך כערך ביטול מפורש (אסור להשתמש ב-debug או בסוגים אחרים של תמונות שאינן distroless).

sidecar.istio.io/proxyImageType: distroless

אחרי שמשנים את סוג התמונה של פריסה באמצעות ההערה, צריך להפעיל מחדש את הפריסה. כדי לחזור לתמונת ברירת המחדל, מסירים את ההערה sidecar.istio.io/proxyImageType או את השדה imageType מה-MeshConfig ומפעילים מחדש את הפריסה.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

מכיוון שלא נדרש דימוי בסיס לניפוי באגים, ברוב סוגי ניפוי הבאגים של ה-Proxy צריך להשתמש ב-gcloud beta container fleet mesh debug proxy-status / proxy-config (פרטים).

מדיניות בנושא תנועה יוצאת

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

אזהרה: אתם יכולים לדרוס את השינויים שלכם. אם כבר יש לכם configmap, אתם צריכים לכלול את כל הגדרות ההתאמה האישית הקודמות בקטע mesh: כדי לשמור את השינויים.

1. ההגדרה הבאה מגדירה את outboundTrafficPolicy ל-REGISTRY_ONLY:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: istio-release-channel
     namespace: istio-system
   data:
     mesh: |-
       outboundTrafficPolicy:
         mode: REGISTRY_ONLY
   

   כאשר release-channel הוא ערוץ ההפצה שלכם (asm-managed, ‏asm-managed-stable או asm-managed-rapid).

2. אפשר לבצע את שינויי ההגדרות הקודמים הנדרשים ב-configmap באמצעות הפקודה הבאה:

   kubectl edit configmap istio-release-channel -n istio-system -o yaml
   

3. מריצים את הפקודה הבאה כדי להציג את ה-configmap:

   kubectl get configmap istio-release-channel -n istio-system -o yaml
   

4. כדי לוודא ש-outboundTrafficPolicy מופעל עם REGISTRY_ONLY, צריך לוודא שהשורות הבאות מופיעות בקטע mesh:.

   ...
   apiVersion: v1
   data:
     mesh: |
       outboundTrafficPolicy:
        mode: REGISTRY_ONLY
   ...
   

אימות משתמשי קצה

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

הגדרת גרסת ה-TLS המינימלית לעומסי העבודה

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

אתם יכולים להשתמש בשדה minProtocolVersion כדי לציין את גרסת ה-TLS המינימלית לחיבורי TLS בין עומסי העבודה. למידע נוסף על הגדרת גרסת ה-TLS המינימלית ובדיקת הגדרת ה-TLS של עומסי העבודה, ראו הגדרת גרסת ה-TLS המינימלית של עומסי עבודה ב-Istio.

אזהרה: במדריך ל-Istio שמקושר בפסקה הקודמת נעשה שימוש ב-IstioOperator, שלא נתמך ב-Cloud Service Mesh מנוהל. צריך להמיר את התג IstioOperator לתג ConfigMap מקביל, כמו בדוגמה הבאה.

בדוגמה הבאה מוצגת הגדרה של ConfigMap שקובעת את גרסת ה-TLS המינימלית לעומסי עבודה ל-1.3:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    meshMTLS:
      minProtocolVersion: TLSV1_3