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

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

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

באמצעות איחוד שירותי אימות הזהות של עומסי עבודה, תוכלו לאפשר לעומסי העבודה האלה לקבל Google Cloud פרטי כניסה לטווח קצר באמצעות חיבור TLS הדדי (mTLS). עומסי העבודה יכולים להשתמש בפרטי הכניסה לטווח קצר כדי לקבל גישה ל-Google Cloud APIs.

מושגים

המושגים שקשורים לאיחוד מבוסס-אישורים X.509 כוללים את הדברים הבאים:

• עוגן אמון הוא אישור CA שנחשב לבסיס האמון. כל שרשראות אישורי הלקוח צריכות להיות מקושרות לאחד מנקודות העוגן של האמון.

• רשות אישורים ברמת ביניים היא אישור אופציונלי של רשות אישורים שעוזר לבנות את שרשרת אישורי הלקוח.

• מאגר אישורים מהימנים מכיל את אישורי עוגן האמון ואת אישורי ה-CA הביניים שמשמשים לאימות שרשרת אישורי הלקוח. הרשות שמנפיקה את האישורים (CA) מנפיקה אישורים מהימנים ללקוח.

  אפשר להעלות למאגר האישורים את סוגי אישורי הלקוח הבאים:

  • אישורים שהונפקו על ידי רשויות אישורים (CA) של צד שלישי לפי בחירתכם
  • אישורים שהונפקו על ידי רשויות אישורים פרטיות
  • אישורים חתומים, כפי שמתואר במאמר בנושא יצירת אישורים בחתימה עצמית

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

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

1. In the Google Cloud console, on the project selector page, select or create 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.

   Go to project selector

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

2. Verify that billing is enabled for your Google Cloud project.

Enable the IAM, Resource Manager, Service Account Credentials, and Security Token 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.

Enable the APIs

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

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

• אדמין במאגר זהויות של עומסי עבודה (roles/iam.workloadIdentityPoolAdmin)
• אדמין בחשבון שירות (roles/iam.serviceAccountAdmin)

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

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

לחלופין, התפקיד הבסיסי 'בעלים' ב-IAM (roles/owner) כולל גם הרשאות להגדרה של איחוד שירותי אימות הזהות. בסביבת ייצור לא מומלץ להקצות תפקידים בסיסיים, אבל אפשר להעניק אותם בסביבת פיתוח או בסביבת בדיקה.

יצירת מאגר אישורים

בקטע הזה מוסבר איך ליצור מאגר אישורים. ככלל, השלבים הם:

• יצירת אישורים בחתימה עצמית
• עיצוב האישורים
• יצירת מאגר האישורים

יצירת אישורים בחתימה עצמית

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

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

כדי ליצור אישור בסיס ואישור ביניים חתום עם שדות keyUsage ו-extendedKeyUsage תקינים:

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

   cat > example.cnf << EOF
   [req]
   distinguished_name = empty_distinguished_name
   [empty_distinguished_name]
   # Kept empty to allow setting via -subj command-line argument.
   [ca_exts]
   basicConstraints=critical,CA:TRUE
   keyUsage=keyCertSign
   extendedKeyUsage=clientAuth
   [leaf_exts]
   keyUsage=critical,Digital Signature, Key Encipherment
   basicConstraints=critical, CA:FALSE
   EOF
   

2. יוצרים את אישור הבסיס.

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=root' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout root.key -out root.cert
   

3. יוצרים את בקשת החתימה לאישור הביניים.

   openssl req \
       -new -sha256 -newkey rsa:2048 -nodes \
       -subj '/CN=int' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout int.key -out int.req
   

4. יוצרים את אישור הביניים.

   openssl x509 -req \
       -CAkey root.key -CA root.cert \
       -set_serial 1 \
       -days 3650 \
       -extfile example.cnf \
       -extensions ca_exts \
       -in int.req -out int.cert
   

5. יוצרים את בקשת החתימה לאישור העלה.

   openssl req -new -sha256 -newkey rsa:2048 -nodes \
       -subj '/CN=example' \
       -config example.cnf \
       -extensions leaf_exts \
       -keyout leaf.key -out leaf.req
   

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

   openssl x509 -req \
       -CAkey int.key -CA int.cert \
       -set_serial 1 -days 3650 \
       -extfile example.cnf \
       -extensions leaf_exts \
       -in leaf.req -out leaf.cert
   

עיצוב האישורים

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

1. שומרים את אישור הבסיס כמחרוזת בשורה אחת.

   export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | sed -z '$ s/\n$//' | tr '\n' $ | sed 's/\$/\\n/g')
   

2. שמירת אישור ביניים כמחרוזת בשורה אחת.

   export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | sed -z '$ s/\n$//' | tr '\n' $ | sed 's/\$/\\n/g')
   

יצירת מאגר אישורים

בקטע הזה יוצרים מאגר אישורים באמצעות קובץ בפורמט YAML שמכיל את ישויות עוגן אמינות ואת רשויות האישורים הביניים.

הקובץ הזה מכיל את תוכן האישור ממשתני הסביבה שיצרתם בשלב עיצוב האישורים. כדי להוסיף עוד עוגני מהימנות, מוסיפים עוד רשומות trustAnchors בקטע trustStore. כדי להוסיף עוד אישורי CA ביניים, מוסיפים עוד רשומות intermediateCas בקטע trustStore.

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

cat << EOF > trust_store.yaml
trustStore:
  trustAnchors:
  - pemCertificate: "${ROOT_CERT}"
  intermediateCas:
  - pemCertificate: "${INTERMEDIATE_CERT}"
EOF

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

אישור הלקוח X.509 יכול להכיל כמה מאפיינים. צריך לבחור את המאפיין שרוצים להשתמש בו כמזהה הנושא על ידי מיפוי google.subject ב Google Cloud למאפיין מהאישור. לדוגמה, אם המאפיין באישור הוא השם הנפוץ של הנושא, המיפוי ייראה כך: google.subject=assertion.subject.dn.cn

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

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

• ‫serialNumberHex: המספר הסידורי
• ‫subject.dn.cn: השם הנפוץ של הנושא
• ‫subject.dn.o: שם הארגון של הנושא
• ‫subject.dn.ou: היחידה הארגונית האחרונה של הנושא
• ‫issuer.dn.cn: השם הנפוץ של המוסד המנפיק
• ‫issuer.dn.o: שם הארגון שהנפיק את האישור
• ‫issuer.dn.ou: היחידה הארגונית האחרונה של המנפיק
• ‫san.dns: שם ה-DNS הראשון של השם החלופי לנושא
• ‫san.uri: ה-URI הראשון של השם החלופי לנושא
• ‫sha256Fingerprint: גיבוב (hash) של אישור עלים מסוג SHA256 (קידוד Base64)

צריך למפות את אחד מהמאפיינים האלה ל-google.subject כדי לזהות את הנושא באופן ייחודי. כדי להגן מפני איומי זיופים, צריך לבחור מאפיין עם ערך ייחודי שאי אפשר לשנות. כברירת מחדל, המזהה google.subject מוגדר כשם הפרטי של הנושא באישור הלקוח, assertion.subject.dn.cn.

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

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

לדוגמה, בעזרת התנאי הבא אפשר להגביל גישה לאישורי לקוח שמכילים את מזהה SPIFFE‏ spiffe://example/path:

assertion.san.uri=="spiffe://example/path"

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

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

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

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

   gcloud iam workload-identity-pools create POOL_ID \
       --location="global" \
       --description="DESCRIPTION" \
       --display-name="DISPLAY_NAME"
   

   צריך להחליף את מה שכתוב בשדות הבאים:

   • ‏POOL_ID: המזהה הייחודי של המאגר.
   • DISPLAY_NAME: שם המאגר.
   • DESCRIPTION: תיאור של המאגר שנבחר. התיאור הזה מופיע כשנותנים גישה לזהויות במאגר.

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

1. כדי להוסיף ספק של מאגר זהויות של עומסי עבודה ב-X.509, מריצים את הפקודה הבאה:

   gcloud iam workload-identity-pools providers create-x509 PROVIDER_ID \
       --location=global \
       --workload-identity-pool="POOL_ID" \
       --trust-store-config-path="TRUST_STORE_CONFIG" \
       --attribute-mapping="MAPPINGS" \
       --attribute-condition="CONDITIONS"
   

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

   • PROVIDER_ID: מזהה ייחודי לפי בחירתך של מאגר זהויות של כוח עבודה.
   • POOL_ID: מזהה מאגר זהויות של כוח עבודה קודם לכן.
   • ‫TRUST_STORE_CONFIG: קובץ ה-YAML של מאגר האישורים.
   • MAPPINGS: רשימה מופרדת בפסיקים של מיפויי המאפיינים שיצרת קודם לכן במדריך הזה. לדוגמה, google.subject=assertion.subject.dn.cn.
   • ‫CONDITIONS: אופציונלי. תנאי למאפיין שיצרתם קודם לכן במדריך הזה. אפשר להסיר את הפרמטר אם אין לך תנאי למאפיין.

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

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

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

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

מתן הרשאה לעומס העבודה החיצוני לגשת למשאבי Google Cloud

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

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

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

הורדה או יצירה של הגדרות אישיות של פרטי הכניסה

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

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

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

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

gcloud iam workload-identity-pools create-cred-config \
  projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --credential-cert-path=CLIENT_CERT_PATH \
    --credential-cert-private-key-path=CLIENT_PRIVATE_KEY_PATH \
    --credential-cert-trust-chain-path=TRUST_CHAIN_PATH \
    --output-file=FILEPATH.json

gcloud iam workload-identity-pools create-cred-config \
  projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --credential-cert-path=CLIENT_CERT_PATH \
    --credential-cert-private-key-path=CLIENT_KEY_PATH \
    --credential-cert-trust-chain-path=TRUST_CHAIN_PATH \
    --output-file=FILEPATH.json

שימוש בהגדרות פרטי הכניסה כדי לקבל גישה אל Google Cloud

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

1. מאתחלים את משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS ומגדירים אותו לקובץ התצורה של פרטי הכניסה:

   Bash

   ‫

     export GOOGLE_APPLICATION_CREDENTIALS=`pwd`/FILEPATH.json
     

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

   PowerShell

   ‫

     $env:GOOGLE_APPLICATION_CREDENTIALS = Resolve-Path 'FILEPATH.json'
     

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

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

   • נתיב ברירת המחדל של ה-CLI של gcloud:

     • ‫Linux ו-macOS: ‏ ~/.config/gcloud/certificate_config.json

     • ב-Windows:‏ %APPDATA%\gcloud\certificate_config.json‎

   • הנתיב שמוגדר במשתנה הסביבה GOOGLE_API_CERTIFICATE_CONFIG.

3. אפשר להשתמש בספריות הלקוח הבאות ב-Cloud שתומכות באיחוד שירותי אימות הזהות של עומסי עבודה עם אישורי X.509.

   Go

   ספריות לקוח של Go תומכות באיחוד שירותי אימות הזהות של עומסי עבודה מסוג X.509 אם הן משתמשות במודול cloud.google.com/go/auth בגרסה 0.16.0 ואילך ובמודול google.golang.org/api בגרסה 0.189.0.

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

     go list -m cloud.google.com/go/auth
     go list -m cloud.google.com/api
   

   Python

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

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

     pip show google-auth
   

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

4. אם עומס העבודה שלכם פועל ב-macOS, צריך להגדיר את CLOUDSDK_PYTHON_SITEPACKAGES=1 כדי שה-CLI של gcloud ישתמש בספריות Python מחוץ לספריית ההתקנה שלו.

5. כדי לבצע אימות באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:

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

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

   ב-CLI של gcloud יש תמיכה באיחוד שירותי אימות הזהות של עומסי עבודה בפורמט X.509 ב-CLI של gcloud בגרסה 538.0 ואילך.

קבלת טוקן גישה באמצעות בקשה פשוטה לגישה אל Google Cloud

יצירת שרשרת האמון

בשלב הזה מוסבר איך ליצור את שרשרת האמון. כשמבצעים קריאה ל-Security Token Service (שירות אסימוני אבטחה) בבקשה רגילה, מעבירים את שרשרת המהימנות בשדה subject_token.

צריך לעצב את האישורים שרוצים לכלול בשרשרת כרשימה בפורמט JSON, כמו שמוגדר ב-RFC 7515. צריך לציין את אישור העלה שמשמש ללחיצת היד ב-mTLS כפריט הראשון. כל אישור בחבילה צריך להיות מחרוזת בקידוד Base64.

1. שומרים את אישור העלה ואת אישור הביניים כמחרוזות בקידוד Base64.

   export LEAF_CERT=$(openssl x509 -in leaf.cert -out leaf.der -outform DER && cat leaf.der | openssl enc -base64 -A)
   

   export INTERMEDIATE_CERT=$(openssl x509 -in int.cert -out int.der -outform DER && cat int.der | openssl enc -base64 -A)
   

2. יוצרים רשימה של מחרוזות בפורמט JSON שאפשר להעביר כ-subject_token בקריאה ל-Security Token Service, בהמשך המאמר.

   export TRUST_CHAIN="[\\\"${LEAF_CERT}\\\", \\\"${INTERMEDIATE_CERT}\\\"]"
   

קבלת טוקן גישה

כדי לקבל את אסימון הגישה:

1. ביצוע החלפת טוקנים באמצעות mTLS ואישור הלקוח:

   curl --key CLIENT_CERT_KEY \
   --cert CLIENT_CERT \
   --request POST 'https://sts.mtls.googleapis.com/v1/token' \
   --header "Content-Type: application/json" \
   --data-raw '{
       "subject_token_type": "urn:ietf:params:oauth:token-type:mtls",
       "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
       "audience": "WORKLOAD_IDENTITY_POOL_URI",
       "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
       "scope": "https://www.googleapis.com/auth/cloud-platform",
       "subject_token": "TRUST_CHAIN"
   }'
   

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

   • ‫CLIENT_CERT_KEY: המפתח הפרטי של אישור הלקוח
   • ‫CLIENT_CERT: אישור הלקוח

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

     //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

   • ‫TRUST_CHAIN: שרשרת האמון שנדרשת לאימות אישור העלה, חייבת לכלול לפחות את CLIENT_CERT כפריט הראשון. אם פעלתם לפי ההוראות שבקטע עיצוב האישורים, מחליפים את TRUST_CHAIN ב-'"${TRUST_CHAIN}"'.

2. משתמשים באסימון הגישה מסוג bearer שנוצר בשלב הקודם כדי לגשת למשאביGoogle Cloud . לדוגמה:

   curl -X GET 'https://storage.googleapis.com/my_object' -H "Authorization: Bearer $ACCESS_TOKEN"
   

מגבלות

בטבלה הבאה מפורטות המגבלות.

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

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