בדף הזה מוסבר על שני סוגי הזהויות ב-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 Admin API.
- זהות שירות של Cloud Run: הזהות (חשבון שירות) שמופע Cloud Run משתמש בה. כשקוד Cloud Run שכתבתם מבצע אינטראקציה עם ספריות לקוח של Cloud, או קורא לשירות אחר של Cloud Run לצורך תקשורת בין שירותים, אתם משתמשים בזהות הזו כדי לשלוח בקשות מ-Cloud Run אל ממשקי API שלGoogle Cloud או שירותים אחרים של Cloud Run.
כדי לגשת לממשקי ה-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 המסוף:
קריאה לממשקי 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 משתמשת בחשבון השירות הזה.
בהתאם להגדרות של מדיניות הארגון, יכול להיות שחשבון השירות שמוגדר כברירת מחדל יקבל אוטומטית את התפקיד 'עריכה' בפרויקט. אנחנו ממליצים מאוד להשבית את הענקת התפקיד האוטומטית על ידי
החלת האילוץ iam.automaticIamGrantsForDefaultServiceAccounts של מדיניות הארגון. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.
אם משביתים את הענקת התפקיד האוטומטית, צריך לקבוע אילו תפקידים להעניק לחשבונות השירות שמוגדרים כברירת מחדל, ואז להעניק את התפקידים האלה בעצמכם.
אם לחשבון השירות שמוגדר כברירת מחדל כבר יש את התפקיד Editor, מומלץ להחליף את התפקיד הזה בתפקידים עם פחות הרשאות.כדי לשנות את התפקידים בחשבון השירות בצורה בטוחה, כדאי להשתמש בסימולטור המדיניות כדי לראות את ההשפעה של השינוי, ואז להעניק ולבטל את התפקידים המתאימים.
איך פועלת הזהות בשירות
כשמשתמשים בספריות לקוח של Cloud כדי לשלוח בקשות ל-Google Cloud API, מתרחשים הדברים הבאים:
- ספריית הלקוח מבקשת אסימון גישה מסוג OAuth 2.0 עבור זהות השירות משרת המטא-נתונים של המופע.
- שרת המטא-נתונים של המופע מספק אסימון גישה ל-IAM עבור חשבון השירות שהוגדר כזהות השירות.
- הבקשה ל-API Google Cloud נשלחת עם אסימון גישה מסוג OAuth 2.0.
- מערכת IAM מאמתת את זהות השירות שמצוינת בטוקן הגישה כדי לוודא שיש לו את ההרשאות הנדרשות, ובודקת את הקישורים למדיניות לפני שהיא מעבירה את הקריאה לנקודת קצה ל-API.
- ה-API Google Cloud מבצע את הפעולה.
יצירת אסימון גישה לבקשה של Cloud Run כדי להפעיל ממשקי Google Cloud API
אם הקוד שלכם ב-Cloud Run משתמש בספריות לקוח של Cloud, אתם יכולים להגדיר את זהות השירות ב-Cloud Run על ידי הקצאת חשבון שירות בזמן הפריסה או ההפעלה. כך הספרייה יכולה לקבל באופן אוטומטי טוקן גישה כדי לאמת את הבקשה של הקוד. אם הקוד שלכם ב-Cloud Run מתקשר עם שירותים אחרים מאומתים ב-Cloud Run, אתם צריכים להוסיף את אסימון הגישה לבקשות שלכם.
כדי להקצות חשבון שירות כזהות השירות, אפשר לעיין במדריכים הבאים:
עם זאת, אם אתם משתמשים בקוד מותאם אישית משלכם או שאתם צריכים לשלוח בקשות באופן פרוגרמטי, אתם יכולים להשתמש ישירות בשרת המטא-נתונים כדי לאחזר באופן ידני את אסימוני הזהות ואסימוני הגישה שמתוארים בקטע הבא. שימו לב שאי אפשר לשלוח שאילתה לשרת הזה ישירות מהמחשב המקומי, כי שרת המטא-נתונים זמין רק לעומסי עבודה שפועלים ב-Google Cloud.
אחזור אסימוני מזהה וגישה באמצעות שרת המטא-נתונים
אלה שני סוגי האסימונים שאפשר לאחזר באמצעות שרת המטא-נתונים:
- אסימוני גישה מסוג OAuth 2.0, שמשמשים לקריאה לרוב ספריות הלקוח של Google API.
- אסימונים מזהים, שמשמשים לקריאה לשירותים אחרים של Cloud Run או להפעלת שירות כלשהו כדי לאמת אסימון מזהה.
כדי לאחזר טוקן, פועלים לפי ההוראות בכרטיסייה המתאימה לסוג הטוקן שבו משתמשים:
אסימוני גישה
לדוגמה, אם רוצים ליצור נושא ב-Pub/Sub, משתמשים בשיטה projects.topics.create.
משתמשים בשרת המטא-נתונים של Compute כדי לאחזר אסימון גישה:
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \ --header "Metadata-Flavor: Google"נקודת הקצה הזו מחזירה תגובת JSON עם מאפיין
access_token.בבקשה של פרוטוקול HTTP, הבקשה צריכה להיות מאומתת באמצעות טוקן גישה בכותרת
Authorization:PUT https://pubsub.googleapis.com/v1/projects/
PROJECT_ID/topics/TOPIC_IDAuthorization: BearerACCESS_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
השלבים הבאים
- מגדירים זהות שירות עבור שירותים, משימות או מאגרי עובדים.
- איך מנהלים את הגישה לשירותים או מאמתים בצורה מאובטחת מפתחים, שירותים ומשתמשי קצה לשירותים שלכם.
- כדי לקבל הסבר מפורט על אפליקציה שמשתמשת בזהות שירות כדי לצמצם את סיכוני האבטחה, אפשר לעיין במדריך בנושא אבטחת שירותי Cloud Run.