זהות הפונקציה (דור ראשון)

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

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

חשבון שירות בזמן ריצה

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

• פונקציות Cloud Run משתמשות בחשבון השירות שמוגדר כברירת מחדל ב-App Engine,‏ [e-mail].

  שימו לב שמספר הפרויקט שונה ממזהה הפרויקט ומשם הפרויקט. אפשר לראות את מספר הפרויקט ב Google Cloud דף Dashboard במסוף.

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

כדי לאבטח את הפונקציות בסביבת הייצור:

• לשנות את ההרשאות בחשבון השירות שמוגדר כברירת מחדל בתחילת ההפעלה, או
• יצירה של חשבונות שירות נפרדים לפונקציות

שינוי הרשאות בחשבון שירות ברירת המחדל של זמן הריצה

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

המסוף

1. נכנסים לדף IAM במסוף Google Cloud :

   כניסה למסוף Google Cloud

2. בוחרים בחשבון השירות של App Engine שמוגדר כברירת מחדל או בחשבון השירות של Compute שמוגדר כברירת מחדל מהטבלה.

3. לוחצים על סמל העיפרון בצד שמאל של השורה כדי להציג את הכרטיסייה עריכת הרשאות.

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

5. לוחצים על Save.

gcloud

מסירים את התפקיד Editor ומשתמשים בפקודה gcloud projects add-iam-policy-binding כדי להוסיף תפקיד חדש:

# Remove the Editor role
gcloud projects remove-iam-policy-binding PROJECT_ID \
--member="SERVICE_ACCOUNT_EMAIL" \
--role="roles/editor"

# Add the desired role
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="SERVICE_ACCOUNT_EMAIL" \
--role="ROLE"

כאשר PROJECT_ID הוא מזהה הפרויקט שבו אתם משתמשים, SERVICE_ACCOUNT_EMAIL היא כתובת האימייל של חשבון השירות של זמן הריצה שמוגדר כברירת מחדל, כפי שמופיע בקטע חשבון השירות של זמן הריצה, ו-ROLE הוא התפקיד החדש שרוצים להקצות לחשבון השירות של זמן הריצה שמוגדר כברירת מחדל.

שימוש בחשבונות שירות נפרדים לפונקציות

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

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

3. אם חשבון השירות והפונקציה נמצאים בפרויקטים שונים, מהפרויקט שבו נמצא חשבון השירות:

   1. מגדירים את חשבון השירות כך שיפעל בין פרויקטים.

   2. מקצים את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) לסוכן השירות של פונקציות Cloud Run‏ ([e-mail]), כאשר PROJECT הוא הפרויקט שבו נמצאת הפונקציה. סוכן השירות של פונקציות Cloud Run מנהל את הגישה בין פרויקטים עבור חשבון השירות שלכם.

   3. נותנים את ההרשאה iam.serviceaccounts.actAs לסוכן השירות של פונקציות Cloud Run בחשבון השירות מהפרויקט השונה.

4. מעניקים לחשבון השירות גישה למשאב. השיטה לביצוע הפעולה הזו תלויה בסוג המשאב.

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

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

הוספת חשבון שירות שמנוהל על ידי משתמש במהלך הפריסה

המסוף

1. נכנסים למסוף Google Cloud :

   כניסה למסוף Google Cloud

2. מציינים ומגדירים את הפונקציה איך שרוצים.

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

4. בוחרים בכרטיסייה זמן ריצה.

5. לוחצים על התפריט הנפתח Service account ובוחרים את חשבון השירות הרצוי.

6. לוחצים על הבא ואז על פריסה.

gcloud

כשפורסים פונקציה באמצעות gcloud functions deploy, מוסיפים את הדגל --service-account. לדוגמה:

gcloud functions deploy --no-gen2 FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL

כאשר FUNCTION_NAME הוא שם הפונקציה ו-SERVICE_ACCOUNT_EMAIL הוא האימייל של חשבון השירות.

עדכון חשבון השירות של פונקציה קיימת

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

המסוף

1. נכנסים למסוף Google Cloud :

   כניסה למסוף Google Cloud

2. לוחצים על שם הפונקציה הרצויה כדי לעבור לדף הפרטים שלה.

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

4. לוחצים על זמן ריצה, בנייה... כדי להציג הגדרות נוספות.

5. בוחרים בכרטיסייה זמן ריצה.

6. לוחצים על התפריט הנפתח Service account ובוחרים את חשבון השירות הרצוי.

7. לוחצים על הבא ואז על פריסה.

gcloud

כשפורסים פונקציה באמצעות gcloud functions deploy, מוסיפים את הדגל --service-account:

gcloud functions deploy FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL

כאשר FUNCTION_NAME הוא שם הפונקציה ו-SERVICE_ACCOUNT_EMAIL הוא חשבון השירות.

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

שימוש בשרת המטא-נתונים כדי לקבל טוקנים

למרות שחשבונות שירות שמוגדרים ב-IAM הם השיטה המומלצת לניהול גישה ב- Google Cloud, יכול להיות ששירותים מסוימים ידרשו שיטות אחרות, כמו מפתח API, לקוח OAuth 2.0 או מפתח לחשבון שירות. יכול להיות שתידרשנה שיטות חלופיות כדי לגשת למשאב חיצוני.

אם שירות היעד דורש הצגה של אסימון מזהה של OpenID Connect או של אסימון גישה של OAuth 2.0, יכול להיות שתוכלו להשתמש בשרת המטא-נתונים של Compute כדי לאחזר את האסימונים האלה במקום להגדיר לקוח OAuth מלא.

הערה: אי אפשר להריץ שאילתות בשרת המטא-נתונים ישירות מהמחשב המקומי.

אסימוני זהות

אפשר להשתמש בשרת המטא-נתונים של Compute כדי לאחזר אסימוני מזהה עם קהל ספציפי באופן הבא:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
  -H "Metadata-Flavor: Google"

כאשר AUDIENCE הוא היעד המבוקש, לדוגמה: כתובת ה-URL של שירות שאתם מפעילים, כמו https://service.domain.com, או מזהה לקוח OAuth של משאב שמוגן על ידי IAP, כמו 1234567890.apps.googleusercontent.com.

אסימוני גישה

אסימוני גישה מסוג OAuth 2.0 משתמשים בהיקפי הרשאות כדי להגדיר הרשאות גישה. כברירת מחדל, אסימוני גישה בתוך Google Cloud הם בהיקף cloud-platform. כדי לגשת ל-Google APIs או ל- Google Cloud APIs אחרים, צריך לאחזר אסימון גישה עם היקף ההרשאות המתאים.

אתם יכולים להשתמש בשרת המטא-נתונים של Compute כדי לאחזר טוקנים של גישה.

אם אתם צריכים אסימון גישה עם היקף ספציפי, אתם יכולים ליצור אותו באופן הבא:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token?scopes=SCOPES" \
  -H "Metadata-Flavor: Google"

כאשר SCOPES היא רשימה מופרדת בפסיקים של היקפי הרשאות OAuth שהתבקשו, לדוגמה: https://www.googleapis.com/auth/drive,https://www.googleapis.com/auth/spreadsheets.

כדי לדעת אילו היקפי הרשאות אתם צריכים, תוכלו לעיין ברשימה המלאה של היקפי הרשאות OAuth של Google.

הערה: פרמטר השאילתה ?scopes= זמין רק בפונקציות של App Engine ו-Cloud Run.

השלבים הבאים

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