שימוש באימות עם HTTP Target

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

הגדרה של חשבון שירות

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

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

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

1. אם אין לכם חשבון שירות שאתם רוצים להשתמש בו למשימות של Cloud Scheduler עם יעדי HTTP, צרו חשבון שירות חדש. חשוב לזכור:

   • חשבון השירות צריך להיות שייך לפרויקט שבו נוצרה המשימה של Cloud Scheduler.

   • אל תשתמשו בסוכן השירות של Cloud Scheduler ‏(service-PROJECT_NUMBER@gcp-sa-cloudscheduler.), כי אי אפשר להשתמש בו למטרה הזו.

   • אל תבטלו את התפקיד "סוכן שירות של Cloud Scheduler" (roles/cloudscheduler.serviceAgent) של סוכן השירות של Cloud Scheduler בפרויקט. אם תעשו את זה, תקבלו תשובות מסוג 403 לנקודות קצה (endpoints) שדורשות אימות, גם אם לחשבון השירות של המשימה יש את התפקיד המתאים.

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

   לדוגמה, ב-Cloud Run ובפונקציות Cloud Run צריך להקצות את התפקיד מפעיל Cloud Run (roles/run.invoker), וב-Cloud Functions (דור ראשון) צריך להקצות את התפקיד מפעיל Cloud Functions (roles/cloudfunctions.invoker).

   כדי לקבל את ההרשאה שנדרשת כדי לצרף חשבון שירות למשאב, בקשו מהאדמין לתת לכם את תפקיד ה-IAM משתמש בחשבון שירות (roles/iam.serviceAccountUser) בחשבון השירות. התפקיד המוגדר מראש הזה כולל את ההרשאה iam.serviceAccounts.actAs, שנדרשת כדי לצרף חשבון שירות למשאב. (אם אתם יצרתם את חשבון השירות, ההרשאה הזו ניתנת לכם באופן אוטומטי).

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

   אם בשלב הקודם יצרתם חשבון שירות ספציפי כדי להפעיל את השירות שאליו מטרגט ה-Cloud Scheduler job, אתם יכולים לפעול לפי העיקרון של הרשאות מינימליות על ידי קישור החשבון והרשאת ההפעלה שלו לשירות המטורגט:

   המסוף

   1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב-Google Cloud .

      כניסה לדף לבחירת הפרויקט

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

   3. מסמנים את התיבה שמימין לשירות שרוצים להפעיל. (לא לוחצים על השירות עצמו).

   4. לוחצים על הכרטיסייה Permissions.

      אם חלונית המידע לא מוצגת, יכול להיות שתצטרכו ללחוץ על Show Info Panel > Permissions.

   5. לוחצים על Add principal.

   6. בשדה New principals, מזינים את כתובת האימייל של חשבון השירות שיצרתם.

   7. ברשימה Select a role, בוחרים את התפקיד שרוצים להקצות.

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

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

   gcloud

   gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID \
       --member=PRINCIPAL \
       --role=ROLE
   

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

   • ‫RESOURCE_TYPE: סוג המשאב של היעד. לדוגמה, run services ליעד של שירות Cloud Run.
   • ‫RESOURCE_ID: המזהה של היעד. לדוגמה, שם של שירות Cloud Run.
   • ‫PRINCIPAL: המזהה של חשבון השירות. הפורמט של הכתובת הוא: serviceAccount:SERVICE_ACCOUNT_EMAIL_ADDRESS. לדוגמה, serviceAccount:my-service-account@my-project..
   • ‫ROLE: שם התפקיד שנדרש להפעלה של שירות היעד. לדוגמה, roles/run.invoker ליעד של שירות Cloud Run. ליעדים של פונקציות Cloud Run, מומלץ להשתמש בפקודה add-invoker-policy-binding.

   דוגמאות:

   • משתמשים בפקודה gcloud run services add-iam-policy-binding כדי להקצות את התפקיד Cloud Run Invoker‏ (roles/run.invoker) ב-IAM לחשבון השירות my-service-account@my-project. בשירות Cloud Run‏ my-service:

     gcloud run services add-iam-policy-binding my-service \
         --region=REGION \
         --member=serviceAccount:my-service-account@my-project. \
         --role=roles/run.invoker
     

   • משתמשים בפקודה gcloud functions add-invoker-policy-binding כדי להקצות את התפקיד המתאים לחשבון השירות my-service-account@my-project. בפונקציית Cloud Run‏ my-cloud-function.

     בפונקציות Cloud Run, הפעולה הזו מוסיפה את הקישור Cloud Run Invoker (roles/run.invoker) למדיניות ה-IAM של השירות הבסיסי של Cloud Run בפונקציה שצוינה. ב-Cloud Functions (דור ראשון), הפעולה הזו מוסיפה את הקישור Cloud Functions Invoker‏ (roles/cloudfunctions.invoker) למדיניות ה-IAM של הפונקציה שצוינה:

     gcloud functions add-invoker-policy-binding my-cloud-function \
         --region=REGION \
         --member=serviceAccount:my-service-account@my-project.
     

   במאמר יצירת חשבון שירות ל-Cloud Scheduler מופיעה דוגמה לשימוש ב-Terraform כדי ליצור חשבון שירות עם הרשאה להפעיל שירות של Cloud Run.

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

4. סוכן השירות שמוגדר כברירת מחדל של Cloud Scheduler מוגדר באופן אוטומטי כשמפעילים את Cloud Scheduler API, אלא אם הפעלתם אותו לפני 19 במרץ 2019. במקרה כזה, צריך להקצות את התפקיד "סוכן שירות של Cloud Scheduler". כך הוא יוכל ליצור אסימוני כותרת בשם חשבון השירות שלכם, כדי לאמת את היעד.

יצירת משימה ב-Cloud Scheduler שמשתמשת באימות

כדי לבצע אימות בין Cloud Scheduler לבין יעד HTTP, ‏Cloud Scheduler יוצר אסימון כותרת על סמך חשבון השירות של הלקוח, שמזוהה באמצעות כתובת האימייל שלו, ושולח אותו ליעד באמצעות HTTPS. אפשר להשתמש באסימון מזהה (OIDC) או באסימון OAuth (גישה). בדרך כלל משתמשים ב-OIDC, חוץ מאשר בממשקי Google API שמתארחים ב-*.googleapis.com: ממשקי ה-API האלה מצפים לאסימון OAuth, ו-Cloud Scheduler מקבל אסימוני OAuth רק לכתובות URL של יעדים שמתארחים ב-*.googleapis.com.

הערה: אם המשימה של Cloud Scheduler משתמשת באימות OIDC וגם הפונקציה מצפה לארגומנטים בצורה של פרמטרים של כתובת URL (לדוגמה, my_function?key=value), צריך לוודא שהשדה Audience (aud) של OIDC לא מכיל את הפרמטרים של כתובת ה-URL.

כדי ליצור משימה ב-Cloud Scheduler שמשתמשת באימות, צריך להוסיף את סוג האסימון ואת כתובת האימייל שמזהה את חשבון השירות של הלקוח כשיוצרים את המשימה:

המסוף

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

   כניסה ל-Cloud Scheduler

2. לוחצים על Create job.

3. בשדה Name, נותנים למשימה שם ייחודי לפרויקט ולאזור. אחרי שמוחקים את המשימה שמשויכת לשם, אפשר להשתמש בו שוב.

4. ברשימה Region, בוחרים אזור למשימה.

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

6. לוחצים על Continue.

7. ברשימה Target type, בוחרים באפשרות HTTP.

8. מציינים כתובת URL שמתחילה ב-https:// ושיטת HTTP.

9. ברשימה Auth header, בוחרים את סוג הטוקן. בדרך כלל משתמשים באסימון OIDC, חוץ מאשר בממשקי Google API שמתארחים ב-*.googleapis.com, כי ממשקי ה-API האלה מצפים לאסימון OAuth.

10. ברשימה Service account, בוחרים את כתובת האימייל של חשבון השירות.

11. אם רוצים, אפשר לציין קהל כדי להגביל את הנמענים של אסימון ה-OIDC. בדרך כלל, כתובת היעד של המשימה בלי פרמטרים של כתובת URL. אם לא מציינים קהל, כתובת ה-URL המלאה משמשת כקהל, כולל פרמטרים של בקשות.

12. קובעים את ההגדרות האופציונליות.

13. לוחצים על יצירה.

gcloud

gcloud scheduler jobs create http JOB_ID \
    --location=LOCATION \
    --schedule="FREQUENCY" \
    --uri=URI \
    --oidc-service-account-email=SERVICE_ACCOUNT_EMAIL

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

• ‫JOB_ID: שם למשימה, שהוא ייחודי לפרויקט ולאזור. אחרי שמוחקים את המשימה שמשויכת לשם, אפשר להשתמש בו שוב.
• ‫LOCATION: המיקום (האזור) של המשימה.
• ‫FREQUENCY: המרווח או התדירות שבהם המשימה תרוץ. לדוגמה, every 3 hours או every 10 mins. המחרוזת שאתם מספקים כאן יכולה להיות כל מחרוזת שתואמת ל-unix-cron.
• ‫URI: כתובת ה-URL המלאה מסוג HTTPS של נקודת הקצה (חייבת להתחיל ב-https://).
• ‫SERVICE_ACCOUNT_EMAIL: כתובת האימייל של חשבון השירות. בדרך כלל משתמשים באסימון OIDC, חוץ מממשקי Google API שמתארחים ב-*.googleapis.com, כי ממשקי ה-API האלה מצפים לאסימון OAuth. (במקום זאת, השתמשו בדגל --oauth-service-account-email כדי להגדיר סוג של אסימון OAuth).
• פרמטרים אופציונליים אחרים מתוארים בחומר העזר של שורת הפקודה gcloud.

הקצאת התפקיד "סוכן שירות של Cloud Scheduler"

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

לסוכן השירות של Cloud Scheduler נדרש התפקיד סוכן השירות של Cloud Scheduler (roles/cloudscheduler.serviceAgent). בלי התפקיד הזה, משימות של Cloud Scheduler שדורשות את סוכן השירות (כמו משימות של יעד HTTP שמשתמשות באימות ומשימות של יעד Pub/Sub) ייכשלו. אתם יכולים להקצות את התפקיד באופן ידני לסוכן השירות של Cloud Scheduler, שכתובת האימייל שלו היא בפורמט הבא:

service-PROJECT_NUMBER@gcp-sa-cloudscheduler.

צריך להקצות את התפקיד באופן ידני רק אם מתקיים אחד מהתנאים הבאים:

• הפעלתם את Cloud Scheduler API לפני 19 במרץ 2019
• הסרתם את התפקיד "סוכן שירות של Cloud Scheduler" מסוכן השירות

כדי לוודא שסוכן השירות של Cloud Scheduler מוגדר בפרויקט ושהוקצה לו התפקיד "סוכן השירות של Cloud Scheduler", אתם יכולים לבדוק את הרשאות הגישה הנוכחיות לפרויקט. שימו לב: אם אתם משתמשים במסוף Google Cloud כדי לראות את הגישה לפרויקט, ודאו שסימנתם את התיבה Include Google-provided role grants.

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

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

איך מבצעים אימות ב-Cloud Scheduler באופן פרוגרמטי