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

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

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

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

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

מכונות וירטואליות (VM) של עובדי Dataflow צריכות להגיע לשירותים ולממשקי API שלGoogle Cloud . יכול להיות שקבוצת נקודות הקצה התלויות של 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 דרך דומיין מסוים, הסביבה שלכם צריכה לעמוד בדרישות הבאות:

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

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

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

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

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

בהתאם לתרחיש לדוגמה, יכול להיות שהמכונות הווירטואליות יצטרכו גם גישה למשאבים מחוץ ל-Google Cloud Platform. כדי להגדיר גישה לאינטרנט ל-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

Go

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

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

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

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

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

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

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

שימוש בתגים מאובטחים עם Dataflow

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

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

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

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

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

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

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

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

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

  2. מקצים את התפקיד משתמש בתגים (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

Go

--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

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

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

Java

--dataflowServiceOptions=use_network_tags=TAG_NAME

Python

--dataflow_service_options=use_network_tags=TAG_NAME

Go

--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 כדי לבצע שינויים במדיניות.

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

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

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

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

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

בדוגמה הבאה, נוצר כלל של חומת אש לתעבורת נתונים נכנסת (ingress) עבור Dataflow, שבו לכל worker 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, אבל הוא שימושי לפתרון בעיות.

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

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

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

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