הגדרת VPC Service Controls

‫Managed Airflow (דור 3) | Managed Airflow (דור 2) | Managed Airflow (דור 1 מדור קודם)

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

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

התמיכה של VPC Service Controls ב-Managed Airflow מאפשרת:

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

פריסת סביבות Managed Airflow עם VPC Service Controls מספקת לכם:

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

מידע על VPC Service Controls ב-Managed Airflow

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

• אם סביבת Managed Airflow מוגנת על ידי היקף, הגישה למאגרי PyPI ציבוריים מוגבלת. מידע נוסף זמין במאמר בנושא התקנת חבילות PyPI ב-VPC Service Controls.

• אם בסביבה שלכם נעשה שימוש ברשתות עם כתובות IP פרטיות, כל התעבורה הפנימית מנותבת לרשת ה-VPC, למעט התעבורה לממשקי Google APIs, לשירותים ולדומיינים שזמינים בסביבות עם כתובות IP פרטיות דרך גישה פרטית ל-Google.

• בהתאם להגדרת רשת ה-VPC, סביבת IP פרטית יכולה לקבל גישה לאינטרנט דרך רשת ה-VPC.

• ב-Managed Airflow אי אפשר להשתמש בזהויות של צד שלישי בכללי כניסה ויציאה כדי לאפשר פעולות בממשק המשתמש של Apache Airflow. עם זאת, אפשר להשתמש בסוג הזהות ANY_IDENTITY בכללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) כדי לאפשר גישה לכל הזהויות, כולל זהויות של צד שלישי. מידע נוסף על סוג הזהות ANY_IDENTITY זמין במאמר כללי תעבורה נכנסת ותעבורה יוצאת.

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

מידע על קישוריות לממשקי API ולשירותים של Google ב-VPC Service Controls

‫Managed Airflow (דור 3) מנתב את התעבורה לשירותי Google דרך restricted.googleapis.com, וכך מאפשר גישה ל-Google APIs, לשירותים ולדומיינים שנתמכים בטווח הזה.

זהירות: אם הסביבה שלכם מצורפת לרשת VPC, כל התנועה הפנימית שלא מנותבת אל restricted.googleapis.com מנותבת אל רשת ה-VPC. בהתאם לאופן שבו מגדירים את רשת ה-VPC, הסביבה יכולה לקבל גישה לאינטרנט דרך רשת ה-VPC.

מידע נוסף ורשימה של השירותים והדומיינים שזמינים דרך restricted.googleapis.com מופיעים במאמר הגדרת רשת במסמכי ענן וירטואלי פרטי (VPC).

סביבות Managed Airflow (דור 3) חוסמות קריאות לממשקי Google API, לשירותים ולדומיינים שלא מופיעים ברשימת ממשקי ה-API והשירותים הנדרשים. כדי להפעיל API מ-DAG:

1. מוודאים שהשירות תומך ב-VPC Service Controls.
2. מוסיפים את השירות לרשימת השירותים המוגבלים.
3. מוסיפים את השירות לשירותים שאפשר לגשת אליהם ב-VPC.

לדוגמה, אם משתמשים ב-VertexAI Operator, צריך להוסיף את aiplatform.googleapis.comגם לשירותים מוגבלים וגם לשירותים שאפשר לגשת אליהם דרך VPC.

מידע נוסף על הוספת שירותים לגבול גזרה זמין במאמר ניהול גבולות גזרה לשירות במסמכי התיעוד של VPC Service Controls.

ב-Managed Airflow (דור 3), אי אפשר לגשת לשירותים שלא תומכים ב-VPC Service Controls ושלא זמינים דרך restricted.googleapis.com מתוך סביבות שמוגנות באמצעות VPC Service Controls. ההגבלה הזו נוספה ב-Managed Airflow (דור 3) כדי לשפר את אבטחת הסביבה. ב-Managed Airflow (דור 2) אפשר להגדיר גישה לשירותים כאלה שלא נתמכים, אבל אנחנו ממליצים מאוד להימנע מכך בכל סביבה שמוגנת על ידי VPC Service Controls.

היקפים לסביבות עם VPC משותף ו-CMEK

אם הסביבה שלכם מוגנת על ידי גבול גזרה לשירות ומשתמשת ב-VPC משותף, ב-Customer-Managed Encryption Keys (CMEK) או בשניהם, צריך לוודא שהפרויקטים הבאים נמצאים באותו גבול גזרה לשירות:

• פרויקט שירות: הפרויקט שמכיל את סביבת Managed Airflow.
• פרויקט מארח: הפרויקט שמכיל את רשת ה-VPC המשותפת.
• הפרויקט שמארח את המפתחות של Cloud Key Management Service.

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

יצירת סביבות בהיקף

כדי לפרוס את Managed Airflow בתוך היקף:

1. מפעילים את Access Context Manager API ואת Cloud Composer API בפרויקט. מידע נוסף זמין במאמר בנושא הפעלת ממשקי API.

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

   • Cloud Composer API ‏ (composer.googleapis.com)
   • ‫Artifact Registry API‏ (artifactregistry.googleapis.com)
   • ‫Compute Engine API‏ (compute.googleapis.com)
   • ‫Kubernetes Engine API‏ (container.googleapis.com)
   • Container File System API ‏ (containerfilesystem.googleapis.com)
   • ‫Cloud DNS API‏ (dns.googleapis.com)
   • ‫Backup for GKE API‏ (gkebackup.googleapis.com)
   • ‫Service Account Credentials API‏ (iamcredentials.googleapis.com)
   • Cloud Logging API ‏ (logging.googleapis.com)
   • ‫Cloud Monitoring API‏ (monitoring.googleapis.com)
   • Cloud Pub/Sub API ‏ (pubsub.googleapis.com)
   • ‫Cloud SQL Admin API‏ (sqladmin.googleapis.com)

   • Cloud Storage API (storage.googleapis.com)

   • לכל שאר השירותים שמשמשים את ה-DAG:

     1. מוסיפים את השירות לרשימת השירותים המוגבלים.
     2. מוסיפים את השירות לשירותים שאפשר לגשת אליהם ב-VPC.

3. אם גבולות גזרה לשירות מגבילים את הגישה ל-API באמצעות שירותים שנגישים ל-VPC, צריך לוודא שרשימת השירותים המורשים כוללת את כל השירותים שנעשה בהם שימוש ב-Managed Airflow.

4. יוצרים סביבת Managed Airflow חדשה:

   1. משתמשים ב-Google Cloud CLI כדי ליצור את הסביבה.
   2. מפעילים כתובת IP פרטית באמצעות הארגומנט --enable-private-environment.
   3. מציינים את פרמטרי הגישה לשרת האינטרנט באמצעות הארגומנטים --web-server-allow-all,‏ --web-server-allow-ip או --web-server-deny-all. מידע נוסף על השימוש בארגומנטים האלה זמין במאמר יצירת סביבות. כדי לשפר את ההגנה, כדאי לאפשר גישה לשרת האינטרנט רק מטווחים ספציפיים של כתובות IP.

   4. אפשר למנוע את ההתקנה של חבילות ממאגרי אינטרנט ציבוריים באמצעות הארגומנט --enable-private-builds-only.

      דוגמה:

      gcloud composer environments create example-environment \
        --location us-central1 \
        --enable-private-environment \
        --web-server-allow-all \
        --enable-private-builds-only
      

5. כברירת מחדל, הגישה לממשק המשתמש ול-API של Airflow מותרת רק מתוך היקף האבטחה. אם רוצים להפוך אותו לזמין מחוץ לגבולות האבטחה, צריך להגדיר רמות גישה או כללים לתעבורת נתונים נכנסת (ingress) וגם יוצאת (egress).

6. כברירת מחדל, בסביבה שלכם אין גישה למשאבים מחוץ למתחם ההיקפי, גם אם API תואם נוסף לרשימת השירותים שאפשר לגשת אליהם ב-VPC. כדי לאפשר גישה למשאבים מחוץ למתחם ההיקפי, צריך להגדיר גשר בין מתחמים היקפיים, כללי תעבורת נתונים יוצאת (egress) ונכנסת (ingress), או להעביר את המשאבים לאותו מתחם היקפי.

   לדוגמה, נניח שיש לכם מפתח Cloud KMS בהיקף A וסביבת Managed Airflow בהיקף B. גם אם תאפשרו את Cloud Key Management Service API בהיקף B באמצעות שירותים נגישים ל-VPC, עדיין לא תהיה לסביבה שלכם גישה למפתח. צריך גם להגדיר תקשורת מעבר לגבולות ההיקף.

הוספת סביבה קיימת להיקף

אפשר להוסיף את הפרויקט שמכיל את הסביבה להיקף אם הסביבות משתמשות בכתובת IP פרטית וההתקנה של חבילות PyPI ממאגרים ציבוריים מושבתת.

כדי לעדכן סביבת Managed Airflow (דור 3) קיימת להגדרה הזו:

1. חשוב לוודא שכבר יצרתם או הגדרתם את ההיקף כמו שמתואר בקטע הקודם.
2. משתמשים ב-Google Cloud CLI כדי לעדכן את הסביבה.
3. מפעילים כתובת IP פרטית באמצעות הארגומנט --enable-private-environment.
4. אפשר להשתמש בארגומנט --enable-private-builds-only כדי לא לאפשר התקנה של חבילות ממאגרי אינטרנט ציבוריים.
5. אם נדרש, מגדירים גישה לשרת האינטרנט של Airflow. כדי לשפר את ההגנה, כדאי לאפשר גישה לשרת האינטרנט רק מטווחים ספציפיים של כתובות IP.

דוגמה:

gcloud composer environments update example-environment \
  --location us-central1 \
  --enable-private-environment \
  --enable-private-builds-only

התקנת חבילות PyPI ב-VPC Service Controls

בהגדרת ברירת המחדל של VPC Service Controls, ‏ Managed Airflow תומך רק בהתקנת חבילות PyPI ממאגרים פרטיים שאפשר להגיע אליהם ממרחב כתובות ה-IP הפנימי של רשת ה-VPC.

לכל סביבות Managed Airflow שנמצאות בתוך היקף של VPC Service Controls אין גישה למאגרי PyPI ציבוריים כברירת מחדל.

התקנה ממאגר פרטי

ההגדרה המומלצת היא להגדיר מאגר PyPI פרטי:

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

התקנה ממאגר ציבורי

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

כדי להתקין חבילות PyPI ממאגר חיצוני:

1. יוצרים מאגר מרוחק של Artifact Registry.
2. מתן גישה למקורות במעלה הזרם למאגר הזה.
3. מגדירים את Airflow כך שיתקין חבילות ממאגר Artifact Registry.

יומנים של VPC Service Controls

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

בנוסף להודעות יומן אחרות, אפשר לבדוק ביומנים מידע על חשבונות שירות של [e-mail] ושל [e-mail] שמגדירים רכיבים של הסביבות שלכם.

שירות Managed Airflow משתמש בחשבון השירות [e-mail] כדי לנהל את רכיבי פרויקט הדייר בסביבות שלכם.

[e-mail] חשבון השירות, שנקרא גם חשבון השירות של סוכן השירות של Composer, מנהל את רכיבי הסביבה בפרויקטים של שירותים ופרויקטים מארחים.

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

• יצירת סביבות
• התקנת חבילות PyPI