הגדרת אימות מנוהל של Workload Identity ב-GKE

במאמר הזה מוסבר איך להגדיר זהויות מנוהלות של עומסי עבודה עבור Google Kubernetes Engine ‏ (GKE) באשכולות שמנוהלים על ידי GKE בצי GKE. בנוסף, מוסבר בו איך לפרוס עומס עבודה ולאמת את הזהות והאישור של עומס העבודה.

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

  1. הגדרת Certificate Authority Service להנפקת אישורים לזהויות מנוהלות של עומסי עבודה

  2. קישור רשויות האישורים למאגר הזהויות של עומסי העבודה.

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

  4. פריסת עומסי עבודה עם זהויות מנוהלות של עומסי עבודה.

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

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

  • ‫Google מנהלת את המאגר באופן מלא, כך שאי אפשר ליצור משאבי משנה כמו מרחבי שמות, זהויות או ספקי זהויות.

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

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

הגדרה של כמה פרויקטים

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

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

  1. Create or select a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  2. הסבר על זהויות מנוהלות של עומסי עבודה

  3. מוודאים שיש לפחות אשכול GKE אחד. מוודאים שהאשכולות פועלים בגרסה 1.33.0-gke.2248000 ואילך.

  4. מוסיפים את האשכולות ל-GKE fleets. אם האשכול שלכם הוא אשכול Autopilot, אל תכללו את --enable-workload-identity. ‫Fleets יוצר באופן אוטומטי מאגר זהויות של עומסי עבודה שמנוהל על ידי Google, ומשמש כדומיין אמון.

    מריצים את הפקודה הבאה כדי להפעיל את GKE fleets:

    gcloud container clusters update CLUSTER_NAME \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-fleet \
    --fleet-project=PROJECT_ID

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

    • ‫CLUSTER_NAME: שם אשכול GKE שרוצים לרשום ב-GKE Fleet
    • ‫PROJECT_ID: מזהה פרויקט המארח של ה-Fleet ב-GKE

  5. Enable the IAM and Certificate Authority Service APIs:

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles. 

    gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com

  6. מגדירים את Google Cloud CLI לשימוש בפרויקט החיוב והמכסות.

    gcloud config set billing/quota_project PROJECT_ID

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

התפקידים הנדרשים

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

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

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

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

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

אפשר להשתמש במאגרי CA Service כדי להגדיר את ההיררכיה הזו. בהיררכיה הזו, מאגר CA משני מנפיק לעומסי העבודה שלכם את אישורי הזהות של עומסי העבודה מסוג X.509.

הגדרת מאגר רשויות אישורים (CA) עליונות

כדי ליצור את מאגר רשויות האישורים הבסיסיות:

יוצרים את מאגר רשויות האישורים (CA) העליונות במסלול Enterprise באמצעות gcloud privateca pools create. השכבה הזו מיועדת להנפקת אישורים לטווח ארוך בכמויות קטנות.

gcloud privateca pools create ROOT_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=enterprise

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

  • ‫ROOT_CA_POOL_ID: מזהה ייחודי של מאגר CA הבסיסי. המזהה יכול להיות באורך של עד 64 תווים, והוא חייב להכיל רק תווים אלפאנומריים (אותיות קטנות וגדולות), קווים תחתונים או מקפים. מזהה המאגר חייב להיות ייחודי באזור.

  • ‫REGION: האזור שבו נמצא מאגר רשויות האישורים הבסיסיות.

  • ‫CA_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את רשות האישורים הבסיסית.

מידע נוסף על מאגרי CA, רמות ואזורים זמין במאמר יצירת מאגרי CA.

הגדרת רשות האישורים (CA) העליונה

יוצרים רשות אישורים (CA) עליונה במאגר רשויות האישורים העליונות באמצעות gcloud privateca roots create. יכול להיות שתתבקשו להפעיל את רשות האישורים הבסיסית אם זו רשות האישורים היחידה במאגר רשויות האישורים הבסיסיות.

כדי ליצור רשות אישורים (CA) בסיסית, מריצים את הפקודה הבאה:

gcloud privateca roots create ROOT_CA_ID \
    --pool=ROOT_CA_POOL_ID \
    --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --max-chain-length=1 \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --auto-enable

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

  • ROOT_CA_ID: שם ייחודי לרשות המאשרת הבסיסית. שם הרשות שמנפיקה את האישורים (CA) יכול להיות באורך של עד 64 תווים, והוא חייב להכיל רק תווים אלפאנומריים באותיות קטנות וגדולות, קווים תחתונים או מקפים. השם של ה-CA צריך להיות ייחודי באזור.
  • ‫ROOT_CA_POOL_ID: המזהה של מאגר רשויות האישורים הבסיסיות.
  • ‫ROOT_CA_CN: השם הנפוץ של רשות האישורים הבסיסית.
  • ‫ROOT_CA_ORGANIZATION: הארגון של רשות האישורים הבסיסית.
  • ‫KEY_ALGORITHM: אלגוריתם המפתח, לדוגמה, ec-p256-sha256
  • ‫REGION: האזור שבו נמצא מאגר רשויות האישורים הבסיסיות.
  • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים הבסיסית.

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

אפשר גם ליצור רשויות אישורי בסיס נוספות במאגר רשויות אישורי הבסיס. הפעולה הזו יכולה להיות שימושית לרוטציה של CA בסיסי.

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

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

  • תרחישים שונים להנפקת אישורים: אם יש לכם תרחישים שונים להנפקת אישורים, אתם יכולים ליצור CA משני לכל תרחיש.

  • איזון עומסים טוב יותר: הוספה של כמה רשויות אישורים משניות למאגר רשויות אישורים עוזרת להשיג איזון עומסים טוב יותר של בקשות לאישורים.

כדי ליצור מאגר של רשויות אישורים משניות ורשות אישורים משנית:

  1. יוצרים את מאגר רשויות האישורים המשניות ברמה DevOps, שמתאימה להנפקת אישורים לטווח קצר בכמות גדולה.

    gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=devops

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

    • SUBORDINATE_CA_POOL_ID: מזהה ייחודי של מאגר ה-CA המשני. המזהה יכול להכיל עד 64 תווים, והוא חייב לכלול רק תווים אלפאנומריים באותיות קטנות וגדולות, קווים תחתונים או מקפים. מזהה המאגר חייב להיות ייחודי באזור.
    • ‫REGION: האזור שבו ייצור מאגר ה-CA המשני.
    • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים המשנית.

    מידע נוסף זמין במאמר יצירת מאגרי CA.

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

    gcloud privateca subordinates create SUBORDINATE_CA_ID \
    --pool=SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --issuer-pool=ROOT_CA_POOL_ID \
    --issuer-location=REGION \
    --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --use-preset-profile=subordinate_mtls_pathlen_0 \
    --project=CA_PROJECT_ID \
    --auto-enable

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

    • ‫SUBORDINATE_CA_ID: שם ייחודי ל-CA המשני. השם יכול להיות באורך של עד 64 תווים והוא חייב להכיל רק תווים אלפאנומריים באותיות קטנות וגדולות, קווים תחתונים או מקפים. השם של מאגר כתובות ה-IP צריך להיות ייחודי באזור.
    • ‫SUBORDINATE_CA_POOL_ID: השם של מאגר רשות האישורים המשנית.
    • ‫REGION: האזור שבו נמצא מאגר CA המשני.
    • ‫ROOT_CA_POOL_ID: המזהה של מאגר רשויות האישורים הבסיסיות.
    • ‫REGION: האזור של מאגר רשויות האישורים הבסיסיות.
    • ‫SUBORDINATE_CA_CN: השם הנפוץ של רשות האישורים המשנית.
    • ‫SUBORDINATE_CA_ORGANIZATION: השם של הארגון המנפיק של רשות האישורים המשנית.
    • ‫KEY_ALGORITHM: אלגוריתם המפתח, לדוגמה, ec-p256-sha256
    • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים המשנית.

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

יצירת קובץ תצורה להנפקת אישורים

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

כדי להגדיר את הגדרות הנפקת האישורים, יוצרים קובץ תצורה של הנפקת אישורים. הפורמט של הקובץ דומה לזה:

{
  "inlineCertificateIssuanceConfig": {
      "caPools": {
        "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1",
        "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2"
      },
      "lifetime": "DURATION",
      "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE,
      "keyAlgorithm": "ALGORITHM"
  }
}

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

  • ‫REGION: האזורים שבהם נמצאים רשויות האישורים.

  • ‫CA_PROJECT_NUMBER: מספר הפרויקט שבו יצרתם את מאגר ה-CA המשני. כדי לקבל את מספר הפרויקט של פרויקט CA_PROJECT_ID, מריצים את הפקודה הבאה:

    gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"

  • SUBORDINATE_CA_POOL_ID: השם של מאגר רשויות האישורים המשניות.

  • ‫ALGORITHM: אופציונלי. אלגוריתם ההצפנה ששימש ליצירת המפתח הפרטי. הערכים התקפים הם ECDSA_P256 (ברירת מחדל), ECDSA_P384,‏ RSA_2048, ‏ RSA_3072, ‏ RSA_4096.

  • ‫DURATION: אופציונלי. משך התוקף של אישור הקצה, בשניות. הערך צריך להיות בין 86,400 (יום אחד) לבין 2,592,000 (30 ימים). אם לא מציינים ערך, המערכת משתמשת בערך ברירת המחדל 86,400 (יום אחד). תוקף האישור בפועל תלוי גם ב-CA שהנפיק אותו, כי הוא יכול להגביל את משך החיים של האישור שהונפק.

  • ROTATION_WINDOW_PERCENTAGE: אופציונלי: אחוז משך החיים של האישור שבו מופעל חידוש. הערך צריך להיות בין 50 ל-80. ערך ברירת המחדל הוא 50.

יצירת קובץ התצורה של הרשאות השיתוף

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

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

כדי ליצור את קובץ התצורה של האמון:

  1. מורידים את האישורים. 

    gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \
    --output-file=CERTIFICATE_PATH \
    --location=REGION

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

    • ‫ROOT_CA_POOL_ID: המזהה של מאגר רשויות האישורים הבסיסיות
    • ‫CERTIFICATE_PATH: הנתיב שבו יישמר האישור בקידוד PEM
    • ‫REGION: האזור של מאגר רשויות האישורים (CA) העליונות

  2. יוצרים קובץ בשם שמכיל את הגדרות האמון שלכם בתוך הקו, עם אישורים בפורמט PEM. הקובץ אמור להיראות כך: 
    {
  "inlineTrustConfig": {
    "additionalTrustBundles": {
      "TRUST_DOMAIN_NAME1": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
          }
        ]
      },
      "TRUSTED_DOMAIN_NAME2": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL3\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL4\n-----END CERTIFICATE-----"
          }
        ]
      }
    }
  }
}

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

    • ‫TRUST_DOMAIN_NAME: שם הדומיין המהימן, בפורמט הבא: 
      PROJECT_ID.svc.id.goog
    • ‫CERTIFICATE_MATERIAL: קבוצה של אישורי CA בפורמט PEM, שמהימנים להנפקת אישורים בדומיין המהימן.

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

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

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

כדי לעדכן את המאגר, מריצים את הפקודה הבאה:

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

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

  • ‫TRUST_DOMAIN_NAME: השם של הדומיין המהימן, בפורמט הבא:

    PROJECT_ID.svc.id.goog

  • ‫CIC_JSON_FILE_PATH: הנתיב לקובץ התצורה להנפקת אישורים בפורמט JSON (cic.json) שיצרתם קודם.

  • ‫TC_JSON_FILE_PATH: אופציונלי. הנתיב לקובץ תצורת האמון בפורמט JSON (tc.json) שיצרתם קודם. אם עומסי העבודה שלכם עוברים אימות בדומיינים שונים של אמון, אתם צריכים לציין את הקובץ הזה. אחרת, אפשר להשמיט את --inline-trust-config.

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

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

gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \
    --location="global" \
    --project=PROJECT_ID

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

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

inlineCertificateIssuanceConfig:
    caPools:
      REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1,
      REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2
    keyAlgorithm: ALGORITHM
    lifetime: DURATION
    rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE
inlineTrustConfig:
    additionalTrustBundles:
      example.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL1
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL2
            -----END CERTIFICATE-----
      myorg.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL3
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL4
            -----END CERTIFICATE-----
name: PROJECT_ID.svc.id.goog
state: ACTIVE

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

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

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

  1. נותנים לתחום המהימן את תפקיד ה-IAM‏ CA Service Workload Certificate Requester (roles/privateca.workloadCertificateRequester) בכל מאגר CA משני. הפקודה gcloud privateca pools add-iam-policy-binding הבאה מאשרת לדומיין המהימן לבקש אישורים משרשראות האישורים של שירות הרשות שמנפיקה את האישורים (CA).

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.workloadCertificateRequester \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID

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

    • ‫SUBORDINATE_CA_POOL_ID: המזהה של מאגר רשויות האישורים המשניות.
    • ‫REGION: האזור של מאגר רשויות האישורים המשניות.

    • ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה ב-GKE.

      כדי לקבל את PROJECT_NUMBER מ-PROJECT_ID, מריצים את הפקודה הבאה:

      gcloud projects describe PROJECT_ID --format="value(projectNumber)"

    • ‫PROJECT_ID: מזהה הפרויקט של פרויקט המארח של ה-Fleet ב-GKE.

    • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים המשנית.

  2. נותנים לעומס העבודה המנוהל את התפקיד CA Service Pool Reader (roles/privateca.poolReader) במאגרי CA המשניים. כך מאשרים לזהות המנוהלת של עומס העבודה לקבל את אישורי X.509 החתומים משרשראות האישורים של רשות האישורים.

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.poolReader \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID

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

    • ‫SUBORDINATE_CA_POOL_ID: המזהה של מאגר ה-CA המשני.
    • ‫REGION: האזור של מאגר רשויות האישורים המשניות.
    • ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה ב-GKE.
    • ‫PROJECT_ID: מזהה הפרויקט של פרויקט המארח של ה-Fleet ב-GKE.
    • ‫CA_PROJECT_ID: מזהה הפרויקט שבו יצרתם את רשות האישורים המשנית.

פריסת עומסי עבודה עם זהויות מנוהלות של עומסי עבודה

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

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

פריסת Pod

כדי לפרוס Pod לבדיקה באשכול:

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

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

  2. יוצרים את מרחב השמות של Kubernetes.

    kubectl create namespace KUBERNETES_NAMESPACE

  3. פריסת PodSpec לבדיקה.

    cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/svc.id.goog
EOF

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

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

kubectl exec -it example-pod -n KUBERNETES_NAMESPACE -- ls  /var/run/secrets/workload-spiffe-credentials

הפלט הבא אמור להתקבל:

ca_certificates.pem
certificates.pem
private_key.pem
trust_bundles.json

צפייה באישור

כדי לראות את האישור:

  1. מייצאים את האישור לקובץ אישור.

    kubectl exec -it example-pod --namespace=KUBERNETES_NAMESPACE -- cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -noout -text > certfile

  2. צופים בקובץ האישור.

    cat certfile

    באישור, במאפיין X509v3 Subject Alternative Name, מופיע מזהה SPIFFE בפורמט הבא: spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

    ‫default מתייחס לחשבון השירות של Kubernetes שמוגדר כברירת מחדל.

בדיקת אימות מעומס עבודה לעומס עבודה

כדי לבדוק אימות מעומס עבודה לעומס עבודה, אפשר לעיין במאמר בדיקת אימות mTLS באמצעות Go.

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

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

נסו בעצמכם

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

מתחילים לעבוד בלי לשלם