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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

שילוב של IAP עם Cloud Service Mesh

במדריך הזה מוסבר איך לשלב את Identity-Aware Proxy‏ (IAP) עם Cloud Service Mesh. השילוב של IAP עם Cloud Service Mesh מאפשר לכם לגשת לשירותים בצורה בטוחה על סמך העקרונות של BeyondCorp של Google. ה-IAP מאמת את זהות המשתמש ואת ההקשר של הבקשה כדי לקבוע אם צריך לאפשר למשתמש לגשת לאפליקציה או למשאב. השילוב של IAP עם Cloud Service Mesh מספק את היתרונות הבאים:

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

דרישות מוקדמות

פועלים לפי השלבים במאמר התקנת כלים תלויי-הקשר ואימות האשכול כדי:

בנוסף, אנחנו יוצאים מנקודת הנחה שיש לכם:

פרויקט. Google Cloud
חשבון לחיוב ב-Cloud.

הגדרת אשכול באמצעות Cloud Service Mesh

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

התקנות חדשות

מפעילים את iap.googleapis.com. בפקודה הבאה, מחליפים את PROJECT_ID בפרויקט שבו רוצים להתקין את Cloud Service Mesh:
```
gcloud services enable \
  --project=PROJECT_ID \
  iap.googleapis.com
```
צריך להגדיר את האפשרות --addons=HttpLoadBalancing באשכול שרוצים לעדכן. תוסף HttpLoadBalancing מאפשר להשתמש בבקר לאיזון עומסים מסוג HTTP (שכבה 7) עבור האשכול. מריצים את הפקודה הבאה כדי לעדכן את האשכול באפשרויות שנדרשות על ידי Cloud Service Mesh. אלא אם הגדרתם אזור או אזור זמן שמוגדרים כברירת מחדל, אתם צריכים לציין את האזור (‎--region=REGION) או את אזור הזמן (‎--zone=ZONE) בפקודה.
```
gcloud container clusters update CLUSTER_NAME \
  --project=PROJECT_ID \
  --update-addons=HttpLoadBalancing=ENABLED
```
כברירת מחדל, ביציאה 31223 של קובץ iap-operator.yaml מוגדר סטטוס, וביציאה 31224 מוגדר HTTP. אם היציאה 31223 כבר בשימוש באשכול, מריצים את הפקודה הבאה כדי להגדיר יציאת סטטוס אחרת:

חשוב: צריך להשתמש בגרסה של kpt שקודמת לגרסה v1.0.
```
kpt cfg set asm gcloud.container.cluster.ingress.statusPort STATUS_PORT
```
אם יציאה 31224 כבר נמצאת בשימוש באשכול, מריצים את הפקודה הבאה כדי להגדיר יציאת http אחרת:
```
kpt cfg set asm gcloud.container.cluster.ingress.httpPort HTTP_PORT
```
פועלים לפי השלבים במאמר התקנה של תכונות ברירת מחדל ו-Mesh CA כדי להשתמש בסקריפט שסופק על ידי Google להתקנת Cloud Service Mesh. כשמריצים את הסקריפט, צריך לכלול את האפשרות הבאה:
```
--option iap-operator
```
לדוגמה:
```
./asmcli install \
  --project_id "PROJECT_ID" \
  --cluster_name "CLUSTER_NAME" \
  --cluster_location "CLUSTER_LOCATION" \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --option iap-operator
```
כשמתקינים את Cloud Service Mesh, הקובץ iap-operator.yaml מגדיר את השדה type בשירות istio-ingressgateway לערך NodePort, וכך מגדיר את השער לפתיחת יציאה ספציפית ברשת שירותים. כך תוכלו להגדיר מאזן עומסים שינתב את התנועה שנשלחת לשם הדומיין שלכם ליציאה הזו.
אם אתם מתקינים את Cloud Service Mesh מנוהל, אתם צריכים גם לבצע את השלבים הבאים:
1. מוסיפים את תווית הגרסה למרחב השמות istio-system.
2. מורידים את מפרט השירות של שער הכניסה של Istio עבור IAP ונותנים לו את השם iap_operator.yaml.
3. מתקינים את ה-ingress כשירות NodePort.
```
asmcli experimental mcp-migrate-check -f iap_operator.yaml

istioctl install -f /asm-generated-configs/gateways-istiooperator/"GATEWAY_NAME".yaml
```

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

שדרוגים

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

כבר הגדרתם את השילוב של IAP ואתם משדרגים את Cloud Service Mesh. במקרה כזה, כבר הפעלתם את iap.googleapis.com בפרויקט ואת התוסף HttpLoadBalancing באשכול. אפשר לדלג לשלב 3 כדי להוריד את חבילת asm ולשדרג את Cloud Service Mesh.
אתם משדרגים את Cloud Service Mesh ורוצים להגדיר את השילוב עם IAP בפעם הראשונה. במקרה כזה, צריך לבצע את כל השלבים הבאים, לשדרג את Cloud Service Mesh ולחזור למדריך הזה אחרי השדרוג כדי להשלים את השילוב.

מפעילים את iap.googleapis.com. בפקודה הבאה, מחליפים את PROJECT_ID בפרויקט שבו רוצים להתקין את Cloud Service Mesh.
```
gcloud services enable \
  --project=PROJECT_ID \
  iap.googleapis.com
```
צריך להגדיר את האפשרות --addons=HttpLoadBalancing באשכול שרוצים לעדכן. תוסף HttpLoadBalancing מאפשר להשתמש בבקר לאיזון עומסים מסוג HTTP (שכבה 7) עבור האשכול. מריצים את הפקודה הבאה כדי לעדכן את האשכול באפשרויות שנדרשות על ידי Cloud Service Mesh. אלא אם הגדרתם אזור או אזור זמן שמוגדרים כברירת מחדל, אתם צריכים לציין את האזור (‎--region=REGION) או את אזור הזמן (‎--zone=ZONE) בפקודה.
```
gcloud container clusters update CLUSTER_NAME \
  --project=PROJECT_ID
  --update-addons=HttpLoadBalancing=ENABLED
```

אם אתם מעדכנים מאזן עומסים קיים של HTTP Cloud Load Balancer שפועל, מריצים את הפקודה הבאה כדי לשמור על יציאות ה-HTTP והסטטוס הקיימות:

kpt cfg set asm gcloud.container.cluster.ingress.httpPort $(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

kpt cfg set asm gcloud.container.cluster.ingress.statusPort $(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="status-port")].nodePort}')

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

כשמשדרגים את Cloud Service Mesh, הקובץ iap-operator.yaml מגדיר את השדה type בשירות istio-ingressgateway לערך NodePort, וכך שער הכניסה מוגדר לפתוח יציאה ספציפית ב-Service Mesh. כך תוכלו להגדיר מאזן עומסים שינתב את התנועה שנשלחת לשם הדומיין שלכם ליציאה הזו.

כברירת מחדל, ביציאה 31223 של קובץ iap-operator.yaml מוגדר סטטוס, וביציאה 31224 מוגדר HTTP.

כשמריצים את הסקריפט, צריך לכלול את האפשרות הבאה:
```
--option iap-operator
```
לדוגמה:
```
./asmcli install \
  --project_id "PROJECT_ID" \
  --cluster_name "CLUSTER_NAME" \
  --cluster_location "CLUSTER_LOCATION" \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --option iap-operator
```
כדי להשלים את השדרוג, מפעילים הוספה אוטומטית של קובץ עזר חיצוני לעומסי העבודה. פרטים נוספים זמינים במאמר בנושא פריסה ופריסה מחדש של עומסי עבודה.

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

שמירת כתובת IP קבועה והגדרת DNS

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

שמירת כתובת IP חיצונית סטטית:

gcloud compute addresses create example-static-ip --global

מקבלים את כתובת ה-IP הסטטית:

gcloud compute addresses describe example-static-ip --global

ברשם שמות הדומיינים שלכם, הגדירו שם דומיין שמוגדר במלואו (FQDN) עם כתובת ה-IP הסטטית. בדרך כלל, מוסיפים רשומת A להגדרות ה-DNS. השלבים והטרמינולוגיה להוספת רשומה של FQDN משתנים בהתאם לרשם שמות הדומיינים.A

יכולות לחלוף 24 עד 48 שעות עד שהגדרת ה-DNS תתעדכן. אפשר להמשיך להגדיר את הכול לפי ההוראות במדריך הזה, אבל לא תוכלו לבדוק את ההגדרה עד שהגדרות ה-DNS יתעדכנו.

פריסת אפליקציה לדוגמה

לפני שמפעילים את IAP, צריך להפעיל אפליקציה באשכול GKE כדי לוודא שלכל הבקשות יש זהות. במדריך הזה נעשה שימוש בדוגמה Bookinfo כדי להדגים איך להגדיר את איזון העומסים של HTTP(S) ולהפעיל את IAP.

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

בקשות חיצוניות

משאב השער של Bookinfo (מוגדר ב-samples/bookinfo/networking/bookinfo-gateway.yaml) משתמש ב-istio-ingressgateway שהוגדר מראש. תזכורת: כשפרסתם את Cloud Service Mesh, ציינתם NodePort בשדה istio-ingressgateway, וכך פתחתם יציאה ספציפית ב-Service Mesh. למרות שלצמתים באשכול יש כתובות IP חיצוניות, בקשות שמגיעות מחוץ לאשכול נחסמות על ידי כללי חומת האש Google Cloud . כשמשתמשים ב-IAP, הדרך הנכונה לחשוף אפליקציות לאינטרנט הציבורי היא באמצעות מאזן עומסים. אל תחשפו את כתובות הצמתים באמצעות כללים בחומת האש, כי זה יגרום לעקיפה של IAP.

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

הפעלת IAP

כדי להפעיל את IAP, צריך לפעול לפי השלבים הבאים.

הגדרת מסך ההסכמה

כדי לבדוק אם כבר יש מותג, משתמשים בפקודה list. יכול להיות לכם רק מותג אחד לכל פרויקט.
```
gcloud iap oauth-brands list
```
זוהי דוגמה לתגובה ב-gcloud אם המותג קיים:
```
name: projects/[PROJECT_NUMBER]/brands/[BRAND_ID]
applicationTitle: [APPLICATION_TITLE]
supportEmail: [SUPPORT_EMAIL]
orgInternalOnly: true
```
הערה: אם כבר קיים מותג בפרויקט והוא הוגדר למשתמשים חיצוניים (orgInternalOnly: false), אבל אתם רוצים להגביל אותו למשתמשים פנימיים, אתם צריכים לבצע את השינוי הזה באופן ידני ממסך ההסכמה ל-OAuth כדי ליצור לקוחות OAuth באמצעות ה-API הזה.
אם אין מותג, משתמשים בפקודה create:
```
gcloud iap oauth-brands create --application_title=APPLICATION_TITLE --support_email=SUPPORT_EMAIL
```
השדות הבאים הם שדות חובה כשקוראים ל-API הזה:
- ‫supportEmail: כתובת האימייל לתמיכה שמוצגת במסך הסכמה ל-OAuth. כתובת האימייל יכולה להיות כתובת של משתמש או כתובת אימייל חלופית של קבוצות Google. לחשבונות שירות יש גם כתובת אימייל, אבל אלה לא כתובות אימייל אמיתיות ותקינות, ואי אפשר להשתמש בהן כשיוצרים מותג. עם זאת, חשבון שירות יכול להיות הבעלים של קבוצה ב-Google. יוצרים קבוצת Google חדשה או מגדירים קבוצה קיימת ומגדירים את חשבון השירות הרצוי כבעלים של הקבוצה.
  
  הערה: המשתמש ששולח את הבקשה חייב להיות הבעלים של כתובת האימייל שצוינה לתמיכה.
- ‫applicationTitle: השם של האפליקציה שמוצג במסך ההסכמה ל-OAuth.
התשובה מכילה את השדות הבאים:
```
name: projects/[PROJECT_NUMBER]/brands/[BRAND_ID]
applicationTitle: [APPLICATION_TITLE]
supportEmail: [SUPPORT_EMAIL]
orgInternalOnly: true
```

יצירת לקוח OAuth של IAP

משתמשים בפקודה create כדי ליצור לקוח. משתמשים במותג name מהשלב הקודם.

gcloud iap oauth-clients create projects/PROJECT_NUMBER/brands/BRAND-ID --display_name=NAME

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

name: projects/[PROJECT_NUMBER]/brands/[BRAND_NAME]/identityAwareProxyClients/[CLIENT_ID]
secret: [CLIENT_SECRET]
displayName: [NAME]

משתמשים במזהה הלקוח (CLIENT_ID בשלב הקודם) וב-CLIENT_SECRET כדי להפעיל את IAP. יוצרים סוד של Kubernetes עם החומרים מלקוח ה-OAuth:
```
kubectl create secret generic -n istio-system my-secret --from-literal=client_id=CLIENT_ID \
--from-literal=client_secret=CLIENT_SECRET
```

פריסת מאזן העומסים

אתם יכולים להשתמש במשאב Ingress כדי ליצור מאזן עומסים מסוג HTTP(S) עם אישורי SSL שהוגדרו באופן אוטומטי. אישורי SSL מנוהלים מוקצים, מתחדשים ומנוהלים עבור הדומיין שלכם.

יוצרים משאב ManagedCertificate. במשאב הזה מצוין הדומיין של אישור ה-SSL. הרשימה spec.domains חייבת להכיל רק דומיין אחד. אין תמיכה בדומיינים עם תו כללי לחיפוש. ב-YAML הבא, מחליפים את DOMAIN_NAME בשם הדומיין שהגדרתם לכתובת ה-IP החיצונית הסטטית.
```
cat <<EOF | kubectl apply -f -
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: example-certificate
  namespace: istio-system
spec:
  domains:
    - DOMAIN_NAME
EOF
```

יוצרים משאב BackendConfig. המשאב הזה מנחה את GCLB איך לבצע בדיקות תקינות ב-Ingress Gateway, וגם איך להגדיר Identity-Aware Proxy. קודם כל, אוספים כמה ערכים מ-Ingress Gateway לגבי בדיקות תקינות:

יציאת הכניסה לבדיקת התקינות: זוהי יציאת בדיקת התקינות של istio-ingress.

export HC_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="status-port")].nodePort}')

נתיב הכניסה של בדיקת התקינות: זהו נתיב בדיקת התקינות של istio-ingress.

export HC_INGRESS_PATH=$(kubectl get pods -n istio-system -l app=istio-ingressgateway -o jsonpath='{.items[0].spec.containers[?(@.name=="istio-proxy")].readinessProbe.httpGet.path}')

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 2
    timeoutSec: 1
    healthyThreshold: 1
    unhealthyThreshold: 10
    port: ${HC_INGRESS_PORT}
    type: HTTP
    requestPath: ${HC_INGRESS_PATH}
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret
EOF

מוסיפים הערה לשירות ה-ingress עם BackendConfig.

    kubectl annotate -n istio-system service/istio-ingressgateway --overwrite \
      cloud.google.com/backend-config='{"default": "http-hc-config"}' \
      cloud.google.com/neg='{"ingress":false}'

יוצרים את מאזן העומסים על ידי הגדרת משאב Ingress.
- מגדירים את ההערה networking.gke.io/managed-certificates לשם האישור שיצרתם בשלב הקודם, example-certificate.
- מגדירים את ההערה kubernetes.io/ingress.global-static-ip-name לשם של כתובת ה-IP הסטטית שהזמנתם, example-static-ip.
- מגדירים את serviceName ל-istio-ingressgateway, שמשמש במשאב Gateway בדוגמה של Bookinfo.
```
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: istio-system
  annotations:
    kubernetes.io/ingress.global-static-ip-name: example-static-ip
    networking.gke.io/managed-certificates: example-certificate
spec:
  defaultBackend:
    service:
      name: istio-ingressgateway
      port:
        number: 80
EOF
```
הערה: יכול להיות שיחלפו 10-20 דקות עד שמאזן העומסים יפעל.
במסוף Google Cloud , נכנסים לדף Kubernetes Engine > Services & Ingress.

מעבר לדף Services & Ingress

ההודעה 'יצירת תעבורה נכנסת' אמורה להופיע בעמודה סטטוס. לפני שממשיכים, צריך לחכות עד ש-GKE יקצה את כל המשאבים ל-Ingress. כדי לראות את הסטטוס העדכני ביותר של ה-Ingress, צריך לרענן את הדף כל כמה דקות. אחרי שה-Ingress מוקצה, יכול להיות שיוצג הסטטוס Ok או השגיאה All backend services are in UNHEALTHY state. אחד המשאבים שמוקצים ב-GKE הוא בדיקת תקינות שמוגדרת כברירת מחדל. אם רואים את הודעת השגיאה, זה מצביע על כך שה-Ingress הוקצה ושהבדיקה של ברירת המחדל של תקינות הפעולה בוצעה. אם הסטטוס הוא 'Ok' או שמופיעה שגיאה, ממשיכים לקטע הבא כדי להגדיר את בדיקות התקינות של מאזן העומסים.

הגדרת רשימת הגישה לרכישות מתוך האפליקציה

מוסיפים משתמש למדיניות הגישה של IAP:

gcloud beta iap web add-iam-policy-binding \
    --member=user:EMAIL_ADDRESS \
    --role=roles/iap.httpsResourceAccessor

כאשר EMAIL_ADDRESS היא כתובת האימייל המלאה של המשתמש, למשל alice@example.com.

בודקים את מאזן העומסים. מפנים את הדפדפן לכתובת:
```
http://DOMAIN_NAME/productpage
```
כאשר DOMAIN_NAME הוא שם הדומיין שהגדרתם עם כתובת ה-IP החיצונית הסטטית.

אמור להופיע productpage של האפליקציה Bookinfo. אם תרעננו את הדף כמה פעמים, תראו גרסאות שונות של ביקורות, שמוצגות בסדר סיבובי: כוכבים אדומים, כוכבים שחורים, ללא כוכבים.

כדאי גם לבדוק את הגישה ל-https Bookinfo.

הפעלת תמיכה ב-RCToken ב-Service mesh

כברירת מחדל, IAP יוצר JSON Web Token (JWT) בהיקף של לקוח OAuth. ב-Cloud Service Mesh, אפשר להגדיר את IAP כך שיפיק RequestContextToken ‏ (RCToken), שהוא JWT אבל עם קהל שניתן להגדרה. בעזרת RCToken אפשר להגדיר את קהל היעד של ה-JWT למחרוזת שרירותית, שאפשר להשתמש בה במדיניות של Cloud Service Mesh להרשאות גרנולריות.

כדי להגדיר את ה-RCToken:

יוצרים משתנה סביבה לקהל של RCToken. זו יכולה להיות כל מחרוזת שרוצים.
```
export RCTOKEN_AUD="your-rctoken-aud"
```
אופציונלי: בשלב הבא נדרש התוסף BACKEND_SERVICE_ID. אם אתם צריכים לגלות את BACKEND_SERVICE_ID, מריצים את הפקודה הבאה:
```
kubectl -n istio-system get Ingress example-ingress -o json | jq \
 '.metadata.annotations."ingress.kubernetes.io/backends"'
```
הפלט הצפוי דומה ל-"{\"BACKEND_SERVICE_ID\":\"HEALTHY\"}". לדוגמה, "ingress.kubernetes.io/backends": "{\"k8s-be-31224--51f3b55cd1457fb6\":\"HEALTHY\"}". ה-BACKEND_SERVICE_ID בדוגמה הזו הוא k8s-be-31224--51f3b55cd1457fb6.

מאחזרים את הגדרות הרכישה הקיימות מתוך האפליקציה.

gcloud iap settings get --format json \
--project=${PROJECT_ID} --resource-type=compute --service=BACKEND_SERVICE_ID > iapSettings.json

מעדכנים את IapSettings עם קהל היעד של RCToken.

cat iapSettings.json | jq --arg RCTOKEN_AUD_STR $RCTOKEN_AUD \
'. + {applicationSettings: {csmSettings: {rctokenAud: $RCTOKEN_AUD_STR}}}' \
> updatedIapSettings.json

gcloud iap settings set updatedIapSettings.json --format json \
--project=${PROJECT_ID} --resource-type=compute --service=BACKEND_SERVICE_ID

מפעילים אימות RCToken בשער הכניסה של Istio.

cat <<EOF | kubectl apply -f -
apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: "ingressgateway-jwt-policy"
  namespace: "istio-system"
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  jwtRules:
  - issuer: "https://cloud.google.com/iap"
    jwksUri: "https://www.gstatic.com/iap/verify/public_key-jwk"
    audiences:
    - $RCTOKEN_AUD
    fromHeaders:
    - name: ingress-authorization
      prefix: "Istio "
    outputPayloadToHeader: "verified-jwt"
    forwardOriginalToken: true
EOF

אופציונלי: מוודאים שבקשות שלא כוללות JWT תקין נדחות:

  cat <<EOF | kubectl apply -f -
  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    name: iap-gateway-require-jwt
    namespace: istio-system
  spec:
    selector:
      matchLabels:
        app: istio-iap-ingressgateway
    action: DENY
    rules:
      - from:
          - source:
              notRequestPrincipals: ["*"]
  EOF

מוודאים שהבקשות אל Bookinfo productpage עדיין מצליחות:
```
http://DOMAIN_NAME/productpage
```

כדי לבדוק את המדיניות:

יוצרים אובייקט בקשה IapSettings, אבל מגדירים את rctokenAud למחרוזת אחרת:

cat iapSettings.json | jq --arg RCTOKEN_AUD_STR wrong-rctoken-aud \
'. + {applicationSettings: {csmSettings: {rctokenAud: $RCTOKEN_AUD_STR}}}' \
> wrongIapSettings.json

קוראים ל-API‏ IapSettings כדי להגדיר את קהל היעד של ה-RCToken.

gcloud beta iap settings set wrongIapSettings.json --project=PROJECT_ID --resource-type=compute --service=BACKEND_SERVICE

שולחים בקשה אל Bookinfo productpage והיא אמורה להיכשל:
```
http://DOMAIN_NAME/productpage
```

סידור וארגון

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

מחיקת האישור המנוהל:

kubectl delete managedcertificates example-certificate

מוחקים את ה-Ingress, וכך משחררים את משאבי איזון העומסים:
```
kubectl -n istio-system delete ingress example-ingress
```
מוחקים את כתובת ה-IP הסטטית:
```
gcloud compute addresses delete example-static-ip --global
```
אם תעשו את זה, הקפידו למחוק את כתובת ה-IP מרשם הדומיין.
מוחקים את האשכול, וכך נמחקים גם המשאבים שמרכיבים את האשכול, כמו מופעי המחשוב, הדיסקים ומשאבי הרשת:
```
gcloud container clusters delete CLUSTER_NAME
```