שילוב של 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 גלובליות.

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

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

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

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

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

התקנות חדשות

  1. מפעילים את iap.googleapis.com. בפקודה הבאה, מחליפים את PROJECT_ID בפרויקט שבו רוצים להתקין את Cloud Service Mesh:

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

    gcloud container clusters update CLUSTER_NAME \
      --project=PROJECT_ID \
      --update-addons=HttpLoadBalancing=ENABLED
    
  3. כברירת מחדל, בקובץ iap-operator.yaml מוגדרת יציאה 31223 כיציאת הסטטוס ויציאה 31224 כיציאת ה-HTTP. אם יציאה 31223 כבר בשימוש באשכול, מריצים את הפקודה הבאה כדי להגדיר יציאת סטטוס אחרת:

    kpt cfg set asm gcloud.container.cluster.ingress.statusPort STATUS_PORT
    

    אם היציאה 31224 כבר נמצאת בשימוש באשכול, מריצים את הפקודה הבאה כדי להגדיר יציאת HTTP אחרת:

    kpt cfg set asm gcloud.container.cluster.ingress.httpPort HTTP_PORT
    
  4. כדי להתקין את Cloud Service Mesh באמצעות סקריפט שסופק על ידי Google, פועלים לפי השלבים במאמר בנושא התקנה של תכונות ברירת מחדל ו-Mesh CA. כשמריצים את הסקריפט, צריך לכלול את האפשרות הבאה:

    --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, וכך מגדיר את שער הכניסה לפתיחת יציאה ספציפית ברשת שירותים. כך תוכלו להגדיר מאזן עומסים שינתב את התנועה שנשלחת לשם הדומיין שלכם ליציאה הזו.

  5. אם אתם מתקינים את 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 ולחזור למדריך הזה אחרי השדרוג כדי להשלים את השילוב.

  1. מפעילים את iap.googleapis.com. בפקודה הבאה, מחליפים את PROJECT_ID בפרויקט שבו רוצים להתקין את Cloud Service Mesh.

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

    gcloud container clusters update CLUSTER_NAME \
      --project=PROJECT_ID
      --update-addons=HttpLoadBalancing=ENABLED
    
  3. אם אתם מעדכנים מאזן עומסים קיים של 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}')
    
  4. כדי לשדרג את Cloud Service Mesh באמצעות סקריפט ש-Google מספקת, פועלים לפי השלבים שמפורטים במאמר שדרוג Cloud Service Mesh.

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

    כברירת מחדל, בקובץ iap-operator.yaml, יציאה 31223 מוגדרת כיציאת הסטטוס ויציאה 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
    
  5. כדי להשלים את השדרוג, מפעילים הזרקה אוטומטית של קובץ עזר חיצוני בעומסי העבודה. למידע נוסף, קראו את המאמר פריסה ופריסה מחדש של עומסי עבודה.

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

שמירת כתובת IP סטטית והגדרת DNS

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

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

    gcloud compute addresses create example-static-ip --global
    
  2. קבלת כתובת IP סטטית:

    gcloud compute addresses describe example-static-ip --global
    
  3. ברשם שמות הדומיינים, מגדירים שם דומיין שמוגדר במלואו (FQDN) עם כתובת ה-IP הסטטית. בדרך כלל, מוסיפים רשומת A להגדרות ה-DNS. השלבים והטרמינולוגיה להוספה של רשומת A ל-FQDN משתנים בהתאם לרשם שמות הדומיינים.

    יכולות לחלוף 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.

  1. כדי לבדוק אם כבר יש לכם מותג, משתמשים בפקודה list. יכול להיות לכם רק מותג אחד לכל פרויקט.

    gcloud iap oauth-brands list

    זוהי דוגמה לתגובה ב-gcloud אם המותג קיים:

    name: projects/[PROJECT_NUMBER]/brands/[BRAND_ID]
    applicationTitle: [APPLICATION_TITLE]
    supportEmail: [SUPPORT_EMAIL]
    orgInternalOnly: true
    
  2. אם לא קיים מותג, משתמשים בפקודה 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

  1. משתמשים בפקודה 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]
    
  2. משתמשים במזהה הלקוח (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 מנוהלים מוקצים, מחודשים ומנוהלים בשביל הדומיין שלכם.

  1. יוצרים משאב 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
  2. יוצרים משאב BackendConfig. המשאב הזה מורה ל-GCLB איך לבצע בדיקות תקינות ב-Ingress Gateway, וגם להגדיר את Identity-Aware Proxy. קודם כל, אוספים כמה ערכים מ-Ingress Gateway לגבי בדיקות תקינות:

    • יציאת Ingress של בדיקת התקינות: זוהי יציאת בדיקת התקינות של 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
  3. מוסיפים הערה לשירות ה-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}'
    
  4. יוצרים את מאזן העומסים על ידי הגדרת משאב ה-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
  5. במסוף Google Cloud , נכנסים לדף Kubernetes Engine > Services & Ingress.

    כניסה לדף Services & Ingress

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

הגדרת רשימת הגישה ל-IAP

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

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

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

  1. בודקים את מאזן העומסים. מזינים בדפדפן את הכתובת:

    http://DOMAIN_NAME/productpage

    כאשר DOMAIN_NAME הוא שם הדומיין שהגדרתם עם כתובת ה-IP החיצונית הסטטית.

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

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

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

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

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

  1. יוצרים משתנה סביבה לקהל של RCToken. זו יכולה להיות כל מחרוזת שרוצים.

    export RCTOKEN_AUD="your-rctoken-aud"
    
  2. אופציונלי: בשלב הבא נדרש התפקיד 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.

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

    gcloud iap settings get --format json \
    --project=${PROJECT_ID} --resource-type=compute --service=BACKEND_SERVICE_ID > iapSettings.json
    
  4. מעדכנים את 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
    
  5. מפעילים אימות 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
    
  6. אופציונלי: מוודאים שבקשות שלא כוללות 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
      

  7. מוודאים שהבקשות אל Bookinfo productpage עדיין מצליחות:

    http://DOMAIN_NAME/productpage

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

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

    cat iapSettings.json | jq --arg RCTOKEN_AUD_STR wrong-rctoken-aud \
    '. + {applicationSettings: {csmSettings: {rctokenAud: $RCTOKEN_AUD_STR}}}' \
    > wrongIapSettings.json
    
  2. קוראים ל-IapSettings API כדי להגדיר את קהל היעד של ה-RCtoken.

    gcloud beta iap settings set wrongIapSettings.json --project=PROJECT_ID --resource-type=compute --service=BACKEND_SERVICE
  3. שולחים בקשה אל Bookinfo productpage והיא אמורה להיכשל:

    http://DOMAIN_NAME/productpage

סידור וארגון

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

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

    kubectl delete managedcertificates example-certificate
  2. מוחקים את ה-Ingress, וכך מבטלים את ההקצאה של משאבי איזון העומסים:

    kubectl -n istio-system delete ingress example-ingress

  3. מחיקת כתובת ה-IP הסטטית:

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

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

  4. מוחקים את האשכול, וכך מוחקים את המשאבים שמרכיבים אותו, כמו מכונות וירטואליות, דיסקים ומשאבי רשת:

    gcloud container clusters delete CLUSTER_NAME