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

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

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

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

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

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

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

• מוודאים ש-Workload Identity Federation for GKE תומך ב- Cloud de Confiance APIs שרוצים לגשת אליהם. רשימת ממשקי ה-API הנתמכים זמינה במאמר מוצרים נתמכים ומגבלות. אם ה-API לא נתמך או אם תרחיש השימוש שלכם חסום בגלל המגבלות של איחוד שירותי אימות הזהות של עומסי עבודה בשירות הזה, אפשר לעיין בקטע חלופה: קישור של חשבונות שירות ב-Kubernetes ל-IAM בדף הזה.

• מוודאים שהפעלתם את IAM Service Account Credentials API.

  הפעלת IAM Credentials API

• ודאו שיש לכם את תפקידי ה-IAM הבאים:

  • roles/container.admin
  • roles/iam.serviceAccountAdmin

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

• מוודאים שיש לכם אשכול קיים במצב Autopilot או במצב Standard. כדי ליצור אשכול חדש, אפשר לעיין במאמר בנושא יצירת אשכול Autopilot.

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

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

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

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

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

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

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

יצירת מאגר צמתים חדש

כל מאגרי הצמתים החדשים שאתם יוצרים מוגדרים כברירת מחדל לשימוש ב-Workload Identity Federation for 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 במישור הבקרה של האשכול, כמו us-central1 או us-central1-a.

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

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

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

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

כדי לאפשר לאפליקציות GKE לבצע אימות ל-APIs באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, צריך ליצור כללי מדיניות של IAM עבור ה-APIs הספציפיים. Cloud de Confianceחשבון המשתמש במדיניות הזו הוא מזהה חשבון משתמש ב-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 במישור הבקרה של האשכול, כמו us-central1 או us-central1-a.

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

   kubectl create namespace NAMESPACE
   

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

   kubectl create serviceaccount KSA_NAME \
       --namespace NAMESPACE
   

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

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

4. יוצרים מדיניות הרשאה ב-IAM שמפנה אל KubernetesServiceAccount. מומלץ להעניק הרשאות לCloud de Confiance משאבים ספציפיים שהאפליקציה צריכה לגשת אליהם. כדי ליצור כללי מדיניות של הרשאה בפרויקט, אתם צריכים את הרשאות ה-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.s3ns.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME \
       --condition=None
   

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

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

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

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

אם אתם משתמשים ב-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.s3ns.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME \
       --condition=None
   

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

   • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance .
   • ‫PROJECT_NUMBER: מספר הפרויקט Cloud de Confiance.
   • ‫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

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 זמין במאמר הסבר על חשבונות שירות. Cloud de Confiance by S3NS

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

   gcloud projects add-iam-policy-binding IAM_SA_PROJECT_ID \
       --member "serviceAccount:IAM_SA_NAME@IAM_SA_PROJECT_ID.s3ns.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.s3ns.iam.gserviceaccount.com \
       --role roles/iam.workloadIdentityUser \
       --member "serviceAccount:PROJECT_ID.s3ns.svc.id.goog[NAMESPACE/KSA_NAME]"
   

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

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

   kubectl annotate serviceaccount KSA_NAME \
       --namespace NAMESPACE \
       iam.gke.io/gcp-service-account=IAM_SA_NAME@IAM_SA_PROJECT_ID.s3ns.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 מהקוד

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

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

באשכולות שמופעלת בהם גרסה 1.24 של GKE ואילך, אתם יכולים להגדיר את חשבון השירות של Kubernetes כך שישתמש במכסת פרויקט אחר Cloud de Confiance כשמתבצעות קריאות לשיטות 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.s3ns.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 במסוף Cloud de Confiance של פרויקט המכסות:

   לדף 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.s3ns.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME' \
    --role='roles/artifactregistry.reader' \
    --all

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

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

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

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

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

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

פתרון בעיות

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

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

• מידע נוסף על איחוד זהויות של עומסי עבודה ל-GKE
• קריאת הסקירה הכללית על אבטחה ב-GKE
• מידע נוסף על חשבונות שירות ב-IAM