אישור גישה באמצעות IAM

משתמשים בניהול זהויות והרשאות גישה (IAM) כדי לתת זהויות הרשאה לבצע פעולות ניהול בפונקציות שנוצרו באמצעות Cloud Functions v2 API – לדוגמה, באמצעות gcloud functions, API בארכיטקטורת REST או Terraform. פעולות ניהול כוללות יצירה, עדכון ומחיקה של פונקציות. מידע על גישת IAM לפונקציות שנוצרו באמצעות Cloud Run זמין במאמר בקרת גישה באמצעות IAM.

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

למידע נוסף על קבלת פרטי האימות המתאימים והצגתם, ראו אימות לצורך הפעלה.

לפני שמתחילים

כדי לקבל את ההרשאה שדרושה לשליטה בגישה לפונקציה ספציפית או לכל הפונקציות בפרויקט, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד אדמין של Cloud Functions (roles/roles/cloudfunctions.admin) בפונקציה או בפרויקט. להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

התפקיד המוגדר מראש הזה כולל את ההרשאה cloudfunctions.functions.setIamPolicy, שנדרשת כדי לשלוט בגישה לפונקציה ספציפית או לכל הפונקציות בפרויקט.

יכול להיות שתוכלו לקבל את ההרשאה הזו גם בתפקידים בהתאמה אישית או בתפקידים אחרים שמוגדרים מראש.

רשימה מלאה של התפקידים וההרשאות שמשויכות אליהם מופיעה במאמר תפקידי IAM ב-Cloud Functions.

הפעלת גישה לפונקציה

אפשר לשלוט בפעולות בפונקציה על ידי הקצאה או הגבלה של תפקידים לזהויות בודדות באמצעות IAM.

הוספת חשבונות משתמש והקצאת תפקידים

משתמשים בפקודה gcloud functions add-iam-policy-binding:

gcloud functions add-iam-policy-binding FUNCTION_NAME \
  --member=PRINCIPAL_ID \
  --role=ROLE

כאשר FUNCTION_NAME הוא שם הפונקציה, PRINCIPAL_ID הוא המזהה של חשבון המשתמש, בדרך כלל כתובת אימייל, ו-ROLE הוא התפקיד.

רשימת המקורות שיכולים לספק PRINCIPAL_ID מופיעה במאמר מזהים של חשבונות משתמשים. רשימת הערכים הקבילים של ROLE מופיעה בדף העזר בנושא תפקידים ב-IAM.

הסרת תפקידים מחשבונות משתמשים

משתמשים בפקודה gcloud functions remove-iam-policy-binding:

gcloud functions remove-iam-policy-binding FUNCTION_NAME \
  --member=PRINCIPAL_ID \
  --role=ROLE

כאשר FUNCTION_NAME הוא שם הפונקציה, PRINCIPAL_ID הוא כתובת האימייל שמזהה את חשבון השירות עם הקידומת serviceAccount:, ו-ROLE הוא התפקיד.

רשימת המקורות הקבילים ל-PRINCIPAL_ID מופיעה במאמר מזהים של חשבונות משתמשים. רשימת הערכים האפשריים של ROLE מופיעה בדף העזר בנושא תפקידי IAM.

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

הוספה של חשבונות משתמשים בכמות גדולה

יוצרים מדיניות IAM בשם, לדוגמה, policy.json:

  {
    "bindings": [
      {
        "role": ROLE,
        "members": [
        PRINCIPAL_ID
        ]
      }
    ]
  }

משתמשים בפקודה gcloud functions set-iam-policy:

gcloud functions set-iam-policy FUNCTION_NAME policy.json

רשימת המקורות הקבילים ל-PRINCIPAL_ID מופיעה במאמר מזהים של חשבונות משתמשים. רשימת הערכים הקבילים של ROLE מופיעה בדף העזר בנושא תפקידי IAM.

הצגת חשבונות ראשיים

כדי להציג את המשתמשים הראשיים, משתמשים בפקודה gcloud functions get-iam-policy:

gcloud functions get-iam-policy FUNCTION_NAME

אישור להפעלה של פונקציית HTTP לא מאומתת

בפונקציות שנוצרו באמצעות Cloud Functions v2 API, צריך לציין את האפשרות allow unauthenticated invocations במהלך הפריסה או אחריה.

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

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

בזמן הפריסה

הפקודה gcloud functions deploy כוללת הנחיה שתעזור לכם להגדיר הרשאות הפעלה במהלך יצירת הפונקציה. הוא יכול לכלול גם את הדגל --allow-unauthenticated:

gcloud functions deploy FUNCTION_NAME \
  --trigger-http \
  --allow-unauthenticated \
  ...

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

אחרי הפריסה

משתמשים בפקודה gcloud run services add-iam-policy-binding כדי להעניק את התפקיד roles/run.invoker לפונקציה הספציפית:

gcloud run services add-iam-policy-binding FUNCTION_NAME \
  --member="allUsers" \
  --role="roles/run.invoker"

מידע נוסף על השדות האלה מופיע במאמר gcloud run add-iam-policy-bindingהפניה.