תפקידים והרשאות ליעדים ב-Cloud Run

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

  1. הענקת הרשאות ברמת הפרויקט לחשבון הראשי שמפעיל את ממשקי ה-API של Eventarc (לדוגמה, יוצר טריגר Eventarc):

    1. התפקיד Eventarc Admin מאפשר לכם שליטה מלאה בכל המשאבים של Eventarc, כולל ציון חשבון שירות לטריגר כשאתם יוצרים אותו.
    2. התפקיד משתמש בחשבון שירות מאפשר לחשבון משתמש להתחזות לחשבון שירות ולהשתמש בו. חשבון השירות משויך לטריגר Eventarc ומייצג את הזהות של הטריגר.

  2. מעניקים הרשאות להפעלת Eventarc לחשבון השירות של הטריגר: התפקיד Eventarc Event Receiver מאפשר לטריגר Eventarc לקבל אירועים מספקי אירועים. אין צורך להקצות את התפקיד אם אתם מעבירים אירועים ישירים מ-Cloud Pub/Sub.

  3. נותנים לחשבון השירות של הטריגר הרשאות לשירות Cloud Run: התפקיד Cloud Run Invoker מאפשר לטריגר Eventarc לקרוא את שירות היעד של Cloud Run. ההגדרה הזו רלוונטית אם אתם מעבירים אירועים לשירות Cloud Run מאומת.

  4. מתן הרשאות לסוכני שירות של Google:

    1. אם אתם יוצרים טריגר לאירועים ישירים מ-Cloud Storage, צריך להעניק את התפקיד Pub/Sub Publisher.
    2. אם הפעלתם את סוכן השירות של Cloud Pub/Sub ב-8 באפריל 2021 או לפני כן, צריך להקצות את התפקיד יצירת אסימונים בחשבון שירות.

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

מתן הרשאות ברמת הפרויקט

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

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

  1. התפקיד Eventarc Admin (roles/eventarc.admin) מאפשר שליטה מלאה בכל המשאבים של Eventarc.

    הקצאת התפקיד בפרויקט:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=PRINCIPAL \
    --role=roles/eventarc.admin

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫PRINCIPAL: מזהה של יוצר הטריגר. בדרך כלל בצורה הבאה: PRINCIPAL_TYPE:ID. לדוגמה: user:my-user@example.com. רשימה מלאה של הערכים האפשריים של PRINCIPAL_TYPE זמינה במאמרי העזרה בנושא קישור מדיניות.

  2. התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) מאפשר לחשבון משתמש להריץ פעולות בתור חשבון שירות.

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

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

    הקצאת התפקיד בפרויקט:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=PRINCIPAL \
    --role=roles/iam.serviceAccountUser

    אפשר גם להקצות את התפקיד לחשבון השירות:

    gcloud iam service-accounts add-iam-policy-binding \
    projects/SERVICE_ACCOUNT_PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com \
    --member=PRINCIPAL \
    --role=roles/iam.serviceAccountUser

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE_ACCOUNT_PROJECT_ID: Google Cloud מזהה הפרויקט שמכיל את חשבון השירות.
    • ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות.

מתן הרשאות להפעלת Eventarc

כל טריגר של Eventarc משויך לחשבון שירות של IAM בזמן יצירת הטריגר. אתם יכולים לציין חשבון שירות שמנוהל על ידי משתמש, שישמש את הטריגר כזהות ברירת המחדל שלו. אם לא מציינים חשבון שירות במהלך יצירת הטריגר, הטריגר משתמש בחשבון השירות שמוגדר כברירת מחדל של Compute Engine לזהות שלו.

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

  1. יוצרים חשבון שירות ורושמים את השם שלו:

    gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות. השם הזה מופיע כחלק מכתובת האימייל שמזהה את חשבון השירות.
    • DESCRIPTION: תיאור אופציונלי של חשבון השירות
    • DISPLAY_NAME: השם של חשבון השירות שיופיע ב Google Cloud מסוף

  2. מקצים את התפקיד 'מקבל אירועים ב-Eventarc' (roles/eventarc.eventReceiver) בפרויקט לחשבון השירות שמשויך לטריגר Eventarc, כדי שהטריגר יוכל לקבל אירועים מספקי אירועים.

    שימו לב שלא צריך להעניק את התפקיד Eventarc Event Receiver אם אתם מבצעים ניתוב של אירועים ישירים מ-Cloud Pub/Sub.

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/eventarc.eventReceiver

    מחליפים את SERVICE_ACCOUNT_NAME בשם של חשבון השירות שרשמתם בשלב הקודם.

מתן הרשאות לשירות Cloud Run

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

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

  1. אם אתם מעבירים אירועים לשירות יעד מאומת של Cloud Run, צריך להקצות את התפקיד Cloud Run Invoker (run.invoker) בשירות Cloud Run לחשבון השירות בניהול המשתמש שמשויך לטריגר Eventarc:

    gcloud run services add-iam-policy-binding SERVICE_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/run.invoker

    מחליפים את SERVICE_NAME בשם של שירות Cloud Run.

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

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

The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header.

מתן הרשאות לסוכני שירות

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

  1. אם יוצרים טריגר לאירועים ישירים מ-Cloud Storage, כדי לתמוך בפרסום הודעות בנושא, צריך להעניק את התפקיד 'פרסום הודעות ב-Pub/Sub' (roles/pubsub.publisher) בפרויקט לסוכן השירות של Cloud Storage:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com \
    --role=roles/pubsub.publisher

    מחליפים את PROJECT_NUMBER במספר הפרויקט ב- Google Cloud. אפשר לראות את מספר הפרויקט בדף Welcome במסוף Google Cloud או על ידי הרצת הפקודה הבאה:

    gcloud projects describe PROJECT_ID --format='value(projectNumber)'

  2. אם הפעלתם את סוכן השירות של Cloud Pub/Sub ב-8 באפריל 2021 או לפני כן, כדי לתמוך בבקשות push מאומתות של Pub/Sub, צריך להעניק את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) בפרויקט לסוכן השירות של Pub/Sub. אחרת, התפקיד הזה מוענק כברירת מחדל:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com \
    --role=roles/iam.serviceAccountTokenCreator

המאמרים הבאים