אימות ל-Google Cloud APIs מעומסי עבודה ב-GKE

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

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

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

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

הפעלת איחוד זהויות של עומסי עבודה ל-GKE באשכולות ובמאגרי צמתים

ב-Autopilot, איחוד זהויות של עומסי עבודה ל-GKE תמיד מופעל. אפשר לדלג אל הקטע הגדרת אפליקציות לשימוש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE.

ב-Standard, מפעילים את איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE באשכולות ובמאגרי צמתים באמצעות Google Cloud CLI או Google Cloud המסוף. חובה להפעיל איחוד זהויות של עומסי עבודה ל-GKE ברמת האשכול לפני שמפעילים איחוד זהויות של עומסי עבודה ל-GKE במאגרי צמתים.

אפשר להפעיל איחוד זהויות של עומסי עבודה ל-GKE באשכול קיים מסוג Standard באמצעות ה-CLI של gcloud או Google Cloud המסוף. מאגרי צמתים קיימים לא מושפעים, אבל כל מאגר צמתים חדש באשכול משתמש באיחוד זהויות של עומסי עבודה ל-GKE.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. כדי להפעיל איחוד זהויות של עומסי עבודה ל-GKE באשכול קיים, מריצים את הפקודה הבאה:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog

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

    • ‫CLUSTER_NAME: השם של האשכול הקיים.
    • ‫LOCATION: המיקום של Compute Engine של האשכול.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

    3. המסוף

    כדי להפעיל איחוד זהויות של עומסי עבודה ל-GKE באשכול קיים:

    1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

      מעבר אל Google Kubernetes Engine

    2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

    3. בדף הפרטים של האשכול, בקטע אבטחה, לוחצים על עריכת Workload Identity.

    4. בתיבת הדו-שיח Edit Workload Identity, מסמנים את התיבה Enable Workload Identity.

    5. לוחצים על שמירת השינויים.

העברת עומסי עבודה קיימים אל איחוד זהויות של עומסי עבודה ל-GKE

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

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

שיטה מומלצת:

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

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

gcloud container node-pools create NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-metadata=GKE_METADATA

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

  • ‫NODEPOOL_NAME: השם של מאגר הצמתים החדש.
  • ‫CLUSTER_NAME: השם של האשכול הקיים שמופעל בו איחוד זהויות של עומסי עבודה ל-GKE.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

הדגל --workload-metadata=GKE_METADATA מגדיר את מאגר הצמתים לשימוש בשרת המטא-נתונים של GKE.

שיטה מומלצת:

צריך לכלול את הדגל כדי שיצירת מאגר הצמתים תיכשל אם איחוד הזהויות של עומסי עבודה ל-GKE לא מופעל באשכול.

עדכון של מאגר צמתים קיים

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

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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

    gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-metadata=GKE_METADATA

    אם איחוד זהויות של עומסי עבודה ל-GKE מופעל באשכול, אפשר להשבית אותו באופן סלקטיבי במאגר צמתים ספציפי על ידי ציון מפורש של --workload-metadata=GCE_METADATA. מידע נוסף זמין במאמר בנושא הגנה על מטא-נתונים של אשכול.

    3. המסוף

    כדי לשנות מאגר צמתים קיים כך שישתמש באיחוד זהויות של עומסי עבודה ל-GKE, מבצעים את השלבים הבאים:

    1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

      מעבר אל Google Kubernetes Engine

    2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

    3. לוחצים על הכרטיסייה Nodes.

    4. בקטע Node Pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים שרוצים לשנות.

    5. בדף פרטים של מאגר הצמתים, לוחצים על עריכה.

    6. בדף Edit node pool (עריכת מאגר הצמתים), בקטע Security (אבטחה), מסמנים את התיבה Enable GKE Metadata Server (הפעלת שרת המטא-נתונים של GKE).

    7. לוחצים על Save.

הגדרת אפליקציות לשימוש באיחוד זהויות של עומסי עבודה ל-GKE

כדי לאפשר לאפליקציות GKE לבצע אימות ל-APIs באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, צריך ליצור כללי מדיניות של IAM עבור ה-APIs הספציפיים. Google Cloudחשבון המשתמש במדיניות הזו הוא מזהה חשבון משתמש ב-IAM שתואם לעומסי העבודה, למרחבי השמות או לחשבונות השירות של Kubernetes. התהליך הזה מחזיר אסימון גישה מאוחד שאפשר להשתמש בו בעומס העבודה בקריאות ל-API.

אפשר גם להגדיר חשבונות שירות ב-Kubernetes להתחזות לחשבונות שירות ב-IAM. כך, GKE ימיר את אסימון הגישה המאוחד לאסימון גישה מ-IAM Service Account Credentials API. פרטים נוספים זמינים בקטע אפשרות חלופית: קישור חשבונות שירות של Kubernetes ל-IAM.

הגדרת הרשאות וגורמים מאשרים

  1. מקבלים פרטי כניסה לאשכול:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

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

    • ‫CLUSTER_NAME: השם של האשכול שבו מופעל איחוד זהויות של עומסי עבודה ל-GKE.
    • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

  2. יוצרים מרחב שמות לשימוש בחשבון השירות של Kubernetes. אפשר גם להשתמש במרחב השמות default או בכל מרחב שמות קיים.

    kubectl create namespace NAMESPACE

  3. יוצרים חשבון שירות ב-Kubernetes לשימוש האפליקציה. אפשר גם להשתמש בכל חשבון שירות קיים ב-Kubernetes בכל מרחב שמות. אם לא מקצים ServiceAccount לעומס העבודה, Kubernetes מקצה את default ServiceAccount במרחב השמות.

    kubectl create serviceaccount KSA_NAME \
    --namespace NAMESPACE

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

    • ‫KSA_NAME: השם של חשבון השירות החדש של Kubernetes.
    • ‫NAMESPACE: השם של מרחב השמות ב-Kubernetes עבור חשבון השירות.

  4. יוצרים מדיניות הרשאה ב-IAM שמפנה אל KubernetesServiceAccount. מומלץ להעניק הרשאות למשאבים ספציפיים שאפליקציה צריכה לגשת אליהם.Google Cloud כדי ליצור כללי מדיניות למתן הרשאה בפרויקט, צריכות להיות לכם הרשאות IAM רלוונטיות.

    לדוגמה, הפקודה הבאה מעניקה את התפקיד Kubernetes Engine Cluster Viewer ‏(roles/container.clusterViewer) לחשבון השירות שיצרתם:

    gcloud projects add-iam-policy-binding projects/PROJECT_ID \
    --role=roles/container.clusterViewer \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME \
    --condition=None

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫PROJECT_NUMBER: מספר הפרויקט Google Cloud.

    אפשר להקצות תפקידים לכל Google Cloud משאב שתומך במדיניות הרשאות של IAM. התחביר של מזהה חשבון המשתמש תלוי במשאב Kubernetes. רשימת המזהים הנתמכים מופיעה במאמר מזהים של חשבונות משתמשים באיחוד זהויות של עומסי עבודה ל-GKE.

אופציונלי: הגדרת אפשרויות של Service mesh

אם אתם משתמשים ב-Istio או ב-Cloud Service Mesh כדי לנהל את הסביבה, מוסיפים את ההערה הבאה לשדה metadata.annotations במפרט ה-Pod:

metadata:
  annotations:
    proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'

ההערה הזו מונעת מהקונטיינרים להתחיל עד שהפרוקסי של Service mesh מוכן להפניית תנועה מהאפליקציות שלכם.

אימות ההגדרה של איחוד זהויות של עומסי עבודה ל-GKE

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

  1. יוצרים קטגוריה ריקה ב-Cloud Storage:

    gcloud storage buckets create gs://BUCKET

    מחליפים את BUCKET בשם של הקטגוריה החדשה.

  2. מקצים את התפקיד צפייה באובייקט אחסון (roles/storage.objectViewer) לחשבון השירות שיצרתם:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME \
    --condition=None

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫PROJECT_NUMBER: מספר הפרויקט Google Cloud.
    • ‫NAMESPACE: מרחב השמות של Kubernetes שמכיל את חשבון השירות.
    • ‫KSA_NAME: השם של ServiceAccount.

  3. שומרים את קובץ המניפסט הבא בשם test-app.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  containers:
  - name: test-pod
    image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    resources:
      requests:
        cpu: 500m
        memory: 512Mi
        ephemeral-storage: 10Mi

  4. באשכולות Standard בלבד, מוסיפים את הערכים הבאים לשדה template.spec כדי למקם את ה-Pods במאגרי צמתים שמשתמשים באיחוד זהויות של עומסי עבודה ל-GKE.

    באשכולות Autopilot, אפשר לדלג על השלב הזה כי כל צומת משתמש באיחוד זהויות של עומסי עבודה ל-GKE, ולכן הצומת דוחה את nodeSelector.

    spec:
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"

  5. מחילים את התצורה על האשכול:

    kubectl apply -f test-app.yaml

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

    kubectl get pods --namespace=NAMESPACE

    כשה-Pod מוכן, הפלט אמור להיראות כך:

    NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          5m27s

  7. פותחים סשן של מעטפת ב-Pod:

    kubectl exec -it pods/test-pod --namespace=NAMESPACE -- /bin/bash

  8. כדי לקבל רשימה של אובייקטים בקטגוריה:

    curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://storage.googleapis.com/storage/v1/b/BUCKET/o"

    הפלט שיתקבל:

    {
  "kind": "storage#objects"
}

    הפלט הזה מראה של-Pod יש גישה לאובייקטים בקטגוריה.

חלופה: קישור של חשבונות שירות של Kubernetes ל-IAM

שיטה מומלצת:

משתמשים במזהים של ישויות מורשות ב-IAM כדי להגדיר איחוד זהויות של עומסי עבודה ל-GKE. עם זאת, לזהות המאוחדת הזו יש מגבלות ספציפיות לכל API נתמך של Google Cloud . אם המגבלות האלה חלות עליכם, אתם יכולים לפעול לפי השלבים הבאים כדי להגדיר גישה לממשקי ה-API האלה מעומסי העבודה שלכם ב-GKE.

  1. יוצרים מרחב שמות של Kubernetes:

    kubectl create namespace NAMESPACE

  2. יוצרים חשבון שירות של Kubernetes:

    kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE

  3. יוצרים חשבון שירות ב-IAM. אפשר גם להשתמש בכל חשבון שירות קיים של IAM בכל פרויקט בארגון.

    gcloud iam service-accounts create IAM_SA_NAME \
    --project=IAM_SA_PROJECT_ID

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

    • ‫IAM_SA_NAME: שם לחשבון השירות החדש ב-IAM.
    • ‫IAM_SA_PROJECT_ID: מזהה הפרויקט של חשבון השירות שלכם ב-IAM.

    מידע על מתן הרשאה לחשבונות שירות ב-IAM לגשת לממשקי API זמין במאמר הסבר על חשבונות שירות. Google Cloud

  4. מקצים לחשבון השירות ב-IAM את התפקידים שהוא צריך ב- Google Cloud API ספציפיים:

    gcloud projects add-iam-policy-binding IAM_SA_PROJECT_ID \
    --member "serviceAccount:IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com" \
    --role "ROLE_NAME"

    מחליפים את ROLE_NAME בשם התפקיד, למשל roles/spanner.viewer.

  5. יוצרים מדיניות הרשאות ב-IAM שנותנת ל-Kubernetes ServiceAccount גישה להתחזות לחשבון השירות ב-IAM:

    gcloud iam service-accounts add-iam-policy-binding IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"

    שם החבר חייב לכלול את מרחב השמות ואת שם חשבון השירות של Kubernetes. לדוגמה, serviceAccount:example-project.svc.id.goog[example-namespace/example-serviceaccount].

  6. מוסיפים הערה ל-Kubernetes ServiceAccount כדי ש-GKE יראה את הקישור בין חשבונות השירות:

    kubectl annotate serviceaccount KSA_NAME \
    --namespace NAMESPACE \
    iam.gke.io/gcp-service-account=IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com

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

  7. אופציונלי: מוסיפים הערה ל-ServiceAccount של Kubernetes כדי שהאפליקציות יקבלו את המזהה בתחביר של מזהה חשבון המשתמש ב-IAM:

    kubectl annotate serviceaccount KSA_NAME \
    --namespace=NAMESPACE \
    iam.gke.io/return-principal-id-as-email="true"

שימוש באיחוד זהויות של עומסי עבודה ל-GKE מהקוד

התהליך של אימות לשירותי Google Cloud מהקוד זהה לתהליך של אימות באמצעות שרת המטא-נתונים של Compute Engine. כשמשתמשים באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, הבקשות שלכם לשרת המטא-נתונים של המופע מנותבות אל שרת המטא-נתונים של GKE. קוד קיים שמבצע אימות באמצעות שרת המטא-נתונים של המופע (למשל קוד שמשתמש בספריות הלקוח שלGoogle Cloud ) אמור לפעול בלי שינויים.

שימוש במכסה מפרויקט אחר עם איחוד זהויות של עומסי עבודה ל-GKE

באשכולות שמופעלת בהם גרסה 1.24 של GKE ואילך, אפשר להגדיר באופן אופציונלי את חשבון השירות של Kubernetes כך שישתמש במכסת פרויקט אחר Google Cloud כשמבצעים קריאות לשיטות GenerateAccessToken ו-GenerateIdToken ב-IAM Service Account Credentials API. כך תוכלו להימנע משימוש במכסה כולה בפרויקט הראשי, ובמקום זאת להשתמש במכסה מפרויקטים אחרים עבור השירותים האלה באשכול.

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

  1. מעניקים לחשבון השירות של Kubernetes את ההרשאה serviceusage.services.use בפרויקט של המכסה.

    gcloud projects add-iam-policy-binding QUOTA_PROJECT_ID \
    --role=roles/serviceusage.serviceUsageConsumer \
    --member='principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME' \

    מחליפים את QUOTA_PROJECT_ID במזהה הפרויקט לצורכי מכסה.

  2. מוסיפים הערה לחשבון השירות של Kubernetes עם פרויקט המכסה:

    kubectl annotate serviceaccount KSA_NAME \
    --namespace NAMESPACE \
    iam.gke.io/credential-quota-project=QUOTA_PROJECT_ID

כדי לוודא שההגדרה פועלת בצורה תקינה:

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

  2. שולחים בקשה לשרת המטא-נתונים:

    curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

  3. עוברים לדף IAM Service Accounts Credentials API במסוף Google Cloud בפרויקט המכסה:

    לדף APIs

  4. בודקים אם יש שינויים בתנועה.

הסרת המשאבים

כדי להפסיק להשתמש באיחוד זהויות של עומסי עבודה ל-GKE, צריך לבטל את הגישה לחשבון השירות של IAM ולהשבית את איחוד הזהויות של עומסי עבודה ל-GKE באשכול.

ביטול גישה

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

לדוגמה, כדי לבטל את הגישה למאגר ב-Artifact Registry, מריצים את הפקודה הבאה:

gcloud artifacts repositories remove-iam-policy-binding REPOSITORY_NAME \
    --location=REPOSITORY_LOCATION \
    --member='principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME' \
    --role='roles/artifactregistry.reader' \
    --all

השבתה של איחוד זהויות של עומסי עבודה ל-GKE

אפשר להשבית את איחוד הזהויות של עומסי עבודה ל-GKE רק באשכולות Standard.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. כדי להשבית את איחוד הזהויות של עומסי עבודה ל-GKE בכל מאגר צמתים:

    gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-metadata=GCE_METADATA

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

  3. משביתים את איחוד הזהויות של עומסי עבודה ל-GKE באשכול:

    gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --disable-workload-identity

    4. המסוף

    1. עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

      מעבר אל Google Kubernetes Engine

    2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

    3. לוחצים על הכרטיסייה Nodes.

    4. כדי להשבית את איחוד הזהויות של עומסי עבודה ל-GKE בכל מאגר צמתים, מבצעים את הפעולות הבאות לכל מאגר צמתים בקטע Node Pools:

      1. לוחצים על השם של מאגר הצמתים שרוצים לשנות.
      2. בדף פרטים של מאגר הצמתים, לוחצים על עריכה.
      3. בדף עריכת מאגר צמתים, בקטע אבטחה, מבטלים את הסימון בתיבת הסימון הפעלת שרת מטא-נתונים של GKE.
      4. לוחצים על Save.

    5. כדי להשבית את איחוד הזהויות של עומסי עבודה ל-GKE באשכול, מבצעים את הפעולות הבאות:

      1. לוחצים על הכרטיסייה פרטים.
      2. בקטע Security (אבטחה), ליד Workload Identity (זהות של עומס עבודה), לוחצים על Edit (עריכה).
      3. בתיבת הדו-שיח Edit Workload Identity, מבטלים את הסימון בתיבה Enable Workload Identity.
      4. לוחצים על שמירת השינויים.

השבתה של איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE בארגון

השלבים בקטע קישור חשבונות שירות של Kubernetes ל-IAM מאפשרים לחשבונות שירות של Kubernetes להתחזות לזהות של חשבון השירות המקושר ב-IAM. אפשר להחליף אסימוני API לטווח ארוך של Kubernetes ServiceAccounts באסימוני גישה לחשבון השירות התואם ב-IAM.

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

מידע נוסף זמין במאמר השבתת יצירת אשכולות של זהויות עומסי עבודה.

פתרון בעיות

מידע לפתרון בעיות זמין במאמר פתרון בעיות באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE.

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