אם הארכיטקטורה שלכם משתמשת בכמה שירותים, סביר להניח שהשירותים האלה צריכים לתקשר ביניהם, באמצעות אמצעים אסינכרוניים או סינכרוניים. יכול להיות שהרבה מהשירותים האלה הם פרטיים, ולכן נדרשים פרטי כניסה כדי לגשת אליהם.
לתקשורת אסינכרונית, אפשר להשתמש בשירותים הבאים Google Cloud :
- Cloud Tasks לתקשורת אסינכרונית אחד על אחד
- Pub/Sub לתקשורת אסינכרונית מסוג אחד לרבים, אחד לאחד ורבים לאחד
- Cloud Scheduler לתקשורת אסינכרונית מתוזמנת באופן קבוע
- Eventarc לתקשורת מבוססת-אירועים
בכל המקרים האלה, השירות שבו נעשה שימוש מנהל את האינטראקציה עם השירות המקבל, על סמך ההגדרה שהגדרתם.
אבל בתקשורת סינכרונית, השירות שלכם קורא לשירות אחר ישירות, דרך HTTP, באמצעות כתובת ה-URL של נקודת הקצה שלו. בתרחיש השימוש הזה, חשוב לוודא שכל שירות יכול לשלוח בקשות רק לשירותים ספציפיים. לדוגמה, אם יש לכם שירות login, הוא צריך להיות מסוגל לגשת לשירות user-profiles, אבל לא לשירות search.
במצב כזה, Google ממליצה להשתמש ב-IAM ובזהות שירות שמבוססת על חשבון שירות שמנוהל על ידי המשתמש לכל שירות, שקיבל את ההרשאות המינימליות שנדרשות לביצוע העבודה.
בנוסף, בבקשה צריך להיות אימות של זהות השירות ששולח את הבקשה. כדי לעשות את זה, צריך להגדיר את השירות שקורא ל-Google כדי להוסיף אסימון מזהה של OpenID Connect בחתימת Google כחלק מהבקשה.
הגדרת חשבון השירות
כדי להגדיר חשבון שירות, צריך להגדיר את השירות המקבל כך שיקבל בקשות מהשירות המתקשר. לשם כך, צריך להגדיר את חשבון השירות של השירות המתקשר כחשבון משתמש בשירות המקבל. לאחר מכן מקצים לחשבון השירות הזה את התפקיד Cloud Run Invoker (roles/run.invoker). כדי לבצע את שתי המשימות האלה, פועלים לפי ההוראות בכרטיסייה המתאימה:
ממשק המשתמש של המסוף
נכנסים למסוף Google Cloud :
בוחרים את שירות הקבלה.
לוחצים על Show Info Panel (הצגת חלונית המידע) בפינה השמאלית העליונה כדי להציג את הכרטיסייה Permissions (הרשאות).
לוחצים על Add principal.
מזינים את הזהות של השירות המתקשר. בדרך כלל זה כתובת אימייל, ובאופן ברירת מחדל
PROJECT_NUMBER-compute@developer.gserviceaccount.com.בתפריט הנפתח Select a role (בחירת תפקיד), בוחרים את התפקיד
Cloud Run Invoker.לוחצים על Save.
gcloud
משתמשים בפקודה gcloud run services add-iam-policy-binding:
gcloud run services add-iam-policy-binding RECEIVING_SERVICE \ --member='serviceAccount:CALLING_SERVICE_IDENTITY' \ --role='roles/run.invoker'
כאשר RECEIVING_SERVICE הוא השם של שירות הקבלה, ו-CALLING_SERVICE_IDENTITY הוא כתובת האימייל של חשבון השירות, שמוגדרת כ-PROJECT_NUMBER-compute@developer.gserviceaccount.com כברירת מחדל.
Terraform
כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.
מוסיפים את השורות הבאות למשאבgoogle_cloud_run_v2_service בתצורת Terraform:מחליפים את us-docker.pkg.dev/cloudrun/container/hello בהפניה לקובץ אימג' של קונטיינר.
קוד ה-Terraform הבא הופך את השירות הראשוני לציבורי.
קוד ה-Terraform הבא יוצר שירות שני של Cloud Run שנועד להיות פרטי.
מחליפים את us-docker.pkg.dev/cloudrun/container/hello בהפניה לקובץ אימג' של קונטיינר.
קוד ה-Terraform הבא מגדיר את השירות השני כפרטי.
קוד ה-Terraform הבא יוצר חשבון שירות.
קוד Terraform הבא מאפשר לשירותים שמצורפים לחשבון השירות להפעיל את שירות Cloud Run הפרטי הראשוני.
קבלת אסימון מזהה והגדרתו
אחרי שמקצים את התפקיד המתאים לחשבון השירות שקורא ל-API, פועלים לפי השלבים הבאים:
מאחזרים אסימון מזהה בחתימת Google באמצעות אחת מהשיטות שמתוארות בקטע הבא. מגדירים את טענת הקהל (
aud) לכתובת ה-URL של השירות המקבל או לקהל בהתאמה אישית שהוגדר. אם אתם לא משתמשים בקהל בהתאמה אישית, הערךaudחייב להישאר כתובת ה-URL של השירות, גם כששולחים בקשות לתג תנועה ספציפי.מוסיפים את האסימון המזהה שאוחזר בשלב הקודם לאחת מהכותרות הבאות בבקשה לשירות המקבל:
- כותרת
Authorization: Bearer ID_TOKEN. - כותרת
X-Serverless-Authorization: Bearer ID_TOKEN. אפשר להשתמש בכותרת הזו אם האפליקציה כבר משתמשת בכותרתAuthorizationלאימות מותאם אישית. הפעולה הזו מסירה את החתימה לפני העברת האסימון למאגר של המשתמש.
- כותרת
במאמר שיטות לקבלת אסימון מזהה מפורטות דרכים נוספות לקבלת אסימון מזהה שלא מתוארות בדף הזה.
שימוש בספריות לאימות
אחת הדרכים להשיג ולהגדיר את תהליך אסימון המזהה היא באמצעות ספריות האימות.
הקוד הזה פועל בכל סביבה, גם מחוץ ל- Google Cloud, שבה הספריות יכולות לקבל פרטי אימות לחשבון שירות. כדי להשתמש בשיטה הזו, צריך להוריד קובץ מפתח של חשבון שירות ולהגדיר את משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS לנתיב של קובץ המפתח של חשבון השירות. מידע נוסף מופיע במאמר בנושא מפתח של חשבון שירות.
הקוד הזה לא מקבל פרטי כניסה לאימות של חשבון משתמש.
Node.js
Python
המשך
Java
שימוש בשרת מטא-נתונים
אם מסיבה כלשהי אין לכם אפשרות להשתמש בספריות האימות, תוכלו לאחזר אסימון מזהה משרת המטא-נתונים של Compute בזמן שהקונטיינר פועל ב-Cloud Run. שימו לב שהשיטה הזו לא פועלת מחוץ ל- Google Cloud, כולל מהמחשב המקומי.
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[AUDIENCE]" \
-H "Metadata-Flavor: Google"
כאשר AUDIENCE היא כתובת ה-URL של השירות שאתם מפעילים או קהל בהתאמה אישית שהגדרתם.
בטבלה הבאה מפורטים החלקים העיקריים של בקשת שאילתת מטא-נתונים:
| רכיבים | תיאור |
|---|---|
| כתובת URL בסיסית | כל ערכי המטא-נתונים מוגדרים כנתיבי משנה מתחת לכתובת ה-URL הבסיסית הבאה: http://metadata.google.internal/computeMetadata/v1 |
| כותרת הבקשה | כל בקשה חייבת לכלול את הכותרת הבאה: Metadata-Flavor: Google הכותרת הזו מציינת שהבקשה נשלחה בכוונה מפורשת לאחזר ערכי מטא-נתונים, ולא נשלחה בלי כוונה ממקור לא מאובטח, והיא מאפשרת לשרת המטא-נתונים להחזיר את הנתונים שביקשתם. אם לא תספקו את הכותרת הזו, שרת המטא-נתונים ידחה את הבקשה שלכם. |
כדי לקבל הסבר מפורט על אפליקציה שמשתמשת בטכניקת האימות הזו משירות לשירות, אפשר לעיין במדריך לאבטחת שירותי Cloud Run.
שימוש באיחוד שירותי אימות הזהות של עומסי עבודה מחוץ ל- Google Cloud
אם בסביבה שלכם נעשה שימוש בספק זהויות שתומך באיחוד שירותי אימות הזהות של עומסי עבודה, אתם יכולים להשתמש בשיטה הבאה כדי לבצע אימות מאובטח לשירות Cloud Run שלכם מחוץ ל- Google Cloud:
מגדירים את חשבון השירות כמו שמתואר בקטע הגדרת חשבון השירות בדף הזה.
מגדירים את האיחוד של Workload Identity עבור ספק הזהויות, כפי שמתואר במאמר הגדרת איחוד של Workload Identity.
פועלים לפי ההוראות בקטע הענקת גישה לזהויות חיצוניות כדי להתחזות לחשבון שירות.
משתמשים ב-API בארכיטקטורת REST כדי לקבל אסימון לטווח קצר, אבל במקום להפעיל את
generateAccessTokenכדי לקבל טוקן גישה, מפעילים אתgenerateIdTokenכדי לקבל אסימון מזהה.לדוגמה, באמצעות cURL:
ID_TOKEN=$(curl -0 -X POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT:generateIdToken \ -H "Content-Type: text/json; charset=utf-8" \ -H "Authorization: Bearer $STS_TOKEN" \ -d @- <<EOF | jq -r .token { "audience": "SERVICE_URL" } EOF ) echo $ID_TOKEN
SERVICE_ACCOUNTהיא כתובת האימייל של חשבון השירות שהוגדר למאגר הזהויות של עומס העבודה כדי לגשת אליו, ו-SERVICE_URLהיא כתובת ה-URL של שירות Cloud Run שמופעל. הערך הזה צריך להיות כתובת ה-URL של השירות, גם כששולחים בקשות לתג תנועה ספציפי. $STS_TOKENהוא אסימון Security Token Service שקיבלתם בשלב הקודם בהוראות בנושא איחוד זהויות של עומסי עבודה.
אפשר לכלול את האסימון המזהה מהשלב הקודם בבקשה לשירות באמצעות כותרת Authorization: Bearer ID_TOKEN או כותרת X-Serverless-Authorization: Bearer ID_TOKEN. אם שני סוגי הכותרות מסופקים, רק הכותרת X-Serverless-Authorizationנבדקת.
שימוש במפתח של חשבון שירות שהורד מחוץ ל- Google Cloud
אם איחוד שירותי אימות הזהות של עומסי עבודה לא מתאים לסביבה שלכם, אתם יכולים להשתמש במפתח של חשבון שירות שהורדתם כדי לבצע אימות מחוץ ל-Google Cloud. מעדכנים את קוד הלקוח כך שישתמש בספריות האימות כפי שמתואר למעלה. מידע נוסף מופיע במאמר בנושא מפתח של חשבון שירות.
אפשר לקבל אסימון מזהה חתום על ידי Google באמצעות JWT בחתימה עצמית, אבל התהליך הזה מורכב מאוד ועלול להוביל לשגיאות. אלה השלבים הבסיסיים:
חתימה עצמית על JWT של חשבון שירות עם ההצהרה
target_audienceשמוגדרת לכתובת ה-URL של שירות הקבלה או לקהל בהתאמה אישית שהוגדר. אם לא משתמשים בדומיינים בהתאמה אישית, הערך שלtarget_audienceצריך להיות כתובת ה-URL של השירות, גם כששולחים בקשות לתג תנועה ספציפי.מחליפים את ה-JWT בחתימה עצמית באסימון מזהה עם חתימה של Google, שבו ההצהרה
audמוגדרת לכתובת ה-URL הקודמת.כוללים את האסימון המזהה בבקשה לשירות באמצעות כותרת
Authorization: Bearer ID_TOKENאו כותרתX-Serverless-Authorization: Bearer ID_TOKEN. אם מסופקות שתי הכותרות, רק הכותרתX-Serverless-Authorizationנבדקת.
קבלת בקשות מאומתות
בשירות הפרטי המקבל, אפשר לנתח את כותרת ההרשאה כדי לקבל את המידע שנשלח על ידי אסימון ה-Bearer.