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

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

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

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

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

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

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

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

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

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

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

למשל, נבחן את התרחיש הבא:

  • יש לכם שני קלאסטרים של חברי צי: frontend-cluster ו-finance-cluster.
  • לא הגדרתם מאגר זהויות של עומסי עבודה בניהול עצמי.
  • יוצרים finance-team היקף צוות וfinance-ns מרחב שמות של צי בתוך היקף הצוות.
  • מקשרים את אשכול finance-cluster להיקף הצוות finance-team.
  • מקצים תפקיד IAM ל-finance-sa KubernetesServiceAccount במרחב השמות של צי finance-ns.

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

  • מריצים במרחב השמות של הצי finance-ns.
  • משתמשים ב-finance-sa ServiceAccount.

עם זאת, אם מישהו באשכול frontend-cluster יוצר מרחב שמות של finance-ns Kubernetes וחשבון שירות finance-sa, הוא מקבל את אותו זהות כמו עומסי העבודה באשכול finance-cluster. הסיבה לכך היא שכל צי המכונות משתמש במאגר הזהויות של עומסי העבודה שמנוהל על ידי Google בפרויקט המארח של צי המכונות, ומזהה הגורם המבצע לא מציין אשכול מארח.

נבחן את השינויים הבאים בתרחיש הקודם:

  • מגדירים מאגר זהויות של עומסי עבודה בניהול עצמי בצי.
  • מגדירים את אשכול finance-cluster כך שיקבל זהויות מהמאגר בניהול עצמי במקום מהמאגר בניהול Google.
  • יוצרים הענקת תפקיד ב-IAM שמציינת את המאגר בניהול עצמי במזהה החשבון הראשי במקום במאגר בניהול Google.

עומסי העבודה שפועלים במרחב השמות של צי finance-ns ב-finance-cluster מקבלים עכשיו זהות מהמאגר בניהול עצמי. עם זאת, ישויות במרחב השמות של finance-ns Kubernetes באשכול frontend-cluster ממשיכות לקבל זהויות ממאגר הזהויות של עומסי העבודה שמנוהל על ידי Google בפרויקט המארח של הצי.

השינויים האלה מניבים את היתרונות הבאים:

  • אתם יכולים להקצות תפקידים באופן מפורש לישויות במרחב השמות של finance-ns.
  • לגורמים באשכול frontend-cluster אין גישה זהה כי הזהויות באשכול frontend-cluster מגיעות ממאגר הזהויות של עומסי העבודה שמנוהל על ידי Google.

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

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

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

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

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

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

    gcloud iam workload-identity-pools create POOL_NAME \
    --location=global \
    --project=POOL_HOST_PROJECT_ID \
    --mode=TRUST_DOMAIN

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

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

  2. נותנים לסוכן השירות של צי הרכבים את התפקיד אדמין של מאגר זהויות של עומסי עבודה ב-IAM (roles/iam.workloadIdentityPoolAdmin) במאגר הזהויות החדש של עומסי העבודה:

    gcloud iam workload-identity-pools add-iam-policy-binding POOL_NAME \
    --project=POOL_HOST_PROJECT_ID \
    --location=global \
    --member=serviceAccount:service-FLEET_HOST_PROJECT_NUMBER@gcp-sa-gkehub.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityPoolAdmin \
    --condition=None

    מחליפים את FLEET_HOST_PROJECT_NUMBER במספר הפרויקט של הפרויקט המארח של הצי.

הוספת המאגר בניהול עצמי להגדרת הצי

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

  1. הפעלה של איחוד שירותי אימות הזהות של עומסי עבודה ברמת ה-Fleet:

    gcloud beta container fleet workload-identity enable \
  --project=FLEET_HOST_PROJECT_ID

    מחליפים את FLEET_HOST_PROJECT_ID במזהה הפרויקט המארח של הצי.

  2. מוסיפים את מאגר הזהויות של עומסי העבודה בניהול עצמי להגדרת ה-Fleet:

    gcloud beta container fleet workload-identity scope-tenancy-pool set POOL_NAME

    מחליפים את POOL_NAME בשם של מאגר הזהויות של עומסי העבודה בניהול עצמי. התחביר של הערך הזה הוא:

    POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

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

    gcloud container fleet scopes create SCOPE_NAME

    מחליפים את SCOPE_NAME בשם של היקף הצוות החדש.

  4. יוצרים מרחב שמות חדש של צי בטווח הצוות:

    gcloud container fleet scopes namespaces create NAMESPACE_NAME \
    --scope=SCOPE_NAME

    מחליפים את NAMESPACE_NAME בשם של מרחב השמות החדש של Fleet.

  5. מקשרים אשכול בצי להיקף הצוות:

    gcloud container fleet memberships bindings create BINDING_NAME \
    --membership=FLEET_CLUSTER_NAME \
    --location=global \
    --scope=SCOPE_NAME

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

    • ‫BINDING_NAME: השם של הקישור החדש לחברות.
    • ‫FLEET_CLUSTER_NAME: השם של אשכול הציים הקיים שאליו רוצים לקשר את ההיקף של הצוות.

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

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

  1. תארו את ההגדרה של החברות בצי:

    gcloud container fleet memberships describe FLEET_CLUSTER_NAME \
    --location=global

    מחליפים את FLEET_CLUSTER_NAME בשם של אשכול קיים של צי מכונות שקשור לכל היקף צוות בצי.

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

    authority:
...
  scopeTenancyIdentityProvider: https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME
  scopeTenancyWorkloadIdentityPool: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
  workloadIdentityPool: FLEET_HOST_PROJECT_ID.svc.id.goog
...

    הפלט הזה צריך לכלול את השדות הבאים:

    • ‫scopeTenancyIdentityProvider: ספק הזהויות לעומסי עבודה שפועלים במרחבי שמות של Fleet בהיקפי צוות. הערך הוא מזהה משאב של האשכול.
    • ‫scopeTenancyWorkloadIdentityPool: מאגר הזהויות של עומסי העבודה שממנו עומסי עבודה במרחבי שמות של fleet במסגרת היקפי צוות מקבלים מזהים. הערך הוא מאגר הזהויות של עומסי העבודה בניהול עצמי, בפורמט POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog.
    • ‫workloadIdentityPool: השם של מאגר הזהויות של עומסי העבודה שמנוהל על ידי Google בפרויקט המארח של ה-Fleet, שממנו כל עומסי העבודה האחרים ב-Fleet מקבלים זהויות כברירת מחדל.

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

    gcloud iam workload-identity-pools namespaces list \
    --workload-identity-pool=POOL_NAME \
    --location=global

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

    ---
description: Fleet namespace NAMESPACE_NAME
name: projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME/namespaces/NAMESPACE_NAME
state: ACTIVE

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

איך מגדירים שעומסי עבודה ישתמשו במאגרים בניהול עצמי לזהויות

כדי שעומסי עבודה ישתמשו במאגר בניהול עצמי, צריך להגדיר מרחבי שמות ספציפיים של צי ב клаסטרים של חברי הצי באמצעות Kubernetes ConfigMap. ההגדרה הזו, שמתבצעת ברמת האשכול ומרחב השמות, מאפשרת לצמצם עוד יותר את היקף ההרשאות שניתנות ממרחבי שמות של צי שלם לעומסי עבודה שפועלים במרחבי שמות ספציפיים של צי באשכולות ספציפיים.

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

    gcloud container clusters get-credentials FLEET_CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CLUSTER_LOCATION

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

    • ‫FLEET_CLUSTER_NAME: השם של אשכול חבר ב-Fleet שכבר משויך להיקף צוות.
    • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של פרויקט האשכול.
    • ‫CLUSTER_LOCATION: המיקום של האשכול.

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

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_workload_identity_pool"

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

    POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog

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

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_identity_provider"

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

    https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME

  4. בעורך טקסט, שומרים את מניפסט ה-YAML הבא של ConfigMap בתור self-managed-pool.yaml:

    kind: ConfigMap
apiVersion: v1
metadata:
  namespace: NAMESPACE_NAME
  name: google-application-credentials
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:SELF_MANAGED_POOL_FULL_NAME: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"
      }
    }

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

    • ‫NAMESPACE_NAME: השם של מרחב השמות של Fleet.
    • ‫SELF_MANAGED_POOL_FULL_NAME: השם המלא של מאגר הזהויות של עומסי העבודה בניהול עצמי, מתוך הפלט של השלבים הקודמים בקטע הזה. לדוגמה, example-pool.global.1234567890.workload.id.goog.
    • ‫IDENTITY_PROVIDER: שם ספק הזהויות מהפלט של השלבים הקודמים בקטע הזה. לדוגמה, https://gkehub.googleapis.com/projects/1234567890/locations/global/memberships/example-cluster.

  5. פורסים את ה-ConfigMap באשכול:

    kubectl create -f self-managed-pool.yaml

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

הענקת תפקידי IAM לחשבונות משתמשים

בקטע הזה יוצרים ServiceAccount של Kubernetes במרחב שמות של צי ומקצים תפקיד IAM ל-ServiceAccount. אחרי שמקצים את התפקיד, ל-Pods שמשתמשים ב-ServiceAccount הזה תהיה גישה למשאבי Google Cloud .

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

    kubectl create serviceaccount SERVICEACCOUNT_NAME \
    --namespace=NAMESPACE_NAME

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

    • ‫SERVICEACCOUNT_NAME: השם של חשבון השירות החדש.
    • ‫NAMESPACE_NAME: השם של מרחב השמות של Fleet.

  2. מקצים תפקיד ב-IAM לחשבון השירות. הפקודה הבאה לדוגמה מקצה את התפקיד Storage Object Viewer‏ (roles/storage.objectViewer) בקטגוריה לחשבון השירות ServiceAccount:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME \
    --role=roles/storage.objectViewer \
    --condition=None

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

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

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

  • ‫metadata.namespace: השם של מרחב השמות של Fleet.
  • ‫spec.serviceAccountName: השם של חשבון השירות ב-Kubernetes במרחב השמות של ה-fleet.
  • ‫spec.containers.env: משתנה סביבה בשם GOOGLE_APPLICATION_CREDENTIALS שמציין את הנתיב לקובץ Application Default Credentials‏ (ADC).
  • ‫spec.containers.volumeMounts: נפח לקריאה בלבד שמאפשר לקונטיינר להשתמש באסימון ה-Bearer עבור ServiceAccount.
  • ‫spec.volumes: נפח מוקרן שמעלה אסימון ServiceAccount ל-Pod. הקהל של האסימון הוא מאגר הזהויות של עומסי העבודה בניהול עצמי. ה-ConfigMap שמכיל את ההגדרה של איחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet הוא מקור לנפח.

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

אימות מתוך עומס עבודה

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

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

    gcloud storage buckets create gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --location=LOCATION \
    --project=FLEET_HOST_PROJECT_ID

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

    gcloud storage buckets add-iam-policy-binding gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --condition=None \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

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

    • ‫FLEET_HOST_PROJECT_NUMBER: מספר הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫POOL_NAME: השם של מאגר הזהויות של עומסי העבודה בניהול עצמי.
    • ‫NAMESPACE_NAME: השם של מרחב השמות של הצי שבו רוצים להפעיל את ה-Pod.
    • ‫SERVICEACCOUNT_NAME: השם של חשבון השירות ב-Kubernetes שה-Pod צריך להשתמש בו.

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

    apiVersion: v1
kind: Pod
metadata:
  name: bucket-access-pod
  namespace:  NAMESPACE_NAME
spec:
  serviceAccountName: SERVICEACCOUNT_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: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
          - key: "config"
            path: "google-application-credentials.json"

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

    • ‫NAMESPACE_NAME: השם של מרחב השמות של הצי שבו רוצים להפעיל את ה-Pod.
    • ‫SERVICEACCOUNT_NAME: השם של חשבון השירות ב-Kubernetes שה-Pod צריך להשתמש בו.
    • ‫POOL_NAME: השם של מאגר הזהויות של עומסי העבודה בניהול עצמי.
    • ‫FLEET_HOST_PROJECT_NUMBER: מספר הפרויקט של פרויקט המארח של ה-Fleet.

  4. פורסים את ה-Pod באשכול:

    kubectl apply -f pod-bucket-access.yaml

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

    kubectl exec -it bucket-access-pod -n NAMESPACE_NAME -- /bin/bash

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

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

    הפלט שיתקבל:

    {
  "kind": "storage#objects"
}

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

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

  3. פורסים Pod שמשתמש באותו ServiceAccount ובאותו מרחב שמות, אבל בשדה spec.volumes.projected.sources.serviceAccountToken שלו מצוין מאגר הזהויות של עומסי עבודה שמנוהל על ידי Google. המאגר הזה כולל את התחביר הבא:

    FLEET_HOST_PROJECT_ID.svc.id.goog

  4. מנסים לגשת לקטגוריה של Cloud Storage מתוך סשן של מעטפת ב-Pod.

הפלט צריך להיות שגיאה 401: Unauthorized, כי מזהה הגורם המוסמך של ה-Pod שמשתמש במאגר הזהויות של עומסי העבודה שמנוהל על ידי Google שונה ממזהה הגורם המוסמך של ה-Pod שמשתמש במאגר שמנוהל עצמאית.

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