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

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

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

מה תלמדו

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

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

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

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

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

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

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

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

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

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

הפעלת Cloud Shell

1. במסוף Cloud, לוחצים על 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. מפעילים את ה-API של שירות Cloud Run שיפעיל את האפליקציה, את ה-API של Firestore שיספק אחסון נתונים ב-NoSQL, את ממשק ה-API של Cloud Build שישמש לפקודת הפריסה ואת Artifact Registry שישמש לשמירת הקונטיינר של האפליקציה בזמן הפיתוח:

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

הרשאת חשבון

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

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

השלב הבא:

בקישורים הבאים תוכלו למצוא עוד מעבדי קוד Labs של Cymbal Eats:

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

הסרת המשאבים

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

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

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