אם הארכיטקטורה שלכם משתמשת בכמה שירותים, סביר להניח שהשירותים האלה צריכים לתקשר זה עם זה, באמצעים אסינכרוניים או סינכרוניים. הרבה מהשירותים האלה יכולים להיות פרטיים, ולכן צריך פרטי כניסה כדי לגשת אליהם.
לתקשורת אסינכרונית, אתם יכולים להשתמש בשירותי Google Cloud הבאים:
- Cloud Tasks לתקשורת אסינכרונית של אחד לאחד
- Pub/Sub לתקשורת אסינכרונית של אחד לרבים, אחד לאחד ורבים לאחד
- Cloud Scheduler לתקשורת אסינכרונית מתוזמנת באופן קבוע
- Eventarc לתקשורת מבוססת-אירועים
בכל המקרים האלה, השירות שבו משתמשים מנהל את האינטראקציה עם השירות המקבל, על סמך ההגדרות שקבעתם.
אבל בתקשורת סינכרונית, השירות שלכם קורא לשירות אחר ישירות, באמצעות HTTP, דרך כתובת ה-URL של נקודת הקצה שלו. בתרחיש לדוגמה הזה, צריך לוודא שכל שירות יכול לשלוח בקשות רק לשירותים ספציפיים. לדוגמה, אם יש לכם שירות login, הוא אמור להיות מסוגל לגשת לשירות user-profiles, אבל לא לשירות search.
במצב כזה, Google ממליצה להשתמש ב-IAM ובזהות שירות שמבוססת על חשבון שירות מנוהל על ידי משתמשים לכל שירות, שקיבל את קבוצת ההרשאות המינימלית שנדרשת כדי לבצע את העבודה שלו.
בנוסף, הבקשה צריכה להציג הוכחה לזהות של השירות שמבצע את הקריאה. כדי לעשות את זה, צריך להגדיר את השירות שמבצע את הקריאה כך שיוסיף לבקשה טוקן של מזהה OpenID Connect שחתום על ידי Google.
הגדרת חשבון השירות
כדי להגדיר חשבון שירות, אתם צריכים להגדיר את השירות המקבל כך שיקבל בקשות מהשירות הקורא. לשם כך, אתם צריכים להפוך את חשבון השירות של השירות הקורא לחשבון משתמש בשירות המקבל. אחר כך מקצים לחשבון השירות את התפקיד Cloud Run Invoker (roles/run.invoker). כדי לבצע את שתי המשימות האלה, פועלים לפי ההוראות בכרטיסייה המתאימה:
ממשק המשתמש של המסוף
נכנסים למסוף Google Cloud :
בוחרים את השירות המקבל.
כדי להציג את הכרטיסייה Permissions, לוחצים על Show Info Panel בפינה הימנית העליונה.
לוחצים על Add principal.
מזינים את הזהות של השירות שמבצע את הקריאה. בדרך כלל מדובר בכתובת אימייל, כברירת מחדל
PROJECT_NUMBER-compute@developer.gserviceaccount.com.בוחרים את התפקיד
Cloud Run Invokerבתפריט הנפתח Select a role.לוחצים על 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 הבא הופך את השירות השני לפרטי, על ידי מתן הרשאה להפעיל אותו רק לחשבון השירות שמבצע את הקריאה החוזרת.
קבלת הטוקן של המזהה והגדרתו
אחרי שמקצים את התפקיד המתאים לחשבון השירות שמבצע את הקריאה, פועלים לפי השלבים הבאים:
משיגים טוקן של מזהה שחתום על ידי Google, באמצעות אחת מהשיטות שמתוארות בקטע הבא. מגדירים את טענת הקהל (
aud) לכתובת ה-URL של השירות המקבל או לקהל מותאם אישית שהוגדר. אם אתם לא משתמשים בקהל בהתאמה אישית, הערך שלaudחייב להישאר כתובת ה-URL של השירות, גם כששולחים בקשות לתג תנועה ספציפי.מוסיפים את טוקן המזהה שקיבלתם בשלב הקודם לאחת מהכותרות הבאות בבקשה לשירות המקבל:
- כותרת
Authorization: Bearer ID_TOKEN. - כותרת
X-Serverless-Authorization: Bearer ID_TOKEN. אפשר להשתמש בכותרת הזו אם האפליקציה כבר משתמשת בכותרתAuthorizationלהרשאה בהתאמה אישית. הפעולה הזו מסירה את החתימה לפני העברת הטוקן למאגר של המשתמש.
- כותרת
במאמר שיטות לקבלת טוקן של מזהה תוכלו לקרוא על דרכים אחרות לקבלת טוקנים של מזהים שלא מתוארות בדף הזה.
שימוש בספריות לאימות
אחת מהדרכים לקבל ולהגדיר את התהליך של טוקן של מזהה היא להשתמש בספריות האימות.
הקוד הזה פועל בכל סביבה, גם מחוץ ל- Google Cloud, שבה הספריות יכולות לקבל פרטי כניסה לאימות של חשבון שירות. כדי להשתמש בשיטה הזו, מורידים קובץ מפתח של חשבון שירות ומגדירים את משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS לנתיב של קובץ המפתח של חשבון השירות. למידע נוסף, קראו את המאמר מפתח של חשבון שירות.
הקוד הזה לא מקבל פרטי כניסה לאימות של חשבון משתמש.
Node.js
Python
Go
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 |
| Request header | הכותרת הבאה חייבת להופיע בכל בקשה: Metadata-Flavor: Google הכותרת הזו מציינת שהבקשה נשלחה במטרה לאחזר ערכי מטא-נתונים, ולא נשלחה בטעות ממקור לא מאובטח, ומאפשרת לשרת המטא-נתונים להחזיר את הנתונים שביקשתם. אם לא תספקו את הכותרת הזו, שרת המטא-נתונים ידחה את הבקשה. |
במדריך לאבטחת שירותי Cloud Run תוכלו למצוא הסבר מפורט על אפליקציה שמשתמשת בשיטת האימות הזו בין שירותים.
שימוש באיחוד זהויות של עומסי עבודה מחוץ ל- Google Cloud
אם הסביבה שלכם משתמשת בספק זהויות שנתמך על ידי איחוד שירותי אימות הזהות של עומסי עבודה, אתם יכולים להשתמש בשיטה הבאה כדי לאמת באופן מאובטח את שירות Cloud Run מחוץ ל- Google Cloud:
מגדירים את חשבון השירות כמו שמתואר בקטע הגדרת חשבון השירות בדף הזה.
מגדירים את איחוד שירותי אימות הזהות של עומסי עבודה עבור ספק הזהויות, כפי שמתואר במאמר הגדרת איחוד שירותי אימות הזהות של עומסי עבודה.
פועלים לפי ההוראות בקטע הענקת גישה לזהויות חיצוניות כדי להתחזות לחשבון שירות.
משתמשים ב-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נבדקת.
קבלת בקשות מאומתות
בשירות הפרטי שמקבל את הבקשה, אפשר לנתח את כותרת ההרשאה כדי לקבל את המידע שנשלח על ידי הטוקן למוכ"ז.