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

במדריך הזה מוסבר איך להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה כדי לאפשר לעומסי עבודה שפועלים ב-Azure Kubernetes Service ‏ (AKS), ב-Amazon Elastic Kubernetes Service או באשכול Kubernetes באירוח עצמי לבצע אימות ב- Google Cloud.

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

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

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

לפני שמגדירים את איחוד שירותי אימות הזהות של עומסי עבודה, צריך לוודא שקלאסטר Kubernetes עומד בקריטריונים הבאים:

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

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

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

1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

   תפקידים שנדרשים כדי לבחור או ליצור פרויקט

   • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
   • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

   כניסה לדף לבחירת הפרויקט

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

2. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

מפעילים את ממשקי ה-API של IAM,‏ מנהל המשאבים,‏ Service Account Credentials ו-Security Token Service.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

הפעלת ממשקי ה-API

הגדרת מיפוי של מאפיין ותנאי

אסימוני ServiceAccount של Kubernetes מכילים כמה הצהרות, כולל ההצהרות הבאות:

• ‫sub: מכיל את מרחב השמות והשם של חשבון השירות – לדוגמה, system:serviceaccount:NAMESPACE:KSA_NAME, כאשר NAMESPACE הוא מרחב השמות של חשבון השירות ו-KSA_NAME הוא השם של חשבון השירות.
• ‫"kubernetes.io".namespace: מכיל את מרחב השמות של ServiceAccount.
• ‫"kubernetes.io".serviceaccount.name: מכיל את השם של חשבון השירות.
• ‫"kubernetes.io".pod.name: מכיל את השם של ה-pod.

כדי להשתמש ב-sub כמזהה נושא (google.subject) ב- Google Cloud, צריך להשתמש במיפוי הבא:

google.subject=assertion.sub

אפשר גם למפות מאפיינים נוספים (אופציונלי). לאחר מכן אפשר לקרוא למאפיינים האלה כשמקצים גישה למשאבים. לדוגמה:

google.subject=assertion.sub,
attribute.namespace=assertion['kubernetes.io']['namespace'],
attribute.service_account_name=assertion['kubernetes.io']['serviceaccount']['name'],
attribute.pod=assertion['kubernetes.io']['pod']['name']

אפשר גם להגדיר תנאי למאפיין. תנאים למאפיינים הם ביטויים ב-CEL שאפשר לבדוק בהם טענת נכוֹנוּת (assertion) ומאפייני יעד. אם התנאי למאפיין מקבל ערך של true לגבי פרטי כניסה מסוימים, הפרטים האלה מאושרים. אחרת, פרטי הכניסה נדחים.

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

assertion['kubernetes.io']['namespace'] in ['backend', 'monitoring']

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

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

מתן גישה לעומס עבודה (workload) של Kubernetes

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

צריך לבצע את השלבים האלה פעם אחת לכל עומס עבודה של Kubernetes שצריך גישה אל Google Cloud.

מומלץ להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה. עם זאת, כשמשתמשים באיחוד שירותי אימות הזהות, יכול להיות שיהיו מגבלות על שיטות מסוימות של API. רשימת המגבלות זמינה במאמר איחוד שירותי אימות הזהות: מוצרים ומגבלות.

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

שימוש באיחוד שירותי אימות הזהויות של עומסי עבודה כדי להעניק גישה ישירה למשאבים

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

כדי ליצור חשבון שירות ב-Kubernetes ולהקצות לו תפקיד:

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

   kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
   

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

   • ‫KSA_NAME: השם של ServiceAccount.
   • ‫NAMESPACE: מרחב השמות שבו רוצים ליצור את חשבון השירות.

2. נותנים לחשבון השירות של Kubernetes גישה ל-IAM עבורGoogle Cloud משאב.

   בהתאם לעקרון ההרשאות המינימליות, מומלץ להעניק רק תפקידים שספציפיים למשאבים שהאפליקציה צריכה לגשת אליהם.

   בדוגמה הבאה, הפקודה מקצה את התפקיד 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/POOL_ID/subject/MAPPED_SUBJECT \
       --condition=None
   

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

   • ‫PROJECT_NUMBER: המספרGoogle Cloud של הפרויקט שמשויך למזהה הפרויקט.

   • ‫POOL_ID: המזהה של מאגר הזהויות של עומסי העבודה.

   • ‫MAPPED_SUBJECT: חשבון השירות של Kubernetes מההצהרה באסימון המזהה שמיפיתם ל-google.subject. לדוגמה, אם מיפיתם את google.subject=assertions.sub וטוקן המזהה מכיל "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount", אז MAPPED_SUBJECT הוא system:serviceaccount:default:my-kubernetes-serviceaccount.

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

עכשיו אפשר לפרוס עומס עבודה שמשתמש ב-Kubernetes ServiceAccount כדי לגשת למשאבי Google Cloud שנתתם להם גישה.

חלופה: שימוש בהתחזות לחשבון שירות ב-IAM כדי להעניק גישה

כדי להגדיר את חשבון השירות של Kubernetes כך שישתמש בהתחזות לחשבון שירות של IAM, מבצעים את הפעולות הבאות:

1. אם עדיין לא עשיתם זאת, יוצרים Kubernetes ServiceAccount:

   kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
   

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

   • KSA_NAME: שם לחשבון השירות
   • ‫NAMESPACE: מרחב השמות שבו רוצים ליצור את ServiceAccount

2. יוצרים חשבון שירות ב-IAM שמייצג את עומס העבודה.

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

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

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

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

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

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

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

   • ‫IAM_SA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את חשבון השירות
   • IAM_SA_NAME: השם של חשבון השירות
   • ‫ROLE: עם שם התפקיד, למשל roles/container.clusterViewer

4. נותנים לחשבון השירות של Kubernetes גישה להתחזות לחשבון השירות של IAM:

   gcloud iam service-accounts add-iam-policy-binding \
     IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MAPPED_SUBJECT" \
       --role=roles/iam.workloadIdentityUser
   
   

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

   • IAM_SA_NAME: השם של חשבון השירות
   • ‫PROJECT_ID: מזהה הפרויקט שבו מריצים את Kubernetes
   • ‫IAM_SA_PROJECT_NUMBER: מספר הפרויקט שבו יצרתם את חשבון השירות
   • ‫POOL_ID: המזהה של מאגר הזהויות של עומסי העבודה.
   • ‫MAPPED_SUBJECT: חשבון השירות של Kubernetes מההצהרה באסימון המזהה שמיפיתם ל-google.subject. לדוגמה, אם מיפיתם את google.subject=assertions.sub וטוקן המזהה מכיל "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount", אז MAPPED_SUBJECT הוא system:serviceaccount:default:my-kubernetes-serviceaccount.

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

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

פריסת עומס העבודה של Kubernetes

כדי לפרוס עומס עבודה ב-Kubernetes שיכול לגשת למשאבים Google Cloud , מבצעים את הפעולות הבאות:

1. יוצרים קובץ תצורה של פרטי הכניסה:

   gcloud iam workload-identity-pools create-cred-config \
       projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
       --service-account=SERVICE_ACCOUNT_EMAIL \
       --credential-source-file=/var/run/service-account/token \
       --credential-source-type=text \
       --sts-location=REGION \
       --output-file=credential-configuration.json

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

   • PROJECT_NUMBER: מספר הפרויקט שמכיל את מאגר הזהויות של עומסי עבודה
   • ‫POOL_ID: המזהה של מאגר זהויות של עומסי עבודה
   • WORKLOAD_PROVIDER_ID: מזהה הספק של מאגר הזהויות של כוח העבודה
   • ‫SERVICE_ACCOUNT_EMAIL: כתובת האימייל של חשבון השירות, אם הגדרתם את חשבון השירות של Kubernetes להשתמש בהתחזות לחשבון שירות של IAM. לא מציינים את הדגל הזה אם הגדרתם את Kubernetes ServiceAccount לשימוש בגישה ישירה למשאבים.
   • ‫REGION: אופציונלי. מציינים את האזור של נקודות הקצה האזוריות של Security Token Service, אם הן זמינות.

   קובץ ההגדרות של פרטי הכניסה מאפשר לספריות הלקוח ב-Cloud, ל-CLI של gcloud ול-Terraform לקבוע את הפרטים הבאים:

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

2. ייבוא של קובץ הגדרות פרטי הכניסה כ-ConfigMap

   kubectl create configmap CONFIGMAP_NAME \
     --from-file credential-configuration.json \
     --namespace NAMESPACE
   

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

   • ‫CONFIGMAP_NAME: השם של ConfigMap.
   • ‫NAMESPACE: מרחב השמות שבו ייצור ה-ConfigMap.

3. פורסים עומס עבודה ומאפשרים לו להשתמש ב-ServiceAccount וב-ConfigMap של Kubernetes.

   יוצרים קובץ מניפסט ומגדירים אותו באופן הבא:

   • מטמיעים כרך אסימונים מוקרן כדי שעומס העבודה יוכל לקבל אסימון של חשבון שירות ב-Kubernetes מקובץ מקומי. מגדירים את אמצעי האחסון כך שהאסימון של Kubernetes ServiceAccount ישתמש בקהל שספק מאגר הזהויות של עומס העבודה מצפה לו.
   • מטמיעים את ה-ConfigMap שמכיל את קובץ התצורה של פרטי הכניסה, כדי שעומס העבודה יוכל לגשת להגדרות הנדרשות לשימוש באיחוד שירותי אימות הזהות של עומסי עבודה.
   • מוסיפים משתנה סביבה GOOGLE_APPLICATION_CREDENTIALS שמכיל את הנתיב של קובץ התצורה של פרטי הכניסה, כדי שעומסי העבודה יוכלו למצוא את הקובץ.

   זוהי דוגמה למניפסט שמשתמש ב-ServiceAccount וב-ConfigMap של Kubernetes כדי לאפשר ל-Google Cloud CLI לבצע אימות אל Google Cloud:

   apiVersion: v1
   kind: Pod
   metadata:
     name: example
     namespace: NAMESPACE
   spec:
     containers:
     - name: example
       image: google/cloud-sdk:alpine
       command: ["/bin/sh", "-c", "gcloud auth login --cred-file $GOOGLE_APPLICATION_CREDENTIALS && gcloud auth list && sleep 600"]
       volumeMounts:
       - name: token
         mountPath: "/var/run/service-account"
         readOnly: true
       - name: workload-identity-credential-configuration
         mountPath: "/etc/workload-identity"
         readOnly: true
       env:
       - name: GOOGLE_APPLICATION_CREDENTIALS
         value: "/etc/workload-identity/credential-configuration.json"
   
     serviceAccountName: KSA_NAME
     volumes:
     - name: token
       projected:
         sources:
         - serviceAccountToken:
             audience: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID
             expirationSeconds: 3600
             path: token
     - name: workload-identity-credential-configuration
       configMap:
         name: CONFIGMAP_NAME

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

   C++‎

   ספריות הלקוח של C++‎ תומכות באיחוד שירותי אימות הזהות של עומסי עבודה החל מגרסה v2.6.0.Google Cloud כדי להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה, צריך ליצור את ספריות הלקוח ב-gRPC בגרסה 1.36.0 ואילך.

   המשך

   ספריות לקוח ל-Go תומכות באיחוד שירותי אימות הזהות של עומסי עבודה אם נעשה בהן שימוש במודול golang.org/x/oauth2 בגרסה v0.0.0-20210218202405-ba52d332ba99 ואילך.

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

   cd $GOPATH/src/cloud.google.com/go
   go list -m golang.org/x/oauth2
   

   Java

   ספריות לקוח של Java תומכות באיחוד שירותי אימות הזהות של עומסי עבודה אם הן משתמשות בארטיפקט com.google.auth:google-auth-library-oauth2-http בגרסה 0.24.0 ואילך.

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

   mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
   

   Node.js

   ספריות לקוח של Node.js תומכות באיחוד שירותי אימות הזהות של עומסי עבודה אם הן משתמשות בגרסה 7.0.2 ואילך של חבילת google-auth-library.

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

   npm list google-auth-library
   

   כשיוצרים אובייקט GoogleAuth, אפשר לציין מזהה פרויקט או לאפשר ל-GoogleAuth לאתר את מזהה הפרויקט באופן אוטומטי. כדי לאתר את מזהה הפרויקט באופן אוטומטי, צריך להקצות לחשבון השירות בקובץ התצורה את התפקיד דפדפן (roles/browser) או תפקיד עם הרשאות דומות בפרויקט. לפרטים נוספים, ראו README לחבילת google-auth-library.

   Python

   ספריות לקוח של Python תומכות באיחוד שירותי אימות הזהות של עומסי עבודה אם הן משתמשות בחבילת google-auth בגרסה 1.27.0 ואילך.

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

   pip show google-auth
   

   כדי לציין מזהה פרויקט ללקוח האימות, תוכלו להגדיר את משתנה הסביבה GOOGLE_CLOUD_PROJECT או לאפשר ללקוח למצוא את מזהה הפרויקט באופן אוטומטי. כדי לאתר את מזהה הפרויקט באופן אוטומטי, צריך להקצות לחשבון השירות בקובץ התצורה את התפקיד דפדפן (roles/browser) או תפקיד עם הרשאות דומות בפרויקט. לפרטים נוספים, ראו מדריך למשתמש לחבילת google-auth.

   gcloud

   כדי לבצע אימות באמצעות איחוד שירותי אימות הזהות של עומסי עבודה, משתמשים בפקודה gcloud auth login:

   gcloud auth login --cred-file=FILEPATH.json
   

   מחליפים את FILEPATH בנתיב לקובץ התצורה של פרטי הכניסה.

   ב-CLI של gcloud יש תמיכה באיחוד שירותי אימות הזהות של עומסי עבודה ב-CLI של gcloud בגרסה 363.0.0 ואילך.

   Terraform

   יש תמיכה באיחוד שירותי אימות הזהות של עומסי עבודה אם משתמשים בספקGoogle Cloud בגרסה 3.61.0 ואילך:

   terraform {
     required_providers {
       google = {
         source  = "hashicorp/google"
         version = "~> 3.61.0"
       }
     }
   }
   

   BQ

   כדי לבצע אימות באמצעות איחוד שירותי אימות הזהויות של עומסי עבודה, משתמשים בפקודה gcloud auth login:

   gcloud auth login --cred-file=FILEPATH.json
   

   מחליפים את FILEPATH בנתיב לקובץ התצורה של פרטי הכניסה.

   ב-bq, יש תמיכה באיחוד שירותי אימות הזהויות של עומסי עבודה ב-CLI של gcloud בגרסה 390.0.0 ואילך.

4. אפשר גם להריץ את הפקודה הבאה כדי לוודא שהאימות פועל כמו שצריך:

   kubectl exec example --namespace NAMESPACE -- gcloud auth print-access-token

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

• מידע נוסף על איחוד שירותי אימות הזהות של עומסי עבודה
• שיטות מומלצות לשימוש באיחוד שירותי אימות הזהות של עומסי עבודה
• איך אפשר לבצע ניהול ספקים ומאגרים של זהויות של עומסי עבודה