יצירת פרטי כניסה לטווח קצר למספר חשבונות שירות

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

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

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

מידע על יצירת פרטי כניסה לטווח קצר

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

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

  • אסימוני גישה מסוג OAuth 2.0

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

    מידע נוסף זמין באסימוני גישה.

  • אסימונים מזהים מסוג OpenID Connect‏ (OIDC)

    אסימונים מזהים עומדים בדרישות של מפרט OpenID Connect‏ (OIDC). מספר מוגבל של שירותים ואפליקציות מקבלים אסימונים מזהים.

    מידע נוסף זמין במאמרים אסימונים מזהים ואימות של אפליקציות שמתארחות ב-Cloud Run או בפונקציות Cloud Run.

  • אסימוני JWT (‏JSON Web Tokens) בחתימה עצמית

    אפשר להשתמש באסימוני JWT בחתימה עצמית כדי לאמת לממשקי Google APIs מסוימים בלי לקבל אסימון גישה משרת ההרשאות. ממשקי API שנפרסו באמצעות API Gateway דורשים את האסימונים האלה.

  • ‫blobs בינאריים בחתימה עצמית

    ‫blobs בחתימה עצמית הם שימושיים בתרחישים שבהם צריך לשדר נתונים בינאריים ושרירותיים באופן מאובטח, לרוב למטרות אימות.

תהליך הבקשה להענקת גישה

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

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

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

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

  • Enable the IAM and Service Account Credentials 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

  • אם עדיין לא ביצעתם זאת, מפעילים את החיוב ואת ממשק ה-API של IAM על-ידי ביצוע השלבים המפורטים במדריך למתחילים.

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

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

מתן ההרשאות הנדרשות

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

  • חשבון שירות 1 (SA_1), מבצע הקריאה ששולח בקשה לפרטי כניסה לטווח קצר.
  • חשבון שירות 2 (SA_2), חשבון שירות הביניים שיעניק את הבקשה הראשונית ל-SA_3. החשבון הזה רק מעביר הלאה את הבקשה - הוא לא נותן ל-SA_1 או ל-SA_3 גישה נוספת כלשהי.
  • חשבון שירות 3 (SA_3), החשבון עם ההרשאות המוגבלות שבשבילו נוצרו פרטי הכניסה.

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

בדוגמה הספציפית הזו, צריך להקצות ל-SA_1 את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) ב-SA_2. זוהי דוגמה להתייחסות לחשבון השירות SA_2 כמשאב: כשמקצים את התפקיד ב-SA_2, מעדכנים את מדיניות ההרשאה שלו באותו אופן שבו מעדכנים כל משאב אחר.

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

בשלב הבא, צריך להקצות גם ל-SA_2 את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) ב-SA_3. זה יאפשר ל-SA_2 ליצור פרטי כניסה לטווח קצר בשביל SA_3.

השלבים הבאים משתמשים ב-API ל-REST כדי להקצות את התפקידים. עם זאת, אפשר להשתמש גם במסוף Cloud de Confiance או ב-ה-CLI של gcloud.

API

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

ה-method serviceAccounts.getIamPolicy מאפשרת לקבל את מדיניות ההרשאות של חשבון השירות.

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project.
  • ‫SA_2: השם של חשבון שירות 2.
  • ‫POLICY_VERSION: גרסת המדיניות שתוחזר. בבקשות צריך לציין את הגרסה הכי עדכנית של המדיניות (3). פרטים נוספים מופיעים במאמר ציון גרסת מדיניות בזמן אחזור מדיניות.

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.s3ns.iam.gserviceaccount.com:getIamPolicy

תוכן בקשת JSON: 

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    }
  ]
}

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

לאחר מכן, משנים את מדיניות ההרשאה כדי להקצות ל-SA_1 את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator).

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

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.s3ns.iam.gserviceaccount.com"
      ]
    }
  ]
}

אחר כך כותבים את המדיניות המעודכנת בשביל SA_2:

השיטה serviceAccounts.setIamPolicy מגדירה מדיניות הרשאות מעודכנת לחשבון השירות.

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project.
  • ‫SA_2: השם של חשבון שירות 2.

  • POLICY: ייצוג JSON של המדיניות שרוצים להגדיר. בדף העזר בנושא מדיניות תוכלו לקרוא על הפורמטים של המדיניות.

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

    {
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.s3ns.iam.gserviceaccount.com"
      ]
    }
  ]
}

שיטת ה-HTTP וכתובת ה-URL: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.s3ns.iam.gserviceaccount.com:setIamPolicy

תוכן בקשת JSON: 

{
  "policy": POLICY
}

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

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

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

ה-method serviceAccounts.getIamPolicy מאפשרת לקבל את מדיניות ההרשאות של חשבון השירות.

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project.
  • SA_3: השם של חשבון שירות 3.
  • ‫POLICY_VERSION: גרסת המדיניות שתוחזר. בבקשות צריך לציין את הגרסה הכי עדכנית של המדיניות (3). פרטים נוספים מופיעים במאמר ציון גרסת מדיניות בזמן אחזור מדיניות.

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.s3ns.iam.gserviceaccount.com:getIamPolicy

תוכן בקשת JSON: 

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    }
  ]
}

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

לאחר מכן, משנים את מדיניות ההרשאה כדי להקצות ל-SA_2 את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator).

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

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.s3ns.iam.gserviceaccount.com"
      ]
    }
  ]
}

לבסוף, כותבים את מדיניות ההרשאה המעודכנת:

השיטה serviceAccounts.setIamPolicy מגדירה מדיניות הרשאות מעודכנת לחשבון השירות.

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project.
  • SA_3: השם של חשבון שירות 3.

  • POLICY: ייצוג JSON של המדיניות שרוצים להגדיר. בדף העזר בנושא מדיניות תוכלו לקרוא על הפורמטים של המדיניות.

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

    {
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.s3ns.iam.gserviceaccount.com"
      ]
    }
  ]
}

שיטת ה-HTTP וכתובת ה-URL: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.s3ns.iam.gserviceaccount.com:setIamPolicy

תוכן בקשת JSON: 

{
  "policy": POLICY
}

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

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

בקשת פרטי כניסה לטווח קצר

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

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

יצירת אסימון גישה מסוג OAuth 2.0

כברירת מחדל, אסימוני גישה מסוג OAuth 2.0 תקפים למשך שעה אחת לכל היותר (3,600 שניות). עם זאת, אפשר להאריך את משך החיים המקסימלי של אסימונים אלו ל-12 שעות (43,200 שניות). כדי לעשות זאת, צריך לזהות את חשבונות השירות שבהם צריך שמשך החיים של האסימונים יהיה ארוך יותר, ואזלהוסיף את חשבונות השירות האלו למדיניות הארגון שכוללת את אילוץ הרשימה constraints/iam.allowServiceAccountCredentialLifetimeExtension. לאחר מכן, אפשר לציין משך חיים של עד 43,200 שניות במהלך יצירה של אסימון בשביל חשבונות השירות האלו.

כדי ליצור אסימון גישה מסוג OAuth 2.0 בשביל חשבון שירות, צריך לבצע את הפעולות הבאות:

API

שיטת 'ה-API של פרטי הכניסה של חשבון השירות' (serviceAccounts.generateAccessToken) יוצרת אסימון גישה מסוג OAuth 2.0 בשביל חשבון שירות.

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

  • SA_NAME: השם של חשבון השירות שבשבילו רוצים ליצור אסימון.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project.
  • DELEGATES: אם משתמשים בתהליך הבקשה להענקת גישה, מומלץ לעיין בחלק ציון שרשרת הענקת גישה שבדף זה. אם משתמשים בתהליך של בקשות ישירות ללא הענקת גישה, צריך להשמיט את השדה delegates בגוף הבקשה.

  • LIFETIME: משך הזמן עד לתפוגת אסימון הגישה, בשניות. לדוגמה: 300s.

    כברירת מחדל, משך החיים המקסימלי של אסימון הוא שעה אחת (3,600 שניות). כדי להאריך את משך החיים המקסימלי של האסימונים האלה ל-12 שעות (43,200 שניות), מוסיפים את חשבון השירות למדיניות הארגון שכוללת את אילוץ הרשימה constraints/iam.allowServiceAccountCredentialLifetimeExtension.

שיטת ה-HTTP וכתובת ה-URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com:generateAccessToken

תוכן בקשת JSON: 

{
  "delegates": [
    DELEGATES
  ],
  "scope": [
    "https://www.googleapis.com/auth/cloud-platform"
  ],
  "lifetime": "LIFETIME"
}

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

אם הבקשה של generateAccessToken תאושר, גוף התגובה יכלול אסימון גישה מסוג OAuth 2.0 ומועד תפוגה. לאחר מכן אפשר יהיה להשתמש ב-accessToken כדי לאמת בקשה מטעם חשבון השירות, עד שמגיעים לזמן ה-expireTime: 

{
  "accessToken": "eyJ0eXAi...NiJ9",
  "expireTime": "2020-04-07T15:01:23.045123456Z"
}

יצירת אסימונים מזהים מסוג OpenID Connect

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

API

שיטת 'ה-API של פרטי הכניסה של חשבון השירות' (serviceAccounts.generateIdToken) יוצרת אסימון מזהה מסוג OIDC בשביל חשבון שירות.

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

  • PRIV_SA: כתובת האימייל של חשבון השירות שנושא את ההרשאות שבשבילו נוצר האסימון לטווח קצר.
  • AUDIENCE_NAME: הקהל של האסימון, בדרך כלל כתובת ה-URL של האפליקציה או השירות שישתמש באסימון כדי לגשת אליהם.

שיטת ה-HTTP וכתובת ה-URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/PRIV_SA:generateIdToken

תוכן בקשת JSON: 

{
  "audience": "AUDIENCE_NAME",
  "includeEmail": "true"
}

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

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

{
  "token": "eyJ0eXAi...NiJ9"
}

יצירת ‎(JWT) JSON Web Token בחתימה עצמית

אפשר להשתמש ב-JSON Web Tokens ‏(JWT) בחתימה עצמית במגוון תרחישים, כמו:

  • אימות קריאה ל-Google API כפי שמתואר במדריך האימות של Google.
  • תקשורת מאובטחת בין שירותים של Google Cloud או שירותים שלא שייכים ל-Google, כמו אפליקציות של App Engine. Cloud de Confiance בתרחיש הזה, אפליקציה אחת יכולה לחתום על אסימון שאפליקציה אחרת יכולה לבדוק למטרות אימות.
  • התייחסות לחשבון שירות כספק זהויות באמצעות חתימה על JWT שמכיל הצהרות שרירותיות על משתמש, חשבון או מכשיר.

כדי ליצור JWT בחתימה עצמית בשביל חשבון שירות, צריך לבצע את הפעולות הבאות:

API

שיטת 'ה-API של פרטי הכניסה של חשבון השירות' (serviceAccounts.signJwt) חותמת על JWT באמצעות מפתח פרטי בניהול מערכת של חשבון שירות.

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

  • SA_NAME: השם של חשבון השירות שבשבילו רוצים ליצור אסימון.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project.
  • DELEGATES: אם משתמשים בתהליך הבקשה להענקת גישה, מומלץ לעיין בחלק ציון שרשרת הענקת גישה שבדף זה. אם משתמשים בתהליך של בקשות ישירות ללא הענקת גישה, צריך להשמיט את השדה delegates בגוף הבקשה.

  • JWT_PAYLOAD: המטען הייעודי (payload) של JWT לחתימה, זהו אובייקט JSON שמכיל קבוצת הצהרות של JWT. מוסיפים את ההצהרות שנחוצות לתרחיש הרצוי, ושעומדות בדרישות האימות של השירות שרוצים לבצע אליו קריאה. אם מבצעים קריאה ל-Google API, מומלץ לעיין ב מדריך האימות של Google כדי לראות מהן דרישות ההצהרה.

    התוקף של ההצהרה exp (זמן התפוגה) צריך להיות בטווח של עד 12 שעות קדימה. כשמבצעים קריאה ל-Google API, צריך להגדיר את ההצהרהexp לא יותר משעה אחת קדימה.

    המטען הייעודי (payload) בדוגמה הבאה מכיל הצהרות לקריאה ל-Google API שבהן EXP היא חותמת זמן במספר שלם שמייצג את זמן התפוגה: 

    { \"iss\": \"SA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com\", \"sub\": \"SA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com\", \"aud\": \"https://firestore.googleapis.com/\", \"iat\": 1529350000, \"exp\": EXP }

שיטת ה-HTTP וכתובת ה-URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com:signJwt

תוכן בקשת JSON: 

{
  "delegates": [
    DELEGATES
  ],
  "payload": "JWT_PAYLOAD"
}

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

אם הבקשה של signJwt תאושר, גוף התגובה יכלול JWT חתום ומזהה של מפתח החתימה ששימש לחתימה על ה-JWT. אפשר להשתמש בערך signedJwt כאסימון למוכ"ז כדי לאמת בקשה באופן ישיר מטעם חשבון השירות. האסימון תקף עד לזמן התפוגה שצוין בבקשה: 

{
  "keyId": "42ba1e...fc0a",
  "signedJwt": "eyJ0eXAi...NiJ9"
}

יצירת blob בחתימה עצמית

‫blobs בחתימה עצמית הם שימושיים בתרחישים שבהם צריך לשדר נתונים בינאריים ושרירותיים באופן מאובטח, לרוב למטרות אימות. לדוגמה, אם רוצים להשתמש בפרוטוקול או באסימון בהתאמה אישית (לא JWT), אפשר לכלול נתונים אלו ב-blob חתום לשימוש של שירות ב-downstream.

כדי ליצור blob בחתימה עצמית בשביל חשבון שירות, צריך לבצע את הפעולות הבאות:

API

שיטת 'ה-API של פרטי הכניסה של חשבון השירות' (serviceAccounts.signBlob) חותמת על blob באמצעות מפתח פרטי בניהול מערכת של חשבון שירות.

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

  • SA_NAME: השם של חשבון השירות שבשבילו רוצים ליצור אסימון.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance . מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project.
  • DELEGATES: אם משתמשים בתהליך הבקשה להענקת גישה, מומלץ לעיין בחלק ציון שרשרת הענקת גישה שבדף זה. אם משתמשים בתהליך של בקשות ישירות ללא הענקת גישה, צריך להשמיט את השדה delegates בגוף הבקשה.
  • BLOB_PAYLOAD: מחרוזת בייטים בקידוד base64. לדוגמה: VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cu.

שיטת ה-HTTP וכתובת ה-URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com:signBlob

תוכן בקשת JSON: 

{
  "delegates": [
    DELEGATES
  ],
  "payload": "BLOB_PAYLOAD"
}

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

אם הבקשה של signBlob תאושר, גוף התגובה יכלול blob חתום ומזהה של מפתח החתימה ששימש לחתימה על ה-blob. אפשר להשתמש בערך signedBlob כאסימון למוכ"ז כדי לאמת בקשה באופן ישיר מטעם חשבון השירות. האסימון תקף עד שיפוג התוקף של המפתח הפרטי בניהול מערכת של חשבון השירות. המזהה של המפתח הזה הוא הערך של השדה keyId בתגובה. 

{
  "keyId": "42ba1e...fc0a",
  "signedBlob": "eyJ0eXAi...NiJ9"
}

ציון שרשרת הענקת הגישה

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

projects/-/serviceAccounts/SA_ID

מחליפים את SA_ID במזהה המספרי שייחודי לחשבון השירות או בכתובת האימייל של חשבון השירות.

לדוגמה, בשרשרת הענקת הגישה שעוברת מ-SA_1 (מבצע הקריאה) אל SA_2 (מקבל הגישה) אל SA_3 (מקבל הגישה) אלSA_4, delegates[] יכיל את SA_2 וגם אתSA_3 בסדר הבא:

{
  "delegates": [
    "projects/-/serviceAccounts/SA_2@PROJECT_ID.s3ns.iam.gserviceaccount.com",
    "projects/-/serviceAccounts/SA_3@PROJECT_ID.s3ns.iam.gserviceaccount.com"
  ]
}

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