מבוא לזהות בשירות

זהויות של שירותי Cloud Run מאפשרות לעומסי העבודה שפועלים לקרוא לממשקי API שלGoogle Cloud דרך ספריות הלקוח של Cloud, באמצעות טוקני גישה מנוהלים. ב-Cloud Run, הגישה מופרדת בין שתי זהויות: חשבון פריסה לניהול משאבים וזהות שירות לבקשות בזמן ריצה לשירותיGoogle Cloud עם ספריות לקוח של Cloud, כמו Cloud Storage, ‏ Firestore, ‏ Cloud SQL, ‏ Pub/Sub ו-Cloud Tasks.

המסמך הזה מיועד לאדמינים, למפעילים ולמפתחים שמנהלים את מדיניות הארגון ואת הגישה של המשתמשים לעומסי עבודה ב-Cloud Run.

זהויות ב-Cloud Run

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

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

כדי לגשת לממשקי ה-API של Google Cloud ולשלוח אליהם בקשות, או כדי לתקשר בין שירותים, לכל זהות צריכות להיות ההרשאות המתאימות שהוקצו לה בניהול זהויות והרשאות גישה (IAM).

שליחת קריאה ל-Cloud Run Admin API באמצעות חשבון הפריסה

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

כשמשתמשים בחשבון הפריסה ב-Cloud Run, מערכת IAM בודקת אם יש לחשבון הפריסה את ההרשאות הנדרשות כדי לבצע את הפעולה ב-Cloud Run. בתרשים הבא מוצג איך חשבון משתמש קורא ל-Cloud Run Admin API כדי לפרוס גרסה חדשה ממסוףGoogle Cloud :

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

שליחת קריאות לממשקי ה-API של Google Cloud באמצעות זהות השירות

כשמכונה של Cloud Run יוצרת אינטראקציה עם שירותים אחרים של Cloud Run שעברו אימות ב-IAM, או קוראת לספריות הלקוח של Cloud באמצעות קוד אפליקציה או תכונות מובנות כמו שילובים של Cloud Run או התקנות של נפחי אחסון ב-Cloud Storage, הסביבה של Google Cloud משתמשת בApplication Default Credentials ‏(ADC) כדי לזהות באופן אוטומטי אם זהות השירות של Cloud Run מאומתת לביצוע פעולת ה-API. זהות השירות של Cloud Run היא חשבון שירות שהוקצה כזהות של המכונה ב-Cloud Run כשפורסים גרסה או מריצים משימה.

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

בהמשך המדריך מוסבר איך משאב של Cloud Run משתמש בזהות השירות כדי לקרוא לשירותים ולממשקי API של Google ולגשת אליהם. למידע נוסף על הגדרת זהות השירות, קראו את דפי הגדרת זהות השירות של שירותים, משימות ומאגרי Worker.

סוגים של חשבונות שירות לזהות של שירות

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

  • חשבון שירות בניהול המשתמש (מומלץ): אתם יוצרים את חשבון השירות הזה באופן ידני וקובעים את קבוצת ההרשאות המינימלית שחשבון השירות צריך כדי לגשת למשאבים ספציפיים ב- Google Cloud . חשבון השירות בניהול המשתמש הוא בפורמט SERVICE_ACCOUNT_NAME@PROJECT_ID..
  • חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine: מערכת Cloud Run מספקת באופן אוטומטי את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בתור זהות השירות שמוגדרת כברירת מחדל. חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine הוא בפורמט PROJECT_NUMBER-compute@.

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

כברירת מחדל, חשבון השירות של Compute Engine נוצר באופן אוטומטי. אם לא תציינו חשבון שירות כשאתם יוצרים את המשאב ב-Cloud Run, המערכת תשתמש בחשבון השירות הזה.

בהתאם להגדרות של מדיניות הארגון, יכול להיות שחשבון השירות שמוגדר כברירת מחדל יקבל באופן אוטומטי את תפקיד העריכה בפרויקט. אנחנו ממליצים מאוד להשבית את הענקת התפקיד האוטומטית על ידי אכיפת האילוץ iam.automaticIamGrantsForDefaultServiceAccounts במדיניות הארגון. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.

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

אם לחשבון השירות שמוגדר כברירת מחדל כבר יש את התפקיד "עריכה", מומלץ להחליף אותו בתפקידים עם פחות הרשאות.

איך פועלת זהות השירות

כשמשתמשים בספריות הלקוח של Cloud בקוד כדי לשלוח בקשות ל-API שלGoogle Cloud , קורים הדברים הבאים:

  1. ספריית הלקוח מבקשת אסימון גישה מסוג OAuth 2.0 לזהות השירות משרת המטא-נתונים של המכונה.
  2. שרת המטא-נתונים של המכונה מספק טוקן גישה של IAM לחשבון השירות שמוגדר כזהות השירות.
  3. הבקשה ל-API של Google Cloud נשלחת עם אסימון גישה מסוג OAuth 2.0.
  4. ‫IAM מאמת את זהות השירות שמופיעה בטוקן הגישה כדי לוודא שיש לו את ההרשאות הנדרשות, ובודק את קישורי המדיניות לפני שהוא מעביר את הקריאה לנקודת קצה ל-API.
  5. ה-API של Google Cloud מבצע את הפעולה.
שליחת קריאה ל-Google Cloud API מ-Cloud Run.
תרשים 1. ‫Cloud Run יוצר טוקן גישה משרת המטא-נתונים, ו-IAM משתמש בטוקן הגישה הזה כדי לאמת שלזהות שהוקצתה לשירות Cloud Run יש הרשאת גישה ל- Google Cloud APIs
.

יוצרים אסימון גישה לבקשה של Cloud Run כדי להפעיל ממשקי API של Google Cloud

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

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

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

אחזור של אסימוני מזהה וטוקני גישה באמצעות שרת המטא-נתונים

אלה שני סוגי האסימונים שאפשר לאחזר באמצעות שרת המטא-נתונים:

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

אסימוני גישה

לדוגמה, אם רוצים ליצור נושא ב-Pub/Sub, משתמשים ב-method‏ projects.topics.create.

  1. משתמשים בשרת המטא-נתונים של Compute כדי לאחזר אסימון גישה:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
    --header "Metadata-Flavor: Google"

    נקודת הקצה הזו מחזירה תגובת JSON עם מאפיין access_token.

  2. בבקשה של פרוטוקול HTTP, צריך לאמת את הבקשה באמצעות אסימון גישה בכותרת Authorization:

    PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
Authorization: Bearer ACCESS_TOKEN

    כאשר:

    • ‫PROJECT_ID הוא מזהה הפרויקט.
    • ‫TOPIC_ID הוא מזהה הנושא.
    • ‫ACCESS_TOKEN הוא אסימון הגישה שאחזרתם בשלב הקודם.

    תשובה:

    {
    "name": "projects/PROJECT_ID/topics/TOPIC_ID"
}

טוקנים של מזהים

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

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
    --header "Metadata-Flavor: Google"

כאשר AUDIENCE הוא הקהל המבוקש של JWT.

בשירותי Cloud Run, הקהל צריך להיות כתובת ה-URL של השירות שאתם מפעילים או קהל בהתאמה אישית, כמו דומיין בהתאמה אישית שמוגדר לשירות.

https://service.domain.com

למשאבים אחרים, סביר להניח שזה מזהה הלקוח ב-OAuth של משאב שמוגן באמצעות IAP:

1234567890.apps.googleusercontent.com

השלבים הבאים