אימות לממשקי API של Google Cloud מעומסי עבודה של צי עם אמון משותף

בדף הזה מוסבר איך להגדיר את האפליקציות כך שיבצעו אימות ל-Google Cloud APIs כמו Compute Engine API או AI Platform API מציים שיש להם מודל אמון משותף. אם בצי שלכם יש מודל אמון מעורב, תוכלו לקרוא את המאמר אימות ל-API מתוך עומסי עבודה בצי עם מודל אמון מעורב (גרסת Preview). Google Cloud

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

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

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

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

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

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

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

    • הגרסה העדכנית של Google Cloud CLI, שכוללת את gcloud, כלי שורת הפקודה לאינטראקציה עם Google Cloud.
    • kubectl

    אם אתם משתמשים ב-Cloud Shell כסביבת המעטפת שלכם לאינטראקציה עם Google Cloud, הכלים האלה מותקנים בשבילכם.

  • מוודאים שאתחלתם את ה-CLI של gcloud לשימוש בפרויקט.

הכנת האשכולות

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

GKE

באשכולות GKE, מבצעים את הפעולות הבאות:

  1. אם היא עדיין לא מופעלת, צריך להפעיל את איחוד זהויות של עומסי עבודה ל-GKE באשכול Google Kubernetes Engine.
  2. רושמים את האשכול ב-Fleet.

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

מקבצים מחוץ Google Cloud

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

  • ‫Google Distributed Cloud (תוכנה בלבד) ב-VMware
  • ‫Google Distributed Cloud (תוכנה בלבד) בשרת פיזי
  • ‫GKE ב-AWS
  • ‫GKE ב-Azure

אשכולות מצורפים

אשכולות מצורפים של EKS ו-AKS שנרשמו באמצעות GKE Multi-Cloud API נרשמים עם איחוד שירותי אימות הזהות של עומסי עבודה של Fleet שמופעל כברירת מחדל. אפשר לרשום אשכולות מצורפים אחרים עם איחוד שירותי אימות הזהות של עומסי עבודה מופעל אם הם עומדים בדרישות הנדרשות. פועלים לפי ההוראות לסוג האשכול שמופיעות במאמר בנושא רישום אשכול.

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

בשלבים הבאים מוסבר איך להגדיר עומס עבודה באשכול רשום לשימוש באיחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet:

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

    gcloud container fleet memberships describe MEMBERSHIP_ID \
    --project=FLEET_PROJECT_ID \
    --format="table(authority.identityProvider,authority.workloadIdentityPool,name)"

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

    • ‫MEMBERSHIP_ID: השם של החברות באשכול. זה בדרך כלל השם של האשכול.
    • ‫FLEET_PROJECT_ID: מזהה הפרויקט המארח של הצי.

    הפלט אמור להיראות כך:

    IDENTITY_PROVIDER: IDENTITY_PROVIDER
WORKLOAD_IDENTITY_POOL: WORKLOAD_IDENTITY_POOL
NAME: projects/FLEET_PROJECT_ID/locations/MEMBERSHIP_LOCATION/memberships/MEMBERSHIP_ID

    הפלט הזה כולל את המידע הבא:

    • ‫IDENTITY_PROVIDER: ספק הזהויות של האשכול.
    • ‫MEMBERSHIP_LOCATION: המיקום של החברות ב-Fleet. בדרך כלל זהה למיקום האשכול.
    • ‫WORKLOAD_IDENTITY_POOL: השם של מאגר הזהויות של עומסי העבודה שמשויך לצי. הערך הזה כולל את התחביר FLEET_PROJECT_ID.svc.id.goog.

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

    kubectl create namespace NAMESPACE

    מחליפים את NAMESPACE בשם של מרחב השמות.

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

    kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE

    מחליפים את KSA_NAME בשם של ServiceAccount.

  4. שומרים את קובץ המניפסט הבא בשם adc-config-map.yaml. ה-ConfigMap הזה מכיל את הגדרות ה-ADC לעומסי עבודה.

    kind: ConfigMap
apiVersion: v1
metadata:
  namespace: NAMESPACE
  name: my-cloudsdk-config
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "credential_source": {
        "file": "/var/run/secrets/tokens/gcp-ksa/token"
      }
    }

  5. פורסים את ה-ConfigMap:

    kubectl create -f adc-config-map.yaml

  6. שומרים את קובץ המניפסט הבא בשם workload-config.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace:  NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  containers:
  - name: sample-container
    image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    env:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
    volumeMounts:
    - name: gcp-ksa
      mountPath: /var/run/secrets/tokens/gcp-ksa
      readOnly: true
  volumes:
  - name: gcp-ksa
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          path: token
          audience: WORKLOAD_IDENTITY_POOL
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
          - key: "config"
            path: "google-application-credentials.json"

    כשפורסים את עומס העבודה הזה, הנפח gcp-ksa ב-Pod מכיל את הנתונים הבאים:

    הקונטיינר ב-Pod מטמיע את הווליום gcp-ksa בנתיב /var/run/secrets/tokens/gcp-ksa ומגדיר את ADC לחפש את קובץ ה-JSON של הגדרות פרטי הכניסה בנתיב הזה.

  7. פורסים את עומס העבודה:

    kubectl apply -f workload-config.yaml

אפשרות חלופית: התחזות לחשבון שירות של IAM

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

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

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

    gcloud container fleet memberships describe MEMBERSHIP_ID \
    --project=FLEET_PROJECT_ID \
    --format="table(authority.identityProvider,authority.workloadIdentityPool,name)"

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

    • ‫MEMBERSHIP_ID: השם של החברות באשכול. זה בדרך כלל השם של האשכול.
    • ‫FLEET_PROJECT_ID: מזהה הפרויקט המארח של הצי.

    הפלט אמור להיראות כך:

    IDENTITY_PROVIDER: IDENTITY_PROVIDER
WORKLOAD_IDENTITY_POOL: WORKLOAD_IDENTITY_POOL
NAME: projects/FLEET_PROJECT_ID/locations/MEMBERSHIP_LOCATION/memberships/MEMBERSHIP_ID

    הפלט הזה כולל את המידע הבא:

    • ‫IDENTITY_PROVIDER: ספק הזהויות של האשכול.
    • ‫MEMBERSHIP_LOCATION: המיקום של החברות. בדרך כלל זה אותו מיקום כמו המיקום של האשכול.
    • ‫WORKLOAD_IDENTITY_POOL: השם של מאגר הזהויות של עומסי העבודה שמשויך לצי. הערך הזה כולל את התחביר FLEET_PROJECT_ID.svc.id.goog.

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

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

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

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

  3. נותנים לחשבון השירות ב-IAM את ההרשאות שנדרשות לו כדי לגשת ל-API של Google Cloud על ידי הוספה של כללי מדיניות ההרשאה הנדרשים ב-IAM. אפשר לעשות זאת באמצעות gcloud iam service-accounts add-iam-policy-binding או שיטה אחרת. במאמר הסבר על תפקידים מפורטת רשימה מלאה של תפקידים מוגדרים מראש עם ההרשאות הנדרשות. אפשר גם לעיין במסמכי התיעוד של כל שירות כדי לראות אילו הרשאות נדרשות לשימוש בממשקי API של Google Cloud .

  4. יוצרים ServiceAccount ב-Kubernetes במרחב שמות. אפשר גם להשתמש ב-ServiceAccount קיים של Kubernetes ובכל מרחב שמות, כולל ServiceAccount של default ומרחב השמות של default.

    kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE

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

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

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

    gcloud iam service-accounts add-iam-policy-binding IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \
    --project=IAM_SA_PROJECT_ID \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:WORKLOAD_IDENTITY_POOL[NAMESPACE/KSA_NAME]"

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

  6. שומרים את קובץ המניפסט הבא בשם adc-config-map.yaml. ה-ConfigMap הזה מכיל את הגדרות ה-ADC לעומסי עבודה.

    kind: ConfigMap
apiVersion: v1
metadata:
  namespace: K8S_NAMESPACE
  name: my-cloudsdk-config
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER",
      "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/IAM_SA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "credential_source": {
        "file": "/var/run/secrets/tokens/gcp-ksa/token"
      }
    }

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

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

  7. שומרים את קובץ המניפסט הבא בשם workload-config.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace:  K8S_NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  containers:
  - name: my-container
    image: my-image
    command: ["sleep","infinity"]
    env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
    volumeMounts:
    - name: gcp-ksa
      mountPath: /var/run/secrets/tokens/gcp-ksa
      readOnly: true
  volumes:
  - name: gcp-ksa
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          path: token
          audience: WORKLOAD_IDENTITY_POOL
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
            - key: "config"
              path: "google-application-credentials.json"

    כשפורסים את עומס העבודה הזה, הנפח gcp-ksa ב-Pod מכיל את הנתונים הבאים:

    הקונטיינר ב-Pod מטמיע את הווליום gcp-ksa בנתיב /var/run/secrets/tokens/gcp-ksa ומגדיר את ADC לחפש את קובץ ה-JSON של הגדרות פרטי הכניסה בנתיב הזה.

  8. פורסים את עומס העבודה:

    kubectl apply -f workload-config.yaml

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

בקטע הזה יוצרים קטגוריה של Cloud Storage וניגשים אליה מ-Pod שמשתמש באיחוד שירותי אימות הזהויות של עומסי עבודה בצי. לפני שמבצעים את השלבים האלה, צריך לוודא שהגדרתם את איחוד שירותי אימות הזהות של עומסי עבודה בהתאם להוראות שבקטע שימוש באיחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet באפליקציות.

בקטע הזה לא מוסבר איך לאמת את איחוד שירותי אימות הזהות של עומסי עבודה באמצעות שיטת ההתחזות לחשבון שירות של IAM.

  1. מאתרים את מספר הפרויקט:

    gcloud projects describe FLEET_PROJECT_ID \
    --format="value(projectNumber)"

    הפלט אמור להיראות כך:

    1234567890

  2. יוצרים קטגוריה של Cloud Storage:

    gcloud storage buckets create gs://FLEET_PROJECT_ID-test-bucket \
    --location=LOCATION

    מחליפים את LOCATION במיקום Google Cloud.

  3. יוצרים מדיניות הרשאה ב-IAM שמעניקה גישה לדלי לחשבון השירות שיצרתם:

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

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

    • ‫FLEET_PROJECT_NUMBER: מספר הפרויקט.
    • FLEET_PROJECT_ID: מזהה הפרויקט.
    • ‫NAMESPACE: השם של מרחב השמות של Kubernetes שבו פועל ה-Pod מהקטע הקודם.
    • ‫KSA_NAME: השם של חשבון השירות ב-Kubernetes שה-Pod מהקטע הקודם משתמש בו.

  4. יוצרים סשן של מעטפת ב-Pod:

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

  5. מנסים להציג את רשימת האובייקטים בקטגוריה:

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

    הפלט שיתקבל:

    {
  "kind": "storage#objects"
}

אימות מהקוד

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

C++

רוב ספריות הלקוח ב-C++‎ תומכות באיחוד שירותי אימות הזהות באמצעות אובייקט ChannelCredentials שנוצר בקריאה ל-grpc::GoogleDefaultCredentials().Google Cloud כדי לאתחל את פרטי הכניסה האלה, צריך ליצור את ספריות הלקוח ב-gRPC בגרסה 1.36.0 ואילך.

בספריית הלקוח ב-Cloud Storage ל-C++‎ נעשה שימוש ב-API בארכיטקטורת REST ולא ב-gRPC, ולכן אין בה תמיכה באיחוד שירותי אימות הזהות.

Go

ספריות לקוח ל-Go תומכות באיחוד שירותי אימות הזהות אם נעשה בהן שימוש במודול golang.org/x/oauth2 בגרסה 00.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 יש תמיכה באיחוד שירותי אימות הזהות אם נעשה בהן שימוש בחבילת google-auth-library בגרסה 7.0.2 ואילך.

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

מה השלב הבא?

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