תפקידים והרשאות ליעדים ב-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 את התפקיד 'מקבל אירועים ב-Eventarc' (roles/eventarc.eventReceiver) בפרויקט, כדי שהטריגר יוכל לקבל אירועים מספקי אירועים.

    שימו לב שלא צריך להעניק את התפקיד 'מקבל אירועים ב-Eventarc' אם אתם מעבירים אירועים ישירות מ-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

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