דוגמה ל-Cloud Service Mesh: ‏ mTLS

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

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

באמצעות Cloud Service Mesh, אתם יכולים לאכוף mTLS מחוץ לקוד האפליקציה, על ידי החלת קובץ YAML יחיד. עם Cloud Service Mesh, אתם יכולים להחיל מדיניות אימות על כל רשת השירותים, על מרחב שמות או על עומס עבודה ספציפי.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• GKE
• Cloud Service Mesh

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

לפני שמתחילים

• הקפידו לוודא שהחיוב מופעל בפרויקט שלכם ב-Cloud. איך מוודאים שהחיוב מופעל בפרויקט?

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

  • יצירת אשכול GKE.
  • הקצאת משאבים מנוהלת של Cloud Service Mesh.
  • פריסת שער כניסה.
  • פריסת האפליקציה לדוגמה Online Boutique ממאגר anthos-service-mesh-packages, ששונה מהקבוצה המקורית של קובצי המניפסט במאגר microservices-demo. בהתאם לשיטות המומלצות, כל שירות נפרס במרחב שמות נפרד עם חשבון שירות ייחודי.

• יוצרים Pod TestCurl כדי לשלוח תעבורת נתונים של טקסט לא מוצפן לבדיקה.

    apiVersion: v1
    kind: Pod
    metadata:
      name: testcurl
      namespace: default
      annotations:
        sidecar.istio.io/inject: "false"
    spec:
      containers:
      - name: curl
        image: curlimages/curl
        command: ["sleep", "600"]
  

גישה לבוטיק אונליין

1. מגדירים את ההקשר הנוכחי של kubectl לקלאסטר שבו פרסתם את Online Boutique:

   gcloud container clusters get-credentials CLUSTER_NAME  \
       --project=PROJECT_ID \
       --zone=CLUSTER_LOCATION 
   

2. מציגים את רשימת השירותים במרחב השמות frontend:

   kubectl get services -n frontend
   

   שימו לב ש-frontend-external הוא LoadBalancer, ויש לו כתובת IP חיצונית. האפליקציה לדוגמה כוללת שירות שהוא מאזן עומסים, כך שאפשר לפרוס אותה ב-GKE בלי Cloud Service Mesh.

3. נכנסים לאפליקציה בדפדפן באמצעות כתובת ה-IP החיצונית של שירות frontend-external:

   http://FRONTEND_EXTERNAL_IP/
   

4. Cloud Service Mesh מאפשר לכם לפרוס שער כניסה. אפשר גם לגשת ל-Online Boutique באמצעות כתובת ה-IP החיצונית של שער הכניסה. מקבלים את כתובת ה-IP החיצונית של השער. מחליפים את ה-placeholders בפרטים הבאים:

   • ‫GATEWAY_SERVICE_NAME : השם של שירות שער הכניסה. אם פרסתם את שער הדוגמה ללא שינוי, או אם פרסתם את שער הכניסה שמוגדר כברירת מחדל, השם הוא istio-ingressgateway.
   • ‫GATEWAY_NAMESPACE: מרחב השמות שבו פרסתם את שער הכניסה. אם פרסתם את שער הכניסה שמוגדר כברירת מחדל, מרחב השמות הוא istio-system.

   kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
   

5. פותחים כרטיסייה נוספת בדפדפן ועוברים לאפליקציה באמצעות כתובת ה-IP החיצונית של שער הכניסה:

   http://INGRESS_GATEWAY_EXTERNAL_IP/
   

6. מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר. מכיוון שהשירותים נמצאים במרחבי שמות שונים, צריך להשתמש בפקודת curl כדי להשיג את שם ה-DNS של שירות frontend.

   kubectl debug --image istio/base --target istio-proxy -it \
     $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
     -n product-catalog -- \
     curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

   הבקשה מצליחה עם הסטטוס 200, כי כברירת מחדל, גם תעבורת TLS וגם תעבורת טקסט רגיל מתקבלות.

הפעלת mTLS לכל מרחב שמות

כדי לאכוף mTLS, צריך להחיל PeerAuthentication מדיניות עם kubectl.

1. שומרים את מדיניות האימות הבאה בשם mtls-namespace.yaml.

   cat <<EOF > mtls-namespace.yaml
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "namespace-policy"
   spec:
     mtls:
       mode: STRICT
   EOF
   

   השורה mode: STRICT בקובץ ה-YAML מגדירה את השירותים כך שהם יקבלו רק mTLS. כברירת מחדל, הערך של mode הוא PERMISSIVE, שמגדיר את השירותים לקבל גם טקסט לא מוצפן וגם mTLS.

2. מחילים את מדיניות האימות כדי להגדיר את כל השירותים של Online Boutique כך שיקבלו רק mTLS:

   for ns in ad cart checkout currency email frontend loadgenerator \
        payment product-catalog recommendation shipping; do
   kubectl apply -n $ns -f mtls-namespace.yaml
   done
   

   הפלט אמור להיראות כך:

   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created
   peerauthentication.security.istio.io/namespace-policy created

3. עוברים לכרטיסייה בדפדפן שדרכה ניגשים לחנות הווירטואלית באמצעות כתובת ה-IP החיצונית של שירות frontend-external:

   http://FRONTEND_EXTERNAL_IP/
   

4. יש לרענן את הדף. הדפדפן מציג את השגיאה הבאה:

   

   רענון הדף גורם לשליחת טקסט רגיל לשירות frontend. בגלל STRICTמדיניות האימות, שרת ה-proxy מסוג קובץ עזר חיצוני חוסם את הבקשה לשירות.

5. עוברים לכרטיסייה בדפדפן שדרכה ניגשים לחנות הווירטואלית באמצעות כתובת ה-IP החיצונית של istio-ingressgateway, ומרעננים את הדף. הדף מוצג בהצלחה. כשניגשים ל-Online Boutique באמצעות שער הכניסה, הבקשה עוברת בנתיב הבא:

   

   תהליך האימות של mTLS:

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

6. מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר.

   kubectl exec testcurl -n default -- curl \
     http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

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

חיפוש ומחיקה של מדיניות אימות

1. כדי לראות רשימה של כל כללי המדיניות של PeerAuthentication ב-Service Mesh:

   kubectl get peerauthentication --all-namespaces
   

   הפלט אמור להיראות כך:

   NAMESPACE         NAME               MODE     AGE
   ad                namespace-policy   STRICT   17m
   cart              namespace-policy   STRICT   17m
   checkout          namespace-policy   STRICT   17m
   currency          namespace-policy   STRICT   17m
   email             namespace-policy   STRICT   17m
   frontend          namespace-policy   STRICT   17m
   loadgenerator     namespace-policy   STRICT   17m
   payment           namespace-policy   STRICT   17m
   product-catalog   namespace-policy   STRICT   17m
   recommendation    namespace-policy   STRICT   17m
   shipping          namespace-policy   STRICT   17m
   

2. מוחקים את מדיניות האימות מכל מרחבי השמות של Online Boutique:

   for ns in ad cart checkout currency email frontend loadgenerator payment \
     product-catalog recommendation shipping; do
       kubectl delete peerauthentication -n $ns namespace-policy
   done;
   

   הפלט אמור להיראות כך:

   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   

3. ניגשים אל Online Boutique באמצעות כתובת ה-IP החיצונית של שירות frontend-external ומרעננים את הדף. הדף מוצג כמו שציפיתם.

4. מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר.

   kubectl debug --image istio/base --target istio-proxy -it \
     $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
     -n product-catalog -- \
     curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

   הבקשה מצליחה עם הסטטוס 200, כי כברירת מחדל, גם תעבורת TLS וגם תעבורת טקסט רגיל מתקבלות.

אם מרעננים את הדף במסוף שבו מוצגת רשימת Workloads, הסטטוס של mTLS יהיה Permissive. Google Cloud

הפעלת פרוטוקול TLS הדדי לכל עומס עבודה

כדי להגדיר מדיניות PeerAuthentication עבור עומס עבודה ספציפי, צריך להגדיר את הקטע selector ולציין את התוויות שתואמות לעומס העבודה הרצוי. עם זאת, Cloud Service Mesh לא יכול לצבור מדיניות ברמת עומס העבודה לתעבורת mTLS יוצאת לשירות. כדי לנהל את ההתנהגות הזו, צריך להגדיר כלל יעד.

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

   cat <<EOF | kubectl apply -n frontend -f -
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "frontend"
     namespace: "frontend"
   spec:
     selector:
       matchLabels:
         app: frontend
     mtls:
       mode: STRICT
   EOF
   

   הפלט אמור להיראות כך:

   peerauthentication.security.istio.io/frontend created

2. מגדירים כלל ניתוב תואם.

   cat <<EOF | kubectl apply -n frontend -f -
   apiVersion: "networking.istio.io/v1alpha3"
   kind: "DestinationRule"
   metadata:
     name: "frontend"
   spec:
     host: "frontend.demo.svc.cluster.local"
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

   הפלט אמור להיראות כך:

   destinationrule.networking.istio.io/frontend created

3. ניגשים אל Online Boutique באמצעות כתובת ה-IP החיצונית של שירות frontend-external ומרעננים את הדף. הדף לא מוצג כי frontend service מוגדר ל-STRICT mTLS, והבקשה נחסמת על ידי פרוקסי ה-sidecar.

4. מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר.

   kubectl exec testcurl -n default -- curl \
     http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

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

5. מחיקת מדיניות האימות:

   kubectl delete peerauthentication -n frontend frontend
   

   הפלט אמור להיראות כך:

   peerauthentication.security.istio.io "frontend" deleted
   

6. מחיקת כלל היעד:

   kubectl delete destinationrule -n frontend frontend
   

   הפלט אמור להיראות כך:

   destinationrule.networking.istio.io "frontend" deleted
   

אכיפת mTLS בכל הרשת

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

1. אכיפת mTLS בכל הרשת:

   kubectl apply -f - <<EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "mesh-wide"
     namespace: "istio-system"
   spec:
     mtls:
       mode: STRICT
   EOF
   

   הפלט אמור להיראות כך:

   peerauthentication.security.istio.io/mesh-wide created

2. ניגשים אל Online Boutique באמצעות כתובת ה-IP החיצונית של שירות frontend-external ומרעננים את הדף. הדף לא מוצג.

3. מריצים את הפקודה הבאה כדי curl את שירות frontend באמצעות HTTP רגיל מ-Pod אחר.

   kubectl exec testcurl -n default -- curl \
     http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

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

4. מחיקת המדיניות mesh-wide:

   kubectl delete peerauthentication -n istio-system mesh-wide
   

   הפלט אמור להיראות כך:

   peerauthentication.security.istio.io "mesh-wide" deleted
   

הערה: מידע נוסף על מדיניות הרשאות זמין במאמר Cloud Service Mesh by example: Authorization.

הסרת המשאבים

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

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

  gcloud container clusters delete  CLUSTER_NAME  \
      --project=PROJECT_ID \
      --zone=CLUSTER_LOCATION 
  

• אם רוצים לשמור את האשכול ולהסיר את הדוגמה Online Boutique:

  1. מוחקים את מרחבי השמות של האפליקציה:

  kubectl delete -f online-boutique/kubernetes-manifests/namespaces
  

  הפלט אמור להיראות כך:

  namespace "ad" deleted
  namespace "cart" deleted
  namespace "checkout" deleted
  namespace "currency" deleted
  namespace "email" deleted
  namespace "frontend" deleted
  namespace "loadgenerator" deleted
  namespace "payment" deleted
  namespace "product-catalog" deleted
  namespace "recommendation" deleted
  namespace "shipping" deleted
  

  1. מחיקת רשומות השירות:

  kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml
  

  הפלט אמור להיראות כך:

  serviceentry.networking.istio.io "allow-egress-googleapis" deleted
  serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
  

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

• מדריך כללי להגדרת מדיניות PeerAuthentication זמין במאמר הגדרת אבטחת תעבורה.