הגדרת גישה לאינטרנט וכללים לחומת אש

במאמר הזה מוסבר איך לבצע את הפעולות הבאות:

  • הגדרת גישה לאינטרנט למכונות וירטואליות (VM) ב-Dataflow
  • שימוש בתגים כדי לאבטח את הרשת של מכונות וירטואליות של עובדים.
  • הגדרת כללי חומת אש לרשת שמשויכת למשימות Dataflow

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

גישה ל Google Cloud ממשקי API ל-Dataflow

מכונות וירטואליות (VM) של עובדי Dataflow צריכות להגיע אלGoogle Cloud ממשקי API ושירותים. יכול להיות שקבוצת נקודות הקצה התלויות Google Cloud תשתנה לאורך זמן, אבל כולן תומכות ב-VPC Service Controls. כדי להגדיר גישה לממשקי API של Google Cloud , אפשר להשתמש באחת מהשיטות הבאות:

כברירת מחדל, כללים של חומת אש והגדרות DNS מאפשרים גישה ל-Google Cloud API. עם זאת, יכול להיות שאתם מגבילים באופן פעיל את הגישה לקבוצת משנה של ממשקי API, למשל אם אתם משתמשים ב-VPC Service Controls. Google Cloud במקרה כזה, צריך לספק גישה לפחות אל restricted.googleapis.com. אם אתם משתמשים ב-Private Service Connect, צריך לספק גישה לvpc-sc חבילה. מתן גישה לדומיינים עם הרשאות רחבות יותר, כמו private.googleapis.com, מספק גם את הפונקציונליות הנדרשת.

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

  • כללי חומת האש צריכים לאפשר יציאה לכל טווחי הכתובות בדומיין שנבחר.

  • רזולוציית ה-DNS של *.googleapis.com צריכה להיות הדומיין שבחרתם.

לדוגמה, אם כללי חומת האש מגבילים את התעבורה היוצאת לטווח הכתובות restricted.googleapis.com, אז הכתובות של *.googleapis.com צריכות להיות בטווח הזה. מידע נוסף זמין במאמר בנושא הגדרת DNS עבור googleapis.com.

באופן דומה, אם אתם משתמשים ב-Private Service Connect, אתם צריכים ליצור רשומות DNS עבור דומיין ברירת המחדל כדי להבטיח גישה לכל השירותים לפחות בvpc-sc חבילה.googleapis.com

גישה לאינטרנט ל-Dataflow

בהתאם לתרחיש לדוגמה, יכול להיות שגם מכונות ה-VM יצטרכו גישה למשאבים מחוץ ל-Google Cloud. כדי להגדיר גישה לאינטרנט ל-Dataflow, אפשר להשתמש באחת מהשיטות הבאות:

  • מגדירים מכונות וירטואליות של Worker עם כתובת IP חיצונית כדי לעמוד בדרישות הגישה לאינטרנט.

  • מגדירים פתרון NAT, כמו Cloud NAT. האפשרות הזו מתאימה להרצת משימות שדורשות גישה לאינטרנט כדי לגשת לממשקי API ולשירותים מחוץ ל- Google Cloud . לדוגמה, יכול להיות שמשימות של Python SDK ידרשו גישה לאינדקס חבילות Python ‏(PyPI) כדי להוריד יחסי תלות של צינורות. במקרה כזה, צריך להגדיר מכונות וירטואליות של Worker עם כתובות IP חיצוניות או להשתמש ב-Cloud NAT. אפשר גם לספק תלות בצינור עיבוד נתונים של Python במהלך שליחת העבודה. לדוגמה, אפשר להשתמש בקונטיינרים בהתאמה אישית כדי לספק יחסי תלות של צינור עיבוד נתונים ב-Python, וכך לא צריך לגשת ל-PyPI בזמן הריצה.

    מידע נוסף זמין במאמר ניהול תלות בצינורות Python במאמרי העזרה של Apache Beam.

השבתה של כתובת IP חיצונית

כברירת מחדל, Dataflow מקצה לעובדים כתובות IP חיצוניות ופנימיות. כשמשביתים כתובות IP חיצוניות, עבודת Dataflow יכולה לגשת רק למשאבים במקומות הבאים:

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

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

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

כדי להשבית כתובות IP חיצוניות, מבצעים אחת מהפעולות הבאות:

Java

  1. מפעילים את הגישה הפרטית ל-Google ברשת או ברשת המשנה.
  2. בפרמטרים של עבודת Dataflow, מציינים --usePublicIps=false ו---network=NETWORK-NAME או --subnetwork=SUBNETWORK-NAME.

    בהתאם לבחירה, מחליפים אחד מהערכים הבאים:

    • ‫NETWORK-NAME: השם של רשת Compute Engine
    • ‫SUBNETWORK-NAME: השם של רשת המשנה ב-Compute Engine

Python

  1. כדי להכין את כל יחסי התלות של חבילות Python, פועלים לפי ההוראות בנושא יחסי תלות של צינורות נתונים ב-Apache Beam.
  2. מפעילים את הגישה הפרטית ל-Google ברשת או ברשת המשנה.

  3. בפרמטרים של עבודת Dataflow, מציינים --no_use_public_ips ו---network=NETWORK או --subnetwork=SUBNETWORK.

    בהתאם לבחירה, מחליפים אחד מהערכים הבאים:

    • ‫NETWORK-NAME: השם של רשת Compute Engine
    • ‫SUBNETWORK-NAME: השם של רשת המשנה ב-Compute Engine

המשך

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

  2. בפרמטרים של עבודת Dataflow, מציינים --no_use_public_ips ו---network=NETWORK או --subnetwork=SUBNETWORK.

    בהתאם לבחירה, מחליפים אחד מהערכים הבאים:

    • ‫NETWORK-NAME: השם של רשת Compute Engine
    • ‫SUBNETWORK-NAME: השם של רשת המשנה ב-Compute Engine

שימוש בתגים כדי לאבטח את הרשת של worker VM

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

‫Dataflow תומך בשני סוגים של תגים לרשתות של מכונות וירטואליות:

שימוש בתגי אבטחה ב-Dataflow

תגים מאובטחים, שנקראים גם תגים שמנוהלים על ידי ניהול זהויות והרשאות גישה (IAM), הם צמדי מפתח/ערך שיוצרים ומנהלים ב-מנהל המשאבים. בניגוד לתגי רשת, תגים מאובטחים תומכים בבקרת גישה באמצעות IAM.

היתרונות של שימוש בתגים מאובטחים במקום בתגים של הרשת כוללים את היתרונות הבאים:

  • תגים מאובטחים מונעים שינוי לא מורשה של תגים ושינויים לא רצויים בכללי חומת האש.

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

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

  • באמצעות תגים מאובטחים, כללי חומת אש של תעבורת נכנס יכולים לכלול מקורות ברשתות VPC שמחוברות באמצעות קישור בין רשתות שכנות (peering) של VPC. במקרה של משימות Dataflow, כלל חומת אש יכול לכלול מקורות גם ברשת של מכונות ה-worker VM וגם ברשתות VPC שמקושרות לרשתות שכנות.

מידע נוסף על ההבדלים בין תגים מאובטחים לתגים של רשתות זמין במאמר השוואה בין תגים לתגים של רשתות.

כדי להחיל תגים מאובטחים על משימת Dataflow, פועלים לפי השלבים הבאים:

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

  2. מקצים את התפקיד Tag User (roles/resourcemanager.tagUser) לחשבון השירות של Dataflow במשאב (ערכי התגים). מידע נוסף על ההרשאות הנדרשות זמין במאמר בנושא ניהול תגים במשאבים.

  3. כשיוצרים את עבודת Dataflow, משתמשים בuse_vm_tags אפשרות השירות בפורמט הבא:

Java

--dataflowServiceOptions=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

Python

--dataflow_service_options=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

המשך

--dataflow_service_options=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

gcloud

משתמשים בפקודה gcloud dataflow jobs run עם האפשרות additional-experiments. אם משתמשים בתבניות Flex, משתמשים בפקודה gcloud dataflow flex-template run.

--additional-experiments=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

שימוש בתגי רשת ב-Dataflow

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

כדי להחיל תגי רשת על עבודת Dataflow, משתמשים בuse_network_tags experiment, באופן הבא:

Java

--dataflowServiceOptions=use_network_tags=TAG_NAME

Python

--dataflow_service_options=use_network_tags=TAG_NAME

המשך

--dataflow_service_options=use_network_tags=TAG_NAME

gcloud

משתמשים בפקודה gcloud dataflow jobs run עם האפשרות additional-experiments. אם משתמשים בתבניות Flex, משתמשים בפקודה gcloud dataflow flex-template run.

--additional-experiments=use_network_tags=TAG_NAME

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

מחליפים את TAG_NAME בשמות התגים. אם מוסיפים יותר מתג אחד, צריך להפריד בין התגים באמצעות נקודה ופסיק (;), כמו בדוגמה הבאה: TAG_NAME_1;TAG_NAME_2;TAG_NAME_3;....

אחרי שהעבודה מתחילה, אי אפשר להוסיף לה עוד תגי רשת.

‫Dataflow תמיד מוסיף את תג הרשת שמוגדר כברירת מחדל, dataflow, לכל מכונת VM של Worker שהוא יוצר.

כאן מפורטות המגבלות שחלות על תגי רשת.

כללי חומת אש ל-Dataflow

כללי חומת אש מאפשרים תעבורה או מונעים אותה מהמכונות הווירטואליות ואליהן. אם עבודות Dataflow שלכם משתמשות ב-ארגון נתונים של Dataflow או ב-Streaming Engine, אז אתם רק צריכים לוודא שכללי חומת האש מאפשרים גישה לממשקי API של Google Cloud . אחרת, צריך להגדיר כללים נוספים של חומת אש כדי שמכונות וירטואליות של Dataflow יוכלו לשלוח ולקבל תעבורת נתונים ברשת ביציאת TCP‏ 12345 לעבודות סטרימינג וביציאת TCP‏ 12346 לעבודות אצווה. בעלי הפרויקט, עורכים או מנהלי אבטחה צריכים ליצור את כללי חומת האש הנדרשים ברשת ה-VPC שבה נעשה שימוש במכונות הווירטואליות של Dataflow.

לפני שמגדירים כללים לחומת אש עבור Dataflow, כדאי לקרוא את המסמכים הבאים:

כשיוצרים כללים של חומת אש ל-Dataflow, צריך לציין את תגי הרשת של Dataflow. אחרת, כללי חומת האש חלים על כל המכונות הווירטואליות ברשת ה-VPC.

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

אם לא יוצרים תגי רשת מותאמים אישית כשמריצים את קוד צינור עיבוד הנתונים, מכונות ה-VM של Dataflow משתמשות בתג ברירת המחדל dataflow. אם אין תגי רשת בהתאמה אישית, צריך ליצור את כללי חומת האש עם התג dataflow שמוגדר כברירת מחדל.

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

חלק מרשתות ה-VPC, כמו הרשת default שנוצרת באופן אוטומטי, כוללות כלל default-allow-internal שעומד בדרישה של חומת האש ל-Dataflow.

דוגמה לכלל חומת אש לתעבורת נתונים נכנסת

כלל חומת האש של התעבורה הנכנסת מאפשר למכונות וירטואליות של Dataflow לקבל חבילות זו מזו. תמיד צריך ליצור כללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress), אחרת תעבורת הנתונים תמיד תיחסם, גם אם כללי תעבורת הנתונים היוצאת (egress) מאפשרים אותה.

בדוגמה הבאה, נוצר כלל של חומת אש לתעבורה נכנסת עבור Dataflow, שבו לכל מכונות ה-VM של העובדים יש את תג הרשת dataflow שמוגדר כברירת מחדל. בעלי פרויקט, עורכים או אדמינים של אבטחה יכולים להשתמש בפקודה gcloud הבאה כדי ליצור כלל הרשאת כניסה שמאפשר תנועה ביציאות TCP‏ 12345 ו-12346 ממכונות וירטואליות עם תג הרשת dataflow למכונות וירטואליות אחרות עם אותו תג:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_INGRESS \
    --action=allow \
    --direction=ingress \
    --network=NETWORK  \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --priority=PRIORITY_NUM \
    --rules tcp:12345-12346

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

  • ‫FIREWALL_RULE_NAME_INGRESS: שם לכלל חומת האש

  • ‫NETWORK: השם של הרשת שבה מכונות ה-VM של העובדים משתמשות

  • ‫CUSTOM_TAG: רשימה מופרדת בפסיקים של תגי רשת

    הנה רשימת הנחיות לשימוש בתגי רשת:

    • אם לא מציינים את --target-tags, הכלל חל על כל המכונות הווירטואליות ברשת ה-VPC.

    • אם לא מציינים את --source-tags ואת כל שאר המקורות, התנועה מכל מקור מותרת.

    • אם לא ציינתם תגי רשת מותאמים אישית ואתם רוצים שהכלל יהיה ספציפי למכונות וירטואליות של Dataflow, צריך להשתמש ב-dataflow כתג הרשת.

    • אם ציינתם תגי רשת בהתאמה אישית ואתם רוצים שהכלל יהיה ספציפי למכונות וירטואליות של Dataflow, אתם צריכים להשתמש בתגי הרשת המותאמים אישית.

  • ‫PRIORITY_NUM: העדיפות של כלל חומת האש

    מספרים נמוכים יותר מייצגים עדיפות גבוהה יותר, והעדיפות הגבוהה ביותר היא 0.

דוגמה לכלל יציאה של חומת אש

כלל חומת האש לתעבורת נתונים יוצאת מאפשר למכונות וירטואליות של Dataflow לשלוח חבילות נתונים זו לזו. אם יצרתם כללים של חומת אש שחוסמים תעבורת נתונים יוצאת, יכול להיות שתצטרכו ליצור כללים מותאמים אישית של חומת אש שמאפשרים תעבורת נתונים יוצאת ברשת ה-VPC.

בדוגמה הזו, נוצר כלל יציאה של חומת אש עבור Dataflow, שבו לכל מכונות העובד הווירטואליות יש תג רשת ברירת מחדל של dataflow. בעלי פרויקט, עורכים או אדמינים של אבטחה יכולים להשתמש בפקודה gcloud הבאה כדי ליצור כלל לאישור תעבורת נתונים יוצאת שמאפשר תעבורת נתונים מיציאות TCP‏ 12345 ו-12346 במכונות וירטואליות עם תג הרשת dataflow למכונות וירטואליות אחרות עם אותו תג:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_EGRESS \
    --network=NETWORK \
    --action=allow \
    --direction=egress \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --destination-ranges=DESTINATION-RANGES\
    --priority=PRIORITY_NUM  \
    --rules tcp:12345-12346

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

  • ‫FIREWALL_RULE_NAME_EGRESS: שם לכלל חומת האש

  • ‫NETWORK: השם של הרשת שבה מכונות ה-VM של העובדים משתמשות

  • ‫CUSTOM_TAG: רשימה מופרדת בפסיקים של תגי רשת

    הנה רשימת הנחיות לשימוש בתגי רשת:

    • אם לא מציינים את --target-tags, הכלל חל על כל המכונות הווירטואליות ברשת ה-VPC.

    • אם לא מציינים את --source-tags ואת כל שאר המקורות, התנועה מכל מקור מותרת.

    • אם לא ציינתם תגי רשת מותאמים אישית ואתם רוצים שהכלל יהיה ספציפי למכונות וירטואליות של Dataflow, צריך להשתמש ב-dataflow כתג הרשת.

    • אם ציינתם תגי רשת בהתאמה אישית ואתם רוצים שהכלל יהיה ספציפי למכונות וירטואליות של Dataflow, אתם צריכים להשתמש בתגי הרשת המותאמים אישית.

  • ‫DESTINATION-RANGES: רשימה מופרדת בפסיקים של CIDR

    הכללת טווח כתובות ה-IP הראשי של רשת המשנה שנבחרה.

  • ‫PRIORITY_NUM: העדיפות של כלל חומת האש

    מספרים נמוכים יותר מייצגים עדיפות גבוהה יותר, והעדיפות הגבוהה ביותר היא 0.

כדי לראות אילו יציאות TCP ספציפיות משמשות את Dataflow, אפשר לצפות במניפסט של קונטיינר הפרויקט. קובץ המניפסט של המאגר מציין במפורש את היציאות כדי למפות יציאות של המארח לתוך המאגר.

גישת SSH למכונות וירטואליות של Worker

לא צריך SSH ב-Dataflow, אבל הוא שימושי לפתרון בעיות.

אם למכונה הווירטואלית של העובד יש כתובת IP חיצונית, אפשר להתחבר למכונה הווירטואלית דרך מסוף Google Cloud או באמצעות Google Cloud CLI. כדי להתחבר באמצעות SSH, צריך כלל חומת אש שמאפשר חיבורים נכנסים ביציאת TCP 22 לפחות מכתובת ה-IP של המערכת שבה מריצים את gcloud או של המערכת שבה מריצים את דפדפן האינטרנט שמשמש לגישה למסוףGoogle Cloud .

כדי לראות את הגדרות הרשת והפעילות, צריך לפתוח סשן SSH באחד מהעובדים ולהריץ את הפקודה iproute2. מידע נוסף זמין בדף בנושא iproute2 בוויקי של Linux Foundation.

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

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