שימוש ב-VPC Service Controls‏ (VPC SC)

‫VPC Service Controls הוא Google Cloud תכונה שמאפשרת להגדיר מתחם אבטחה היקפית כדי להגן מפני זליגת נתונים. גם כתובת ה-URL run.app שמוגדרת כברירת מחדל וגם דומיינים בהתאמה אישית כפופים ל-VPC Service Controls. במדריך הזה נסביר איך להשתמש ב-VPC Service Controls עם Cloud Run כדי להוסיף אבטחה לשירותים.

מגבלות והמלצות

  • ב-Artifact Registry או ב-Container Registry:

    • המאגר שבו מאחסנים את הקונטיינר צריך להיות באותו גבולות גזרה לשירות של VPC Service Controls כמו הפרויקט שבו מבצעים את הפריסה.
    • הקוד שנבנה צריך להיות באותם גבולות גזרה כמו הרישום שאליו מתבצעת הדחיפה של הקונטיינר.

  • התכונה פריסה רציפה לא זמינה בפרויקטים שנמצאים בתוך היקף של VPC Service Controls.

  • כשמפעילים שירותים של Cloud Run, אכיפת המדיניות של VPC Service Controls לא משתמשת בפרטי האימות של הלקוח ב-IAM. הבקשות האלה כפופות למגבלות הבאות:

    • אין תמיכה בכללי מדיניות תעבורת נתונים נכנסת (ingress) של VPC Service Controls שמשתמשים ב-IAM principals. רק סוג הזהות ANY_IDENTITY נתמך.
    • לא אפשרי להשתמש ברמות גישה לאזורים של VPC Service Controls שמשתמשים בישויות מורשות של IAM.

הגדרת הארגון לתמיכה ב-VPC Service Controls

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

אם אתם פורסים פונקציות של Cloud Run באמצעות gcloud functions, אתם או האדמין שלכם צריכים לתת לחשבון השירות של Cloud Build גישה למתחם ההיקפי של VPC Service Controls. מידע נוסף זמין במאמר סקירה כללית של תהליך build.

הגדרת היקף אבטחה של VPC Service Controls

בשלבים הבאים מוסבר איך להגדיר גבולות גזרה של VPC Service Controls.

  1. מוודאים שיש לכם את התפקידים הנדרשים לניהול VPC Service Controls.

  2. נכנסים לדף VPC Service Controls במסוף Google Cloud .

    מעבר לדף VPC Service Controls

  3. אם מוצגת בקשה לעשות זאת, בוחרים את הארגון.

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

  5. לוחצים על היקף חדש. מקלידים שם להיקף.

  6. בוחרים את הפרויקטים שרוצים לאבטח בתוך גבולות הגזרה.

    1. לוחצים על פרויקטים.

    2. בחלון הוספת פרויקטים, בוחרים את הפרויקטים שרוצים להוסיף.

      אם אתם משתמשים ב-VPC משותף, הקפידו להוסיף את הפרויקט המארח ואת פרויקטי השירות.

    3. לוחצים על הלחצן הוספת פרויקטים.

  7. בוחרים באפשרות Cloud Run כשירות שרוצים לאבטח בתוך ההיקף.

    1. לוחצים על שירותים מוגבלים.

    2. לוחצים על הוספת שירותים.

    3. מחפשים את Cloud Run. אחר כך בוחרים באפשרות Cloud Run Admin API. (בוחרים באפשרות Cloud Functions V2 API אם השתמשתם ב-gcloud functions).

    4. לוחצים על Add Cloud Run Admin API (הוספת Cloud Run Admin API) או על Cloud Functions V2 API (אם השתמשתם ב-gcloud functions).

  8. הפעלת גישה למפתחים.

    הפעלת VPC Service Controls ב-Cloud Run מונעת גישה מחוץ לגבולות הגזרה, כולל צפייה בשירותים ופריסתם ממכונות שלא נמצאות בגבולות הגזרה, כמו מחשבים ניידים של החברה. כדי שמפתחים ומפעילים של אפליקציות יוכלו להציג ולפרוס משאבים בתוך גבולות הגזרה, צריך להגדיר את מדיניות הכניסה של גבולות הגזרה:

    1. לוחצים על Ingress Policy (מדיניות כניסה).

    2. מציינים את המקור, הזהות, הפרויקט והשירותים.

    3. לוחצים על הוספת כלל.

    אם הארגון שלכם משתמש ב-Access Context Manager, אתם יכולים גם להגדיר רמות גישה כדי לאפשר גישה למפתחים.

  9. לוחצים על יצירת היקף.

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

הגדרה של מדיניות הארגון

כדי לנהל את מדיניות הארגון, צריך להיות לכם התפקיד אדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin).

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

הגבלת ההגדרות המותרות של תעבורת נתונים נכנסת (ingress)

מדיניות הארגון run.allowedIngress קובעת את הגדרות הכניסה שמפתחים יכולים להשתמש בהן ב-Cloud Run. כדי לאפשר רק בקשות פנימיות, צריך להגדיר את מדיניות הארגון כך שהמפתחים ישתמשו בערך internal. כדי לאפשר בקשות דרך מאזן עומסים חיצוני של אפליקציות (ALB), עם בקרות גישה שמנוהלות על ידי Cloud Load Balancing, צריך להגדיר את מדיניות הארגון כך שהמפתחים ישתמשו בערך internal-and-cloud-load-balancing.

מידע נוסף על ההגדרות האלה זמין במאמר הגבלת תעבורת כניסה ל-Cloud Run

המסוף

  1. נכנסים לדף המדיניות Allowed ingress settings (Cloud Run) במסוףGoogle Cloud :

    מעבר למדיניות הארגון

  2. לוחצים על Edit.

  3. בדף עריכה, בוחרים באפשרות התאמה אישית.

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

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

  6. בקטע סוג המדיניות, בוחרים באפשרות אישור.

  7. בקטע ערכים מותאמים אישית, מזינים internal. אם רוצים לאפשר גם תנועה של Cloud Load Balancing, לוחצים על ערך מדיניות חדש ומזינים internal-and-cloud-load-balancing.

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

gcloud

משתמשים בפקודה gcloud resource-manager org-policies allow:

gcloud resource-manager org-policies allow \
  run.allowedIngress internal \
  --organization ORGANIZATION_ID

כאשר ORGANIZATION_ID הוא מזהה הארגון. אם רוצים לאפשר גם תנועה של Cloud Load Balancing, מחליפים את run.allowedIngress internal ב-run.allowedIngress internal-and-cloud-load-balancing.

אחרי שמגדירים את מדיניות הארגון הזו, כל השירותים חייבים להשתמש בערכים המותרים בהגדרות הכניסה שלהם. המשמעות היא ששירותי Cloud Run יכולים לקבל רק תעבורת נתונים שמקורה ברשת VPC בתוך גבולות גזרה לשירות. ניסיונות להגדיר ערך אחר ל-ingress ייחסמו על ידי מדיניות הארגון.

הגבלת ההגדרות המותרות של תעבורת נתונים יוצאת (egress) ב-VPC

מדיניות הארגון run.allowedVPCEgress שולטת בהגדרות היציאה שמפתחים יכולים להשתמש בהן ב-Cloud Run. מגדירים את מדיניות הארגון כך שתאפשר רק את הערך all-traffic:

המסוף

  1. נכנסים לדף המדיניות Allowed VPC egress settings (Cloud Run) במסוףGoogle Cloud :

    מעבר למדיניות הארגון

  2. לוחצים על Edit.

  3. בדף עריכה, בוחרים באפשרות התאמה אישית.

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

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

  6. בקטע סוג המדיניות, בוחרים באפשרות אישור.

  7. בקטע ערכים מותאמים אישית, מזינים all-traffic.

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

gcloud

משתמשים בפקודה gcloud resource-manager org-policies allow:

gcloud resource-manager org-policies allow \
  run.allowedVPCEgress all-traffic \
  --organization ORGANIZATION_ID

כאשר ORGANIZATION_ID הוא מזהה הארגון.

אופן הפעולה אחרי הגדרת מדיניות הארגון

אחרי שמדיניות הארגון מוגדרת, כל הגרסאות החדשות צריכות להשתמש ביציאה ישירה מרשת ה-VPC או במחבר של חיבור לרשת (VPC) מאפליקציית serverless, ולהשתמש בערך all-traffic בהגדרות היציאה. השילוב הזה מנתב את כל תעבורת הנתונים היוצאת מהעדכונים האלה דרך רשת VPC, וכך התעבורה הזו כפופה לכללי חומת האש ולהגדרות אחרות של רשת ה-VPC. פריסות של גרסאות חדשות שמציינות ערך שונה נחסמות על ידי מדיניות הארגון.

מדיניות הארגון והעברות של תנועת גולשים

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

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

הגדרת הפרויקט לתמיכה ב-VPC Service Controls

כדי להשתמש ב-VPC Service Controls בפרויקטים ספציפיים בתוך גבולות הגזרה לשירות, צריך לבצע הגדרה נוספת.

הגדרת רשתות VPC

בקטע הזה מוסבר איך להגדיר את רשת ה-VPC כך שבקשות שנשלחות לדומיינים הרגילים של googleapis.com ינותבו אוטומטית לטווח כתובות ה-IP הווירטואליות (VIP) המוגבלות של 199.36.153.4/30 (restricted.googleapis.com), שבהן שירות Cloud Run פועל. אין צורך לבצע שינויים בקוד.

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

  1. מפעילים את הגישה הפרטית ל-Google ברשתות המשנה שמארחות את משאבי רשת ה-VPC.

  2. מגדירים כללי חומת אש כדי למנוע יציאת נתונים מרשת ה-VPC:

    • יוצרים כלל לדחיית תעבורת נתונים יוצאת שחוסם את כל התעבורה היוצאת.

    • יוצרים כלל שמאפשר תעבורת נתונים יוצאת (egress) אל 199.36.153.4/30 ביציאת TCP ‏443. חשוב לוודא שהיא מופיעה בעדיפות לפני כלל היציאה שדוחה את הבקשה שיצרתם – כך מתאפשרת יציאה רק לטווח ה-VIP המוגבל.

  3. יוצרים מדיניות תגובה ב-Cloud DNS.

    gcloud dns response-policies create RESPONSE_POLICY \
--networks=NETWORK \
--description=DESCRIPTION

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

    • ‫RESPONSE_POLICY: שם למדיניות התגובה.
    • NETWORK: השם של הרשת שאליה רוצים לשייך את המדיניות הזו. כדי לציין כמה רשתות, מפרידים בין השמות של כל רשת באמצעות פסיקים, למשל: network1,network2.
    • ‫DESCRIPTION: תיאור של מדיניות התגובה, כמו Cloud Run VPC Service Controls response policy

  4. מוסיפים כלל למדיניות התגובה כדי לפתור את *.googleapis.com ל-restricted.googleapis.com. טווח כתובות ה-IP של restricted.googleapis.com הוא 199.36.153.4/30.

    gcloud dns response-policies rules create RESPONSE_POLICY_RULE \
--response-policy=RESPONSE_POLICY \
--dns-name="*.googleapis.com." \
--local-data=name="restricted.googleapis.com.",type="A",ttl=300,rrdatas="199.36.153.4|199.36.153.5|199.36.153.6|199.36.153.7"

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

    • ‫RESPONSE_POLICY_RULE: שם לכלל מדיניות התגובה.
    • ‫RESPONSE_POLICY: השם של מדיניות התגובה שיצרתם בשלב הקודם, במירכאות.

  5. מוסיפים כלל למדיניות התגובה כדי לפתור את *.run.app (או *.cloudfunctions.net אם יצרתם את הפונקציה באמצעות gcloud functions deploy) ל-restricted.googleapis.com. טווח כתובות ה-IP של restricted.googleapis.com הוא 199.36.153.4/30.

    gcloud dns response-policies rules create RESPONSE_POLICY_RULE \
--response-policy=RESPONSE_POLICY \
--dns-name="*.run.app." \
--local-data=name="restricted.googleapis.com.",type="A",ttl=300,rrdatas="199.36.153.4|199.36.153.5|199.36.153.6|199.36.153.7"

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

    • ‫RESPONSE_POLICY_RULE: שם לכלל מדיניות התגובה.
    • ‫RESPONSE_POLICY: השם של מדיניות התגובה שציינתם בשלב הקודם, במירכאות.

בשלב הזה, בקשות שמקורן בתוך רשת ה-VPC:

  • לא יכולים לצאת מרשת ה-VPC, ולכן מונעים יציאה מחוץ לגבולות הגזרה של השירות.
  • יכולה לגשת רק לממשקי API ולשירותים של Google שבודקים את VPC Service Controls, וכך למנוע זליגת מידע דרך ממשקי API של Google.

פריסת שירותים ומשימות ב-Cloud Run שתואמים ל-VPC Service Controls

אחרי שמגדירים את VPC Service Controls ל-Cloud Run, מוודאים שכל השירותים והמשימות של Cloud Run שנפרסו בתוך גבולות גזרה לשירות מפעילים את VPC Service Controls. לשם כך צריך:

  • שירותים ועבודות ב-Cloud Run חייבים להשתמש בתעבורת נתונים יוצאת (egress) ישירה של VPC או במחבר של חיבור לרשת (VPC) מאפליקציית serverless. מידע נוסף זמין במאמר התחברות לרשת VPC.
  • שירותים ומשימות ב-Cloud Run חייבים לנתב את כל התנועה היוצאת דרך רשת ה-VPC. מידע נוסף זמין במאמר הגדרות של תעבורת נתונים יוצאת.
  • שירותי Cloud Run צריכים לאפשר תנועה ממקורות פנימיים בלבד. מידע נוסף מופיע בקטע הגדרות Ingress. הגדרת הכניסה ל-'all' משביתה את האכיפה של VPC Service Controls.

בדיקת תאימות של שירותים קיימים ל-VPC Service Controls

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

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