בעזרת VPC Service Controls אתם יכולים להגדיר מתחם אבטחה היקפית מסביב למשאבים של Google Cloud , כדי להגן מפני זליגת נתונים. אתם יכולים לכלול משימות של Cloud Scheduler בהיקף של VPC Service Controls כדי להגן על עומסי העבודה המתוזמנים ולהגביל את יעדי המשימות.
מגבלות
המגבלות הבאות חלות על התמיכה של VPC Service Controls ב-Cloud Scheduler.
פעולות אכיפה
הפעולות הבאות נאכפות על ידי VPC Service Controls:
- יצירת משימות ב-Cloud Scheduler
- עדכונים לגבי משימות ב-Cloud Scheduler
למה זה חשוב?
מכיוון ש-VPC Service Controls נאכף רק על יצירה ועדכון של משימות, הוא לא נאכף באופן אוטומטי על משימות שנוצרו לפני שהוספתם את Cloud Scheduler להיקף של VPC Service Controls. המשימות ממשיכות לפעול גם אם היעדים שלהן לא נמצאים בהיקף VPC Service Controls או שהם לא יעדים נתמכים. כדי לאכוף את VPC Service Controls בכל המשימות של Cloud Scheduler:
- משימות עם יעדים שלא נתמכים או שנמצאים מחוץ להיקף: מוחקים את המשימות. איך מוחקים משימות שלא עומדות בדרישות
- משימות עם יעדים שנתמכים ונמצאים בתוך היקף האבטחה: מריצים עדכון בכל משימה אחרי שמוסיפים את Cloud Scheduler להיקף האבטחה. איך אוכפים את VPC Service Controls על משימות קיימות
יעדים נתמכים
השילוב של Cloud Scheduler עם VPC Service Controls תומך ביעדים הבאים. נקודות קצה של HTTP נתמכות אם הן מופיעות ברשימה, אבל נקודות קצה שרירותיות של HTTP לא נתמכות.
- שירותי Cloud Run – צריך להשתמש בדומיין הקנוני שמוגדר כברירת מחדל ב-
run.app. אין תמיכה בדומיינים מותאמים אישית וב-DNS מותאם אישית, והם יגרמו לכך שיצירת המשימה תיכשל. - פונקציות Cloud Run – צריך להשתמש בדומיין הקנוני שמוגדר כברירת מחדל,
cloudfunctions.netאוrun.app. אין תמיכה בדומיינים מותאמים אישית וב-DNS מותאם אישית, והם יגרמו לכך שיצירת המשימה תיכשל. Google Cloud ממשקי API שתואמים ל-VPC Service Controls (בגרסת טרום-השקה או בגרסת זמינות כללית) יכולים להיות בפרויקט שונה Google Cloud מהמשימה של Cloud Scheduler.
צריך להשתמש בפורמט של נקודת הקצה הגלובלית (
https://SERVICE.googleapis.com). נקודות קצה אזוריות, כמו*.rep.googleapis.com,LOCATION.SERVICE.googleapis.comו-REGION-SERVICE.googleapis.com, ונקודות קצה של mTLS (*.mtls.googleapis.com) נדחות.הדרישה הזו רלוונטית רק לכתובות ה-URI של יעדי המשרות. כדי לשלוח בקשות משלכם ל-Cloud Scheduler API דרך נקודת קצה אזורית, קראו את המאמר שימוש בנקודות קצה אזוריות.
במשימות ב-Cloud Run, הפורמט הנתמך של ה-URI הוא:
https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/jobs/JOB_NAME:runבמאמר שירותים, משימות, מאגרי Worker ומכונות: ארבע דרכים להרצת הקוד מוסבר ההבדל בין שירות Cloud Run לבין משאבי משימות.
Pub/Sub
יעדים לא נתמכים
כש-Cloud Scheduler הוא שירות מוגבל בהיקף ההרשאות של VPC Service Controls, כל ניסיון ליצור או לעדכן משימה עם יעד לא נתמך ייכשל עם קוד השגיאה TARGET_TYPE_NOT_PERMITTED_FOR_VPC. הפעולה הזו לא יוצרת יומן הפרות כשמשתמשים במצב פרימטר לבדיקות.
דומיינים מותאמים אישית (כמו מאזני עומסים של אפליקציות (ALB) חיצוניים או DNS מותאם אישית) לנקודות קצה בלי שרת (serverless) הם לא יעדים נתמכים. קריאות בזמן ריצה לדומיינים מותאמים אישית נחסמות על ידי שירות היעד בגלל שחסרים פרטי כניסה בתוך ההיקף, גם למשימות קיימות שנוצרו לפני ההרשמה להיקף.
כדי למנוע חסימה לא צפויה של עומסי העבודה, לפני שמעבירים את גבולות הגזרה למצב אכיפה, צריך למחוק את כל המשימות עם יעדים לא נתמכים או עם יעדים מחוץ לגבולות הגזרה של VPC Service Controls שבהם אתם מתכוונים להשתמש.
מחיקת משרות שלא עומדות בדרישות
מומלץ. למחוק משימות ב-Cloud Scheduler עם יעדים שהם:
- לא נתמך (ראו יעדים נתמכים)
- מחוץ להיקף של VPC Service Controls שבו אתם מתכוונים להשתמש
אם לא תמחקו את המשימות האלה לפני שתוסיפו את Cloud Scheduler למתחם VPC Service Controls, המשימות ימשיכו לפעול אבל VPC Service Controls לא ייאכף עליהן. פעולות אכיפה
לדוגמה, אם יש לכם משימה ב-Cloud Scheduler שמטרגטת יעד לא נתמך (כמו נקודת קצה שרירותית של HTTP), המשימה תמשיך לפעול אחרי שתוסיפו את Cloud Scheduler להיקף של VPC Service Controls, אבל היא לא תהיה מוגנת על ידי VPC Service Controls. אותו דבר נכון לגבי משימה קיימת עם יעד מחוץ למתחם VPC Service Controls. עם זאת, אם משימה קיימת מטרגטת דומיין מותאם אישית בלי שרת (serverless) בתוך ההיקף, שירות היעד חוסם קריאות בזמן ריצה.
הוספת תפקידי IAM נדרשים
חובה. כדי להשתמש ב-VPC Service Controls, לחשבון השירות של Cloud Scheduler צריך להיות תפקיד סוכן השירות של Cloud Scheduler ב-IAM. חשבון השירות של Cloud Scheduler נוצר באופן אוטומטי בשביל הפרויקט. כדי לוודא שיש לו את תפקיד ה-IAM של סוכן השירות של Cloud Scheduler, או כדי להקצות לו את התפקיד הזה, מבצעים את הפעולות הבאות:
במסוף Google Cloud , נכנסים לדף IAM.
מסמנים את התיבה Include Google-provided role grants.
במסנן, מקלידים Cloud Scheduler Service Account ובוחרים את חשבון השירות הזה.
בודקים את העמודה Role של חשבון המשתמש Cloud Scheduler Service Account. אתם יכולים להמשיך אם התפקיד הבא מופיע ברשימה:
- סוכן השירות של Cloud Scheduler
אם התפקיד "סוכן שירות של Cloud Scheduler" לא מופיע ברשימה, לוחצים על הסמל Edit ונותנים את התפקיד Cloud Scheduler Service Agent לחשבון המשתמש של חשבון השירות של Cloud Scheduler.
הגדרת היקף של VPC Service Controls
חובה. אתם יכולים להשתמש במתחם קיים או ליצור מתחם חדש כדי להגן על משימות Cloud Scheduler עם יעדים נתמכים. בשתי הגישות אפשר לציין את השירותים שרוצים להגביל. מציינים את Cloud Scheduler API.
גבולות גזרה קיימים: כדי לעדכן גבולות גזרה קיימים של VPC Service Controls כך שיכללו את Cloud Scheduler, פועלים לפי השלבים לעדכון גבולות גזרה לשירות.
גבולות גזרה חדשים: כדי ליצור גבולות גזרה חדשים ל-Cloud Scheduler, פועלים לפי השלבים ליצירת גבולות גזרה לשירות.
אכיפת VPC Service Controls במשימות קיימות
מומלץ. כדי לאכוף את VPC Service Controls על משימות ב-Cloud Scheduler שיצרתם לפני שהוספתם את Cloud Scheduler לגבולות הגזרה של VPC Service Controls, צריך להריץ update על המשימה. לא צריך לשנות את המשימה, אבל צריך להריץ את העדכון כדי ש-VPC Service Controls יחול על המשימה ועל ההפעלות העתידיות שלה.
אפשר להריץ עדכון למשימה באמצעות מסוף Google Cloud (בוחרים את המשימה ולוחצים על Edit), ה-API או ה-CLI של gcloud.
כדי לאכוף את VPC Service Controls על משימה קיימת באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:
יעדי HTTP
gcloud scheduler jobs update http JOB_ID
מחליפים את JOB_ID במזהה המשימה.
יעדי Pub/Sub
gcloud scheduler jobs update pubsub JOB_ID
מחליפים את JOB_ID במזהה המשימה.