פריסה מאובטחת ל-Cloud Run

1. סקירה כללית

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

מה תלמדו

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

לאחר מכן נסביר איך להעניק הרשאת גישה לאפליקציה ולשלוח בקשות מורשות.

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

2. הגדרה ודרישות

הגדרת סביבה בקצב אישי

1. נכנסים למסוף Google Cloud ויוצרים פרויקט חדש או משתמשים מחדש בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או חשבון Google Workspace, עליכם ליצור חשבון.

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

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

הערה: אם אתם משתמשים בחשבון Gmail, תוכלו להשאיר את מיקום ברירת המחדל כפי שהוא – ללא ארגון. אם אתם משתמשים בחשבון Google Workspace, בחרו מיקום שמתאים לארגון שלכם.

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

הפעלת Cloud Shell

1. במסוף Cloud, לוחצים על Activate Cloud Shell .

אם זו הפעם הראשונה שאתם מפעילים את Cloud Shell, יוצג לכם מסך ביניים (מתחת לקצה המסך) עם תיאור של Cloud Shell. במקרה כזה, לוחצים על Continue (והמסך הזה לא יוצג לכם שוב). כך נראה המסך החד-פעמי:

תהליך ההקצאה והחיבור ל-Cloud Shell אמור להימשך רק כמה רגעים.

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

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

2. מריצים את הפקודה הבאה ב-Cloud Shell כדי לוודא שהאימות בוצע:

gcloud auth list

פלט הפקודה

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

הערה: כלי שורת הפקודה gcloud הוא כלי שורת הפקודה המאוחד והחזק ב-Google Cloud. הוא מותקן מראש ב-Cloud Shell. תוכלו לראות את התמיכה שלו בהשלמה באמצעות מקש Tab. למידע נוסף, קראו את הסקירה הכללית של כלי שורת הפקודה של Google Cloud.

3. מריצים את הפקודה הבאה ב-Cloud Shell כדי לוודא שפקודת gcloud מכירה את הפרויקט:

gcloud config list project

פלט הפקודה

[core]
project = <PROJECT_ID>

אם לא, אפשר להגדיר אותו באמצעות הפקודה הבאה:

gcloud config set project <PROJECT_ID>

פלט הפקודה

Updated property [core/project].

הגדרת הסביבה

בשיעור ה-Lab הזה מריצים פקודות בשורת הפקודה של Cloud Shell. בדרך כלל אפשר להעתיק את הפקודות ולהדביק אותן כפי שהן, אבל במקרים מסוימים תצטרכו לשנות את ערכי ה-placeholder לערכי נכונים.

1. מגדירים משתנה סביבה למזהה הפרויקט לשימוש בפקודות מאוחרות יותר:

export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export SERVICE_NAME=partner-registration-service

2. מפעילים את Cloud Run Service API שיפעיל את האפליקציה, את Firestore API שיספק אחסון נתונים מסוג NoSQL, את Cloud Build API שבו תשתמש פקודת הפריסה ואת Artifact Registry שיאחסן את קונטיינר האפליקציה במהלך ה-build:

gcloud services enable \
  run.googleapis.com \
  firestore.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com

3. מאתחלים את מסד הנתונים של Firestore במצב Native. הפקודה הזו משתמשת ב-App Engine API, לכן צריך להפעיל אותו קודם.

בפקודה צריך לציין אזור ל-App Engine, שבו לא נשתמש אבל חייבים ליצור אותו מסיבות היסטוריות, ואזור למסד הנתונים. אנחנו נשתמש ב-us-central ל-App Engine וב-nam5 למסד הנתונים. nam5 הוא המיקום הרב-אזורי בארצות הברית. מיקומים במספר אזורים ממקסמים את הזמינות והעמידות של מסד הנתונים.

gcloud services enable appengine.googleapis.com

gcloud app create --region=us-central
gcloud firestore databases create --region=nam5

4. משכפלים את המאגר של האפליקציה לדוגמה ועוברים לספרייה

git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git

cd cymbal-eats/partner-registration-service

3. קריאת קובץ ה-README

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

שלב 3 – מריצים את npm install

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

שלבים 4 ו-5 – עריכה והרצה של deploy.sh

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

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

שלבים 6 עד 11 – שליחת בקשות לדוגמה לאינטרנט כדי לוודא שההתנהגות תקינה

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

4. פריסה מאובטחת של השירות

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

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

יוצרים חשבון שירות ומעניקים לו את הגישה הנדרשת ל-Firestore/Datastore

gcloud iam service-accounts create partner-sa

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:partner-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role=roles/datastore.user

עריכת deploy.sh

משנים את הקובץ deploy.sh כדי להחריג גישה לא מאומתת (‎–no-allow-unauthenticated), ולציין את חשבון השירות החדש (‎–service-account) לאפליקציה שנפרסה. מתקנים את GOOGLE_PROJECT_ID למזהה הפרויקט שלכם.

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

gcloud run deploy $SERVICE_NAME \
  --source . \
  --platform managed \
  --region ${REGION} \
  --no-allow-unauthenticated \
  --project=$PROJECT_ID \
  --service-account=partner-sa@${PROJECT_ID}.iam.gserviceaccount.com

פריסת השירות

מריצים את הסקריפט deploy.sh משורת הפקודה:

./deploy.sh

בסיום הפריסה, בשורה האחרונה של הפלט של הפקודה תוצג כתובת ה-Service URL של האפליקציה החדשה. שומרים את כתובת ה-URL במשתנה סביבה:

export SERVICE_URL=<URL from last line of command output>

עכשיו מנסים לאחזר הזמנה מהאפליקציה באמצעות הכלי curl:

curl -i -X GET $SERVICE_URL/partners

הדגל -i בפקודה curl מציין שצריך לכלול כותרות תגובה בפלט. השורה הראשונה בפלט אמורה להיות:

HTTP/2 403

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

5. שליחת בקשות מאומתות

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

Authorization: Bearer identity-token

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

שליחת בקשה באמצעות חשבון המשתמש

הכלי של Google Cloud CLI יכול לספק אסימון למשתמש המאומת שמוגדר כברירת מחדל. מריצים את הפקודה הבאה כדי לקבל אסימון זהות לחשבון שלכם ולשמור אותו במשתנה הסביבה ID_TOKEN:

export ID_TOKEN=$(gcloud auth print-identity-token)

כברירת מחדל, אסימונים מזהים שהונפקו על ידי Google תקפים למשך שעה אחת. מריצים את הפקודה הבאה של curl כדי לשלוח את הבקשה שנדחתה בעבר כי לא הייתה לה הרשאה. הפקודה הזו תכלול את הכותרת הנדרשת:

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $ID_TOKEN"

הפלט של הפקודה צריך להתחיל ב-HTTP/2 200, כדי לציין שהבקשה מקובלת ומתבצעת. (אם מחכים שעה ומנסים שוב את הבקשה הזו, היא תיכשל כי תוקף הטוקן יפוג). גוף התגובה מופיע בסוף הפלט, אחרי שורה ריקה:

{"status":"success","data":[]}

עדיין אין שותפים.

רושמים שותפים באמצעות נתוני ה-JSON לדוגמה בספרייה באמצעות שתי פקודות curl:

curl -X POST \
  -H "Authorization: Bearer $ID_TOKEN" \
  -H "Content-Type: application/json" \
  -d "@example-partner.json" \
  $SERVICE_URL/partner

וגם

curl -X POST \
  -H "Authorization: Bearer $ID_TOKEN" \
  -H "Content-Type: application/json" \
  -d "@example-partner2.json" \
  $SERVICE_URL/partner

חוזרים על בקשת ה-GET הקודמת כדי לראות עכשיו את כל השותפים הרשומים:

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $ID_TOKEN"

אמורים להופיע נתוני JSON עם תוכן רב יותר, שמכילים מידע על שני השותפים הרשומים.

שליחת בקשה מחשבון לא מורשה

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

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

1. יוצרים חשבון שירות בשם tester.

gcloud iam service-accounts create tester

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

export USER_EMAIL=$(gcloud config list account --format "value(core.account)")

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="user:$USER_EMAIL" \
  --role=roles/iam.serviceAccountTokenCreator

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

export TEST_TOKEN=$( \
  gcloud auth print-identity-token \
    --impersonate-service-account \
    "tester@$PROJECT_ID.iam.gserviceaccount.com" \
)

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

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $TEST_TOKEN"

הפלט של הפקודה יתחיל שוב ב-HTTP/2 403 כי הבקשה, אף על פי שהיא מאומתת, לא מורשית. לחשבון השירות החדש אין הרשאה להפעיל את האפליקציה הזו.

מתן הרשאה לחשבון

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

export REGION=us-central1
gcloud run services add-iam-policy-binding ${SERVICE_NAME} \
  --member="serviceAccount:tester@$PROJECT_ID.iam.gserviceaccount.com" \
  --role=roles/run.invoker \
  --region=${REGION}

אחרי שממתינים דקה או שתיים עד שהתפקיד החדש יתעדכן, חוזרים על הבקשה המאומתת. שומרים אסימון TEST_TOKEN חדש אם חלפה שעה או יותר מאז השמירה הראשונה שלו.

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $TEST_TOKEN"

הפלט של הפקודה מתחיל עכשיו ב-HTTP/1.1 200 OK והשורה האחרונה מכילה את תגובת ה-JSON. הבקשה התקבלה על ידי Cloud Run ועובדה על ידי האפליקציה.

6. אימות תוכניות לעומת אימות משתמשים

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

מנגנון האימות המובנה של Cloud Run מיועד לשימוש בתוכניות, ולא במשתמשי קצה.

הערה:

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

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

בקשות מאומתות מתוכנית Python

תוכנית יכולה לשלוח בקשות מאומתות לאפליקציה מאובטחת של Cloud Run באמצעות בקשות אינטרנט רגילות של HTTP, אבל צריך לכלול כותרת Authorization. האתגר היחיד החדש בתוכניות האלה הוא לקבל אסימון זהות תקף ועדיין בתוקף כדי להוסיף לכותרת הזו. האסימון הזה יאומת על ידי Cloud Run באמצעות ניהול זהויות והרשאות גישה (IAM) ב-Google Cloud, לכן האסימון צריך להיות מונפק וחתום על ידי רשות שאושרה על ידי IAM. יש ספריות לקוח זמינות בשפות רבות שתוכניות יכולות להשתמש בהן כדי לבקש הנפקה של אסימון כזה. ספריית הלקוח שבה נשתמש בדוגמה הזו היא google.auth של Python. יש כמה ספריות Python ליצירת בקשות אינטרנט באופן כללי. בדוגמה הזו נעשה שימוש במודול הפופולרי requests.

בשלב הראשון צריך להתקין את שתי ספריות הלקוח:

pip install google-auth
pip install requests

הקוד ב-Python לבקשת אסימון זהות עבור משתמש ברירת המחדל הוא:

credentials, _ = google.auth.default()
credentials.refresh(google.auth.transport.requests.Request())
identity_token = credentials.id_token

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

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

הקוד ב-Python לשליחת בקשה עם כותרת Authorization שנוספה הוא:

auth_header = {"Authorization": "Bearer " + identity_token}
response = requests.get(url, headers=auth_header)

תוכנית Python המלאה הבאה תשלח בקשה מאומתת לשירות Cloud Run כדי לאחזר את כל השותפים הרשומים, ולאחר מכן תדפיס את השמות והמזהים שהוקצו להם. מעתיקים ומריצים את הפקודה הבאה כדי לשמור את הקוד הזה בקובץ print_partners.py.

cat > ./print_partners.py << EOF
def print_partners():
    import google.auth
    import google.auth.transport.requests
    import requests

    credentials, _ = google.auth.default()
    credentials.refresh(google.auth.transport.requests.Request())
    identity_token = credentials.id_token

    auth_header = {"Authorization": "Bearer " + identity_token}
    response = requests.get("${SERVICE_URL}/partners", headers=auth_header)

    parsed_response = response.json()
    partners = parsed_response["data"]

    for partner in partners:
        print(f"{partner['partnerId']}: {partner['name']}")


print_partners()
EOF

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

gcloud auth application-default login

פועלים לפי ההוראות כדי להשלים את תהליך הכניסה. לאחר מכן מריצים את התוכנית משורת הפקודה:

python print_partners.py

הפלט אמור להיראות כך:

10102: Zippy food delivery
67292: Foodful

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

7. מעולה!

כל הכבוד, סיימת את הקודלאב!

השלב הבא:

מדריכי Codelab נוספים של Cymbal Eats:

• הפעלת תהליכי עבודה ב-Cloud באמצעות Eventarc
• הפעלת עיבוד אירועים מ-Cloud Storage
• התחברות ל-CloudSQL פרטי מ-Cloud Run
• חיבור למסדי נתונים מנוהלים מ-Cloud Run
• אבטחה של אפליקציה ללא שרת באמצעות שרת proxy לאימות זהויות (IAP)
• הפעלת משימות של Cloud Run באמצעות Cloud Scheduler
• אבטחת תעבורת הנתונים הנכנסת (ingress) ב-Cloud Run
• התחברות ל-AlloyDB פרטי מ-GKE Autopilot

הסרת המשאבים

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

מחיקת הפרויקט

הדרך הקלה ביותר לבטל את החיוב היא למחוק את הפרויקט שיצרתם בשביל המדריך.