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

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

זהויות ב-Cloud Run

כדי להשתמש ב-Cloud Run, Google Cloud משתמש Cloud Run ומופע Cloud Run צריכים להיות בעלי זהות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יצירת אסימון גישה לבקשה של 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

השלבים הבאים