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

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

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

השלב הבא:

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

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

הסרת המשאבים

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

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

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