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

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

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

מה תלמדו

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

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

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

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

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

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

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

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

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

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

הפעלת Cloud Shell

1. ב-Cloud Console, לוחצים על Activate Cloud Shell .

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

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

המכונה הווירטואלית הזו כוללת את כל הכלים שדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות של הרשת. אפשר לבצע את רוב העבודה ב-codelab הזה, אם לא את כולה, באמצעות דפדפן או 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. תשימו לב שהוא תומך בהשלמה אוטומטית של כרטיסיות. למידע נוסף, ראו סקירה כללית של כלי שורת הפקודה של 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 שישמש לאחסון קובץ ה-container של האפליקציה אחרי שהוא ייבנה:

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. השיעור Lab הזה מתמקד בהטמעה, ולכן לא עוסק בתחום הזה, אבל כדאי לחקור את הנושא בנפרד.

שלבים 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

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

איך נותנים הרשאה לחשבון

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

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 באמצעות Cloud Identity and Access Management (IAM) ב-Google Cloud, ולכן הוא צריך להיות מונפק וחתום על ידי רשות שמוכרת על ידי IAM. יש ספריות לקוח שזמינות בשפות רבות, שאפשר להשתמש בהן כדי לבקש הנפקת אסימון כזה. בדוגמה הזו נשתמש בספריית הלקוח של Python‏ google.auth. יש כמה ספריות 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 לשליחת בקשה עם כותרת הרשאה שנוספה:

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

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

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!

השלב הבא:

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

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

הסרת המשאבים

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

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

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