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

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

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

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

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

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

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

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

    2. אם אתם יוצרים טריגר לאירועים ישירים מ-Cloud Storage, הקצו את התפקיד מפרסם Pub/Sub לסוכן השירות של Cloud Storage.

    3. אם הפעלתם את סוכן השירות של Cloud Pub/Sub ב-8 באפריל 2021 או לפני כן, אתם צריכים להקצות לסוכן השירות של Pub/Sub את התפקיד יצירת אסימונים בחשבון שירות.

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

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

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

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

  1. התפקיד "אדמין ב-Eventarc" (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 (למידע על תפקידים נוספים שנדרשים כדי לפרוס שירות, ראו התפקידים הנדרשים לפריסת שירותי 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, כדי שהטריגר יוכל לקבל אירועים מספקי אירועים.

    שימו לב: אם אתם מנתבים אירועים ישירים מ-Cloud Pub/Sub, אתם לא צריכים להקצות את התפקיד "מקבל אירועים ב-Eventarc".

    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" (roles/run.invoker) בשירות Cloud Run לחשבון השירות בניהול המשתמש שמשויך לטריגר של Eventarc:

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

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

    • ‫SERVICE_NAME: השם של שירות Cloud Run.
    • ‫REGION: האזור שבו נפרס שירות Cloud Run.

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

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

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

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

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

  1. אם התפקיד "סוכן שירות של Eventarc" (roles/eventarc.serviceAgent) הוסר מסוכן השירות של Eventarc, צריך להקצות את התפקיד בפרויקט כדי ש-Eventarc יוכל לנהל את משאבי התעבורה הבסיסיים ולאמת את מקורות האירועים. אחרת, התפקיד הזה מוקצה כברירת מחדל כשיוצרים משאב Eventarc בפעם הראשונה:

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

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

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

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

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

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

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

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