אבטחה והרשאות ב-Dataflow

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

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

לפני שמתחילים

Google Cloud בסקירה הכללית של Google Cloud אפשר לקרוא על מזהי פרויקטים. המזהים האלה כוללים את שם הפרויקט, מזהה הפרויקט ומספר הפרויקט.

שדרוג ותיקון של מכונות וירטואליות ב-Dataflow

ב-Dataflow משתמשים במערכת הפעלה שמותאמת לקונטיינרים. תהליכי האבטחה של מערכת הפעלה שמותאמת לקונטיינרים חלים גם על Dataflow. במאמר אבטחה והקשחה של מכונות וירטואליות של Worker מוסבר איך Google מאבטחת ומקשיחה את המכונות הווירטואליות האלה.

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

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

תמונות קונטיינר של Dataflow זמינות במסוףGoogle Cloud .

אבטחת קובצי אימג' של קונטיינרים

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

‫Google מקשיחה ומתקנת את מערכת ההפעלה של קובצי האימג' הבסיסיים שמשמשים את קובצי האימג' שבבעלות Dataflow. ‫Google מפרסמת במהירות תיקונים לתמונות האלה. כל משאבי הייצור של Dataflow, כולל קובצי האימג' של Beam שסופקו כברירת מחדל, נסרקים באופן אוטומטי וקבוע לאיתור נקודות חולשה. כל הבעיות שזוהו בקונטיינרים שבבעלות Google מטופלות במסגרת יעד מוגדר למדידת רמת השירות (SLO). הקהילה של Beam מטפלת בבעיות במאגרי Beam. כחלק ממודל האחריות המשותפת של Dataflow, כדי לנהל בעיות אבטחה בצורה יעילה, מומלץ להשתמש בקובצי אימג' של קונטיינרים בהתאמה אישית.

למרות שקובצי האימג' של מערכת ההפעלה שמותאמות לקונטיינרים שבהן Dataflow משתמש תואמות ל-CIS ברמה 1, השגת תאימות כוללת היא אחריות משותפת. המכונות הווירטואליות שעליהן פועלים הקונטיינרים האלה נמצאות בפרויקט של הלקוח. הלקוחות אחראים לסרוק את משאבי הפרויקט שלהם. אתם יכולים להשתמש ב-Security Command Center כדי לסרוק את המשאבים שלכם ולבדוק אם הם עומדים בדרישות התאימות ואם יש בהם נקודות חולשה.

סביבת זמן ריצה

בסביבת זמן הריצה של קוד המשתמש בצינור עיבוד הנתונים, Dataflow משתמש בקובץ אימג' של Apache Beam שנוצר מראש, או בקונטיינר בהתאמה אישית אם סופק כזה.

המשתמש להרצת הקונטיינר נבחר על ידי שירות Dataflow. ב-Dataflow אי אפשר להריץ קובצי אימג' של קונטיינר SDK בהתאמה אישית או קובצי אימג' של קונטיינר תבנית בהתאמה אישית לתבניות Flex כמשתמש שאינו משתמש Root.

בניגוד לסביבות אחרות (כמו Google Kubernetes Engine (GKE)) שבהן קונטיינרים פועלים בצמתים משותפים, מכונות וירטואליות של Dataflow worker לא משותפות בין צינורות עיבוד נתונים. המשאבים של צינור עיבוד הנתונים מוקצים לכל משימה בנפרד. אין שיתוף של מכונות וירטואליות ומשאבים אחרים בין צינורות עיבוד נתונים.

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

אבטחה והרשאות לצינורות עיבוד נתונים מקומיים

כשמריצים באופן מקומי, צינור עיבוד הנתונים של Apache Beam פועל בתורGoogle Cloud החשבון שהגדרתם באמצעות קובץ ההפעלה של Google Cloud CLI. לפעולות של Apache Beam SDK שמופעלות באופן מקומי ולחשבון Google Cloudיש גישה לאותם קבצים ומשאבים.

כדי להציג את החשבון שבחרתם כברירת מחדל, מריצים את הפקודה gcloud config list. Google Cloud

צינורות עיבוד נתונים מקומיים יכולים להפיק נתונים ליעדים מקומיים, כמו קבצים מקומיים, או ליעדים בענן, כמו Cloud Storage או BigQuery. אם צינור עיבוד הנתונים שמופעל באופן מקומי כותב קבצים למשאבים מבוססי-ענן כמו Cloud Storage, הוא משתמש בפרטי הכניסה לחשבון Google Cloud ובפרויקט Google Cloud שהגדרתם כברירת המחדל של Google Cloud CLI. כדי לדעת איך לבצע אימות באמצעות פרטי הכניסה לחשבון Google Cloud , קראו את המדריך לשפה שבה אתם משתמשים: Java,‏ Python או Go.

אבטחה והרשאות לצינורות עיבוד נתונים ב- Google Cloud

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

  • חשבון השירות של Dataflow שירות Dataflow משתמש בחשבון השירות של Dataflow כחלק מהבקשה ליצירת משימה, למשל כדי לבדוק את מכסת הפרויקט וליצור worker instances בשמכם. בנוסף, Dataflow משתמש בחשבון השירות של Dataflow במהלך הרצת המשימה כדי לנהל אותה. החשבון הזה נקרא גם סוכן השירות של Dataflow.

  • חשבון השירות של ה-worker VM. מכונות ה-worker משתמשות בחשבון השירות של ה-worker VM כדי לגשת למשאבי הקלט והפלט אחרי ששולחים את המשימה. כברירת מחדל, ה-workers משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine ומשויך לפרויקט שלכם כחשבון השירות של ה-worker. כשיטה מומלצת, אנחנו ממליצים לציין חשבון שירות בניהול המשתמש במקום להשתמש בחשבון השירות של ה-worker VM שמוגדר כברירת מחדל.

כדי להתחזות לחשבון השירות כשמריצים צינור עיבוד נתונים, לחשבון שמפעיל את צינור עיבוד הנתונים צריכה להיות ההרשאה iam.serviceAccounts.actAs. ההרשאה הזו כלולה בתפקיד "משתמש בחשבון שירות" (roles/iam.serviceAccountUser). התחזות לחשבון שירות מאפשרת לכם לאמץ באופן זמני את הזהות וההרשאות שלו כדי לבצע משימות שדורשות רמות גישה שונות, תוך הימנעות מהסיכונים שקשורים למפתחות קבועים. איך מתחזים לחשבון שירות?

בהתאם להרשאות אחרות בפרויקט, יכול להיות שחשבון המשתמש שלכם יצטרך גם את התפקיד roles/dataflow.developer. אם אתם Project Owner או עורכים שלו, כבר יש לכם את ההרשאות שכלולות בתפקיד roles/dataflow.developer.

שיטות מומלצות

  • כשאפשר, ציינו חשבון שירות בניהול המשתמש בתור חשבון השירות של ה-worker VM, במקום להשתמש בחשבון השירות של ה-worker VM שמוגדר כברירת מחדל.
  • כשנותנים הרשאות למשאבים, צריך להקצות את התפקיד שמכיל את ההרשאות המינימליות שנדרשות למשימה. אתם יכולים ליצור תפקיד בהתאמה אישית שכולל רק את ההרשאות הנדרשות.
  • כשמקצים תפקידים לגישה למשאבים, כדאי להשתמש ברמת המשאב הנמוכה ביותר האפשרית. לדוגמה, במקום להקצות את התפקיד roles/bigquery.dataEditor בפרויקט או בתיקייה, מקצים את התפקיד בטבלה ב-BigQuery.
  • יוצרים קטגוריה בבעלות הפרויקט, שתשמש כקטגוריית ה-staging של Dataflow. הרשאות ברירת המחדל של הקטגוריה מאפשרות ל-Dataflow להשתמש בקטגוריה כדי להעביר את קובצי ההפעלה של צינור עיבוד הנתונים.

חשבון שירות של Dataflow

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

service-PROJECT_NUMBER@dataflow-service-producer-prod.

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

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

לחשבון הזה מוקצה התפקיד "סוכן שירות של Dataflow" בפרויקט. יש לו את ההרשאות הנדרשות כדי להריץ משימת Dataflow בפרויקט, כולל הפעלת ה-workers של Compute Engine. החשבון הזה משמש רק את Dataflow והוא ספציפי לפרויקט שלכם.

אתם יכולים לבדוק את התפקידים שהוקצו לחשבון השירות של Dataflow במסוףGoogle Cloud או ב-Google Cloud CLI.

המסוף

  1. נכנסים לדף Roles.

    לדף Roles

  2. אם רלוונטי, בוחרים את הפרויקט.

  3. ברשימה, לוחצים על הכותרת Cloud Dataflow Service Agent. ייפתח דף עם רשימת ההרשאות שהוקצו לחשבון השירות של Dataflow.

‫CLI של gcloud

בודקים את ההרשאות של חשבון השירות של Dataflow:

gcloud iam roles describe roles/dataflow.serviceAgent

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

אם תסירו את ההרשאות של חשבון השירות ממדיניות ניהול הזהויות והרשאות הגישה (IAM), החשבון יישאר כי הוא בבעלות של שירות Dataflow.

חשבון שירות של worker VM

מכונות של Compute Engine מריצות פעולות של Apache Beam SDK בענן. ה-workers האלה משתמשים בחשבון השירות של ה-worker VM בפרויקט כדי לגשת לקבצים ולמשאבים אחרים שמשויכים לצינור עיבוד הנתונים. חשבון השירות של ה-worker VM משמש כזהות של כל ה-worker VMs, וכל הבקשות שמגיעות מה-VM משתמשות בחשבון השירות של ה-worker VM. חשבון השירות הזה משמש גם לאינטראקציה עם משאבים כמו קטגוריות של Cloud Storage ונושאי Pub/Sub.

  • כדי שחשבון השירות של ה-worker VM יוכל להריץ משימה, צריך להיות לו התפקיד roles/dataflow.worker.
  • כדי שחשבון השירות של ה-worker VM יוכל ליצור או לבדוק משימה, צריך להיות לו התפקיד roles/dataflow.admin.

בנוסף, כשצינורות עיבוד הנתונים של Apache Beam ניגשים למשאבים של Google Cloud , צריך להקצות את התפקידים הנדרשים לחשבון השירות של ה-worker VM בפרויקט ב-Dataflow. חשבון השירות של ה-worker VM צריך להיות מסוגל לגשת למשאבים בזמן הפעלת המשימה ב-Dataflow. לדוגמה, אם המשימה כותבת ל-BigQuery, לחשבון השירות צריך להיות לפחות התפקיד roles/bigquery.dataEditor בטבלה ב-BigQuery. דוגמאות למשאבים:

חשבון השירות של worker VM שמוגדר כברירת מחדל

כברירת מחדל, ה-workers משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine של הפרויקט בתור חשבון השירות של ה-worker. כתובת האימייל של חשבון השירות הזה היא:

PROJECT_NUMBER-compute@

חשבון השירות הזה נוצר באופן אוטומטי כשמפעילים את Compute Engine API בפרויקט מתוך ספריית ה-API במסוף Google Cloud .

אפשר להשתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כחשבון השירות של ה-worker VM ב-Dataflow, אבל מומלץ ליצור חשבון שירות ייעודי ל-worker VM ב-Dataflow, עם התפקידים וההרשאות שאתם צריכים בלבד.

בהתאם להגדרות של מדיניות הארגון, יכול להיות שחשבון השירות שמוגדר כברירת מחדל יקבל באופן אוטומטי את התפקיד "עריכה" בפרויקט. אנחנו ממליצים מאוד להשבית את הענקת התפקיד האוטומטית על ידי אכיפת האילוץ iam.automaticIamGrantsForDefaultServiceAccounts במדיניות הארגון. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.

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

אם לחשבון השירות שמוגדר כברירת מחדל כבר יש את התפקיד "עריכה", מומלץ להחליף את התפקיד הזה בתפקידים עם פחות הרשאות.

ציון חשבון שירות של worker VM שמנוהל על ידי המשתמשים

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

  1. אם אין לכם חשבון שירות שמנוהל על ידי משתמש, צרו חשבון שירות.

  2. מגדירים את תפקידי ה-IAM הנדרשים לחשבון השירות.

    • כדי שחשבון השירות של ה-worker VM יוכל להריץ משימה, צריך להיות לו התפקיד roles/dataflow.worker.
    • כדי שחשבון השירות של ה-worker VM יוכל ליצור או לבדוק משימה, צריך להיות לו התפקיד roles/dataflow.admin.
    • לחלופין, אפשר ליצור תפקיד IAM בהתאמה אישית עם ההרשאות הנדרשות. רשימת ההרשאות הנדרשות מופיעה במאמר תפקידים.

  3. יכול להיות שתצטרכו להקצות לחשבון השירות תפקידים נוספים כדי להשתמש במשאבי Google Cloudשנדרשים למשימה, כמו BigQuery,‏ Pub/Sub או Cloud Storage. לדוגמה, אם המשימה קוראת מ-BigQuery, לחשבון השירות צריך להיות גם לפחות התפקיד roles/bigquery.dataViewer בטבלה ב-BigQuery.

  4. חשוב לוודא שלחשבון השירות בניהול המשתמשים יש גישת קריאה וכתיבה למיקומים הזמניים ולמיקומי ה-staging שצוינו במשימת Dataflow.

  5. כדי להפעיל את צינור עיבוד הנתונים, לחשבון המשתמש צריכה להיות ההרשאה iam.serviceAccounts.actAs להתחזות לחשבון השירות של ה-worker VM.

  6. בפרויקט שמכיל את חשבון השירות של ה-worker VM שמנוהל על ידי המשתמש, לחשבון השירות של Dataflow (service-PROJECT_NUMBER@dataflow-service-producer-prod.) ולסוכן השירות של Compute Engine (service-PROJECT_NUMBER@compute-system.) צריכים להיות התפקידים הבאים. ‫PROJECT_NUMBER הוא מזהה הפרויקט שבו פועלת המשימה ב-Dataflow. שני החשבונות האלה הם סוכני שירות.

    נניח שמשימת Dataflow פועלת בפרויקט א' וחשבון השירות של ה-worker VM מתארח בפרויקט ב'. ודאו שלסוכני השירות מפרויקט א' יש את התפקידים iam.serviceAccountTokenCreator ו-iam.serviceAccountUser בפרויקט ב'. בפרויקט שבו פועלת משימת Dataflow, לחשבונות יש את התפקידים האלה כברירת מחדל. כדי להקצות את התפקידים האלה, פועלים לפי השלבים שמפורטים בקטע הקצאת תפקיד יחיד בדף "ניהול הגישה לחשבונות שירות".

  7. כשחשבון השירות של ה-worker VM בניהול המשתמש והמשימה נמצאים בפרויקטים שונים, צריך לוודא שהאילוץ הבוליאני iam.disableCrossProjectServiceAccountUsage לא נאכף בפרויקט שבבעלותו חשבון השירות בניהול המשתמש. איך מאפשרים צירוף של חשבונות שירות בין פרויקטים

  8. כשמריצים את משימת צינור עיבוד הנתונים, מציינים את חשבון השירות.

    Java

    משתמשים באפשרות --serviceAccount ומציינים את חשבון השירות כשמריצים את משימת צינור עיבוד הנתונים משורת הפקודה: --serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    משתמשים באפשרות --service-account-email ומציינים את חשבון השירות כשמריצים את משימת צינור עיבוד הנתונים כתבנית Flex: --service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    Python

    משתמשים באפשרות --service_account_email ומציינים את חשבון השירות כשמריצים את משימת צינור עיבוד הנתונים: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    המשך

    משתמשים באפשרות --service_account_email ומציינים את חשבון השירות כשמריצים את משימת צינור עיבוד הנתונים: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.

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

הצגת חשבון השירות של ה-worker VM של משימה

במשימה קיימת, כתובת האימייל של חשבון השירות של ה-worker VM מאוחסנת בשדה environment.serviceAccountEmail (environment.service_account_email ב-RPC ובספריות הלקוח) של המשאב Job.

כדי לאחזר את האובייקט environment ואת serviceAccountEmail, צריך לבקש את תצוגת המשרה JOB_VIEW_DESCRIPTION או JOB_VIEW_ALL כשמקבלים משרה. בקשות שמשתמשות ב-JOB_VIEW_SUMMARY, כולל projects.locations.jobs.list ושאילתות סיכום שמוגדרות כברירת מחדל, משמיטות את environment.serviceAccountEmail.

קריאות ל-API לקריאה בלבד כדי לבדוק מטא-נתונים של משימות, כמו projects.locations.jobs.get, לא כרוכות בחיובים לכל בקשה. הקריאות ל-API כפופות למכסות רגילות של מעקב ו-API, והחיובים של Dataflow חלים על משאבי המחשוב, האחסון ועיבוד הנתונים של צינור עיבוד הנתונים. למידע נוסף, ראו תמחור.

המסוף

  1. במסוף Google Cloud , נכנסים לדף Dataflow > Jobs.

    כניסה לדף Jobs

  2. לוחצים על שם המשימה שרוצים לבדוק.

  3. בדף Job details, בחלונית הצדדית Job info, לוחצים על REST ליד Equivalent בתחתית החלונית.

  4. בתיבת הדו-שיח Equivalent REST response, מאתרים את השדה serviceAccountEmail באובייקט environment.

    אם ציינתם חשבון שירות בניהול המשתמשים כשהפעלתם את המשימה, כתובת האימייל של חשבון השירות מופיעה גם בשדה service_account_email בקטע Pipeline options שבחלונית Job info.

‫CLI של gcloud

כדי לאחזר את כתובת האימייל של חשבון השירות של ה-worker VM של משימה, מריצים את הפקודה gcloud dataflow jobs describe עם הדגל --full:

gcloud dataflow jobs describe JOB_ID \
    --region=REGION \
    --project=PROJECT_ID \
    --full \
    --format="value(environment.serviceAccountEmail)"

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

  • ‫JOB_ID: המזהה של משימת Dataflow
  • ‫REGION: האזור שבו המשימה פועלת, למשל us-central1
  • ‫PROJECT_ID: מזהה הפרויקט שמכיל את המשימה

REST

כדי לאחזר את המטא-נתונים של סביבת ההפעלה של משימה ואת כתובת האימייל של חשבון השירות של ה-worker, שולחים בקשת GET ל-method‏ projects.locations.jobs.get ומגדירים את הפרמטר view של השאילתה ל-JOB_VIEW_DESCRIPTION או ל-JOB_VIEW_ALL:

curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?view=JOB_VIEW_DESCRIPTION"

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

  • ‫PROJECT_ID: מזהה הפרויקט שמכיל את המשימה
  • ‫REGION: האזור שבו המשימה פועלת, למשל us-central1
  • ‫JOB_ID: המזהה של משימת Dataflow

התשובה היא משאב Job שכולל את כתובת האימייל של חשבון השירות של ה-worker VM בשדה environment.serviceAccountEmail:

{
  "id": "JOB_ID",
  "projectId": "PROJECT_ID",
  "name": "JOB_NAME",
  "environment": {
    "serviceAccountEmail": "SERVICE_ACCOUNT_EMAIL"
  }
}

Python

משתמשים בספריית הלקוח של Dataflow ל-Python כדי להפעיל את get_job עם JobView.JOB_VIEW_DESCRIPTION ולקרוא את job.environment.service_account_email:

from google.cloud import dataflow_v1beta3

client = dataflow_v1beta3.JobsV1Beta3Client()
request = dataflow_v1beta3.GetJobRequest(
    project_id="PROJECT_ID",
    location="REGION",
    job_id="JOB_ID",
    view=dataflow_v1beta3.JobView.JOB_VIEW_DESCRIPTION,
)
job = client.get_job(request=request)
print(job.environment.service_account_email)

כדי לבדוק את כל המשימות באזור מסוים, מפעילים את list_jobs כדי להציג את מזהי המשימות, ואז מפעילים את get_job עם JobView.JOB_VIEW_DESCRIPTION לכל משימה.

Java

משתמשים בספריית הלקוח של Dataflow ל-Java כדי להפעיל את getJob עם JobView.JOB_VIEW_DESCRIPTION ולקרוא את job.getEnvironment().getServiceAccountEmail():

import com.google.dataflow.v1beta3.GetJobRequest;
import com.google.dataflow.v1beta3.Job;
import com.google.dataflow.v1beta3.JobView;
import com.google.dataflow.v1beta3.JobsV1Beta3Client;

try (JobsV1Beta3Client jobsClient = JobsV1Beta3Client.create()) {
  GetJobRequest request =
      GetJobRequest.newBuilder()
          .setProjectId("PROJECT_ID")
          .setLocation("REGION")
          .setJobId("JOB_ID")
          .setView(JobView.JOB_VIEW_DESCRIPTION)
          .build();
  Job job = jobsClient.getJob(request);
  System.out.println(job.getEnvironment().getServiceAccountEmail());
}

המשך

משתמשים בספריית הלקוח של Dataflow ל-Go כדי להפעיל את GetJob עם JobView_JOB_VIEW_DESCRIPTION ולקרוא את job.GetEnvironment().GetServiceAccountEmail():

import (
        "context"

        dataflow "cloud.google.com/go/dataflow/apiv1beta3"
        dataflowpb "cloud.google.com/go/dataflow/apiv1beta3/dataflowpb"
)

ctx := context.Background()
client, err := dataflow.NewJobsV1Beta3Client(ctx)
if err != nil {
        // Handle error.
}
defer client.Close()

req := &dataflowpb.GetJobRequest{
        ProjectId: "PROJECT_ID",
        Location:  "REGION",
        JobId:     "JOB_ID",
        View:      dataflowpb.JobView_JOB_VIEW_DESCRIPTION,
}
job, err := client.GetJob(ctx, req)
if err != nil {
        // Handle error.
}
serviceAccountEmail := job.GetEnvironment().GetServiceAccountEmail()
_ = serviceAccountEmail

דוגמאות מלאות לספריות לקוח בשפות נוספות מופיעות בדוגמאות הקוד של GetJob.

הוספת תפקידים

כדי להוסיף תפקידים בפרויקט:

המסוף

  1. נכנסים לדף IAM במסוף Google Cloud .

    כניסה לדף IAM

  2. בוחרים את הפרויקט הרצוי.

  3. בשורה שמכילה את חשבון המשתמש שלכם, לוחצים על Edit principal ואז על Add another role.

  4. ברשימה הנפתחת, בוחרים את התפקיד Service Account User.

  5. בשורה שמכילה את חשבון השירות של ה-worker VM, לוחצים על Edit principal ואז על Add another role.

  6. ברשימה הנפתחת, בוחרים בתפקיד Dataflow Worker.

  7. אם חשבון השירות של ה-worker VM צריך את התפקיד "אדמין ב-Dataflow", חוזרים על הפעולה בשביל אדמין ב-Dataflow.

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

    מידע נוסף על הקצאת תפקידים מופיע במאמר הקצאת תפקיד ב-IAM באמצעות המסוף.

‫CLI של gcloud

  1. מקצים לחשבון המשתמש את התפקיד roles/iam.serviceAccountUser. מריצים את הפקודה הבאה:

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUser
    • מחליפים את PROJECT_ID במזהה הפרויקט.
    • מחליפים את EMAIL_ADDRESS בכתובת האימייל של חשבון המשתמש.

  2. מקצים תפקידים לחשבון השירות של ה-worker VM. מריצים את הפקודה הבאה לתפקיד roles/dataflow.worker ב-IAM ולכל תפקיד שנדרש למשאבים שמשמשים במשימה. אם חשבון השירות של ה-worker VM צריך את התפקיד "אדמין ב-Dataflow", חוזרים על הפעולה עם תפקיד ה-IAM‏ roles/dataflow.admin. בדוגמה הזו משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, אבל מומלץ להשתמש בחשבון שירות בניהול המשתמש.

    gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:PROJECT_NUMBER-compute@" --role=SERVICE_ACCOUNT_ROLE
    • מחליפים את PROJECT_ID במזהה הפרויקט.
    • מחליפים את PROJECT_NUMBER במספר הפרויקט. כדי למצוא את מספר הפרויקט, אפשר לעיין במאמר זיהוי פרויקטים או להשתמש בפקודה gcloud projects describe.
    • מחליפים את SERVICE_ACCOUNT_ROLE בכל אחד מהתפקידים.

גישה למשאבים ב- Google Cloud

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

כדי לוודא שלצינור הנתונים של Apache Beam יש גישה למשאבים האלה, צריך להשתמש במנגנוני בקרת הגישה של המשאבים כדי לתת גישה באופן מפורש לחשבון השירות של ה-worker VM בפרויקט Dataflow.

אם אתם משתמשים בתכונות של Assured Workloads עם Dataflow, כמו אזורים באיחוד האירופי ותמיכה עם בקרות ריבונות, כל המשאבים של Cloud Storage, ‏BigQuery, ‏Pub/Sub, מחברי קלט/פלט ומשאבים אחרים שצינור עיבוד הנתונים ניגש אליהם צריכים להיות ממוקמים בפרויקט או בתיקייה של Assured Workloads בארגון.

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

גישה למאגרי Artifact Registry

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

כדי להשתמש ב-Artifact Registry עם Dataflow, צריך לתת לפחות גישת כתיבה ל-Artifact Registry (role/artifactregistry.writer) לחשבון השירות של ה-worker VM שמריץ את משימת Dataflow.

כל התוכן במאגר מוצפן באמצעות Google-owned and Google-managed encryption keys או מפתחות הצפנה בניהול הלקוח. כברירת מחדל, ב-Artifact Registry נעשה שימוש ב-Google-owned and Google-managed encryption keys , ולא נדרשת הגדרה לאפשרות הזו.

גישה לקטגוריות של Cloud Storage

כדי לתת לפרויקט ב-Dataflow גישה לקטגוריה של Cloud Storage, צריך לתת לחשבון השירות של ה-worker VM בפרויקט ב-Dataflow גישה לקטגוריה. לכל הפחות, לחשבון השירות צריכות להיות הרשאות קריאה וכתיבה גם לקטגוריה וגם לתוכן שלה. כדי לתת את הגישה הנדרשת, אתם יכולים להשתמש בהרשאות IAM ל-Cloud Storage.

כדי לתת לחשבון השירות של ה-worker VM את ההרשאות שנדרשות לקריאה ולכתיבה בקטגוריה, משתמשים בפקודה gcloud storage buckets add-iam-policy-binding. הפקודה הזו מוסיפה את חשבון השירות של פרויקט Dataflow למדיניות ברמת הקטגוריה.

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:PROJECT_NUMBER-compute@" --role=SERVICE_ACCOUNT_ROLE

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

  • ‫BUCKET_NAME: השם של הקטגוריה של Cloud Storage
  • ‫PROJECT_NUMBER: מספר הפרויקט ב-Dataflow. כדי למצוא את מספר הפרויקט, אפשר לעיין במאמר זיהוי פרויקטים או להשתמש בפקודה gcloud projects describe.
  • ‫SERVICE_ACCOUNT_ROLE: תפקיד ה-IAM, לדוגמה storage.objectViewer

כדי לאחזר רשימה של הקטגוריות של Cloud Storage בפרויקטGoogle Cloud , משתמשים בפקודה gcloud storage buckets list:

gcloud storage buckets list --project= PROJECT_ID

מחליפים את PROJECT_ID במזהה הפרויקט.

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

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

אפשר גם להגדיר הרשאות לקטגוריה דרך מסוף Google Cloud . אפשר לקרוא מידע נוסף במאמר הגדרת הרשאות לקטגוריות.

ב-Cloud Storage יש שתי מערכות שבאמצעותן אפשר להעניק למשתמשים גישה לקטגוריות ולאובייקטים: IAM ורשימות של בקרת גישה (ACL). ברוב המקרים, IAM היא השיטה המומלצת לשליטה בגישה למשאבים.

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

  • אם אתם משתמשים ברשימות ACL כדי לשלוט בגישה, ודאו שההרשאות של חשבון השירות של ה-worker VM תואמות להגדרות ה-IAM. בגלל חוסר העקביות בין כללי המדיניות של IAM ושל ACL, יכול להיות שלא תהיה גישה לקטגוריה של Cloud Storage למשימות של Dataflow כשמעבירים את הקטגוריה של Cloud Storage מגישה מפורטת לגישה אחידה ברמת הקטגוריה. מידע נוסף זמין במאמר הנחיות לשגיאות נפוצות.

גישה למערכי נתונים ב-BigQuery

אתם יכולים להשתמש ב-API של BigQueryIO כדי לגשת למערכי נתונים ב-BigQuery, באותו פרויקט שבו אתם משתמשים ב-Dataflow או בפרויקט אחר. כדי שהמקור והכיור של BigQuery יפעלו כמו שצריך, לשני החשבונות הבאים צריכה להיות גישה לכל מערכי הנתונים של BigQuery שמשימת Dataflow קוראת מהם או כותבת אליהם:

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

מבין ההרשאות הנדרשות ב-BigQuery, נדרשת הרשאת ה-IAM‏ bigquery.datasets.get כדי שהצינור יוכל לגשת למערך נתונים ב-BigQuery. בדרך כלל, רוב התפקידים ב-IAM ב-BigQuery כוללים את ההרשאה bigquery.datasets.get, אבל התפקיד roles/bigquery.jobUser הוא יוצא דופן.

גישה לנושאים ולמינויים ב-Pub/Sub

כדי לגשת לנושא או למינוי ב-Pub/Sub, צריך להשתמש בתכונות של ניהול זהויות והרשאות גישה (IAM) ב-Pub/Sub כדי להגדיר הרשאות לחשבון השירות של ה-worker.

ההרשאות הרלוונטיות הן מהתפקידים הבאים ב-Pub/Sub:

  • כדי לצרוך נתונים, חובה להשתמש ב-roles/pubsub.subscriber.
  • כדי ליצור מינוי ל-Pub/Sub, צריך את התפקיד roles/pubsub.editor.
  • מומלץ להשתמש ב-roles/pubsub.viewer כדי ש-Dataflow יוכל לשלוח שאילתות לגבי ההגדרות של הנושאים והמינויים. להגדרה הזו יש שני יתרונות:
    • ‫Dataflow יכול לבדוק אם יש הגדרות לא נתמכות במינויים, שלא יפעלו כמו שצריך.
    • אם המינוי לא משתמש במועד האחרון לאישור שמוגדר כברירת מחדל (10 שניות), הביצועים משתפרים. ‫Dataflow מאריך שוב ושוב את המועד האחרון לאישור של הודעה בזמן שהיא מעובדת על ידי צינור עיבוד הנתונים. בלי ההרשאות של pubsub.viewer, ל-Dataflow אין אפשרות לשלוח שאילתה לגבי המועד האחרון לאישור, ולכן הוא צריך להניח שמועד ברירת המחדל הוא המועד האחרון. ההגדרה הזו גורמת ל-Dataflow לשלוח יותר בקשות modifyAckDeadline מהנדרש.
    • אם VPC Service Controls מופעל בפרויקט שבבעלותו המינוי או הנושא, כללי תעבורת נתונים נכנסת (ingress) שמבוססים על כתובת IP לא מאפשרים ל-Dataflow לשלוח שאילתות לגבי ההגדרות. במקרה כזה, צריך כלל תעבורת נתונים נכנסת שמבוסס על חשבון השירות של ה-worker VM.

למידע נוסף ולדוגמאות קוד שמראות איך להשתמש בתכונות של ניהול הזהויות והרשאות הגישה ב-Pub/Sub, קראו את המאמר תרחיש לדוגמה: תקשורת בין פרויקטים.

גישה ל-Firestore

כדי לגשת למסד נתונים של Firestore (במצב Native או במצב Datastore), צריך להוסיף את חשבון השירות של Dataflow worker VM (לדוגמה, PROJECT_NUMBER-compute@) כעורך של הפרויקט שבבעלותו מסד הנתונים, או להשתמש בתפקיד Datastore מגביל יותר כמו roles/datastore.viewer. בנוסף, צריך להפעיל את Firestore API בשני הפרויקטים מתוך API Library במסוף Google Cloud .

גישה לתמונות בפרויקטים עם מדיניות בנושא קובצי אימג' מהימנים

אם הגדרתם בפרויקט מדיניות בנושא קובצי אימג' מהימנים וקובץ האימג' לאתחול נמצא בפרויקט אחר, ודאו שהמדיניות בנושא קובצי אימג' מהימנים מוגדרת כך שתהיה לה גישה לקובץ האימג'. לדוגמה, אם אתם מריצים משימת Dataflow מתבנית, ודאו שקובץ המדיניות כולל גישה לפרויקט dataflow-service-producer-prod. הפרויקט Google Cloud מכיל את התמונות של משימות התבנית.

גישה לתבניות ש-Google מספקת באמצעות מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

אם בארגון שלכם משתמשים בכללי מדיניות של גבולות גישה לישויות מורשות (PAB), יכול להיות שמשתמשים או חשבונות שירות לא יוכלו לראות ולהריץ תבניות ש-Google מספקת. במקרה כזה, נסו את אחד מהפתרונות הבאים:

  • מעדכנים את המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) כדי לאפשר גישה לפרויקט שמנוהל על ידי Google ומארח את התבניות ש-Google מספקת. מוסיפים את הפרויקט dataflow-templates (או את מספר הפרויקט 473832897378) למדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) כמשאב מותר:

    //cloudresourcemanager.googleapis.com/projects/dataflow-templates

    במאמר עריכת כללי מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) מוסבר איך לעדכן את כללי המדיניות.

  • להחריג חשבונות משתמשים ספציפיים בקישור המדיניות. אם רק חשבונות משתמשים או חשבונות שירות ספציפיים צריכים להריץ תבניות ש-Google מספקת, אפשר להשתמש בביטויים מותנים בקישור של מדיניות ה-PAB כדי להחריג את חשבונות המשתמשים האלה מהמדיניות.

  • מריצים את התבנית מהפרויקט שלכם. משתמשים בקוד התבנית בקוד פתוח ממאגר DataflowTemplates ב-GitHub כדי ליצור את התבנית ולהעביר אותה לשלב ה-staging בפרויקט שלכם. דוגמה לכך מופיעה במאמר פיתוח והרצה של תבנית Flex לדוגמה.

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

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

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

  1. אבטחת רשת ותשתית
  2. ניהול זהויות והרשאות גישה (IAM)
  3. הגנה על נתונים והצפנה

‫Dataflow פועל על מכונות וירטואליות מנוהלות עם התאמה לעומס (autoscaling) (עובדים). לכן, הגדרה נכונה של הרכיבים האלה עוזרת להבטיח שהנתונים לא ייחשפו ויישארו מאובטחים במהלך העיבוד.

אבטחת רשתות ותשתיות

כברירת מחדל, ל-workers של Dataflow מוקצות כתובות IP ציבוריות כדי לגשת לאינטרנט ול-Google APIs. בסביבה מאובטחת, צריך להגביל את הגישה הזו.

  • השבתת כתובות IP ציבוריות: כדי להריץ את ה-workers של Dataflow בלי כתובות IP ציבוריות, מעבירים את הפרמטר --usePublicIps=false.
  • הגדרת גישה פרטית ל-Google: כשהכתובות ה-IP הציבוריות מושבתות, ה-workers עדיין צריכים לתקשר עם ממשקי ה-API של Google (כמו Cloud Storage, ‏BigQuery או Pub/Sub). מפעילים את גישה פרטית ל-Google ברשת המשנה של ה-VPC, כדי שה-workers יוכלו לנתב את התנועה לשירותי Google באופן פנימי.
  • שימוש ב-VPC משותפים וב-VPC Service Controls ‏ (VPC-SC):
    • להציב את צינורות עיבוד הנתונים של Dataflow בתוך מתחם אבטחה היקפית באמצעות VPC Service Controls. כך מצמצמים את הסיכון לזליגת נתונים, כי אי אפשר להעתיק נתונים למשאבים מחוץ להיקף, גם אם למשתמשים יש פרטי כניסה תקינים.
    • להשתמש ברשתות משנה ייעודיות עם כללי חומת אש מחמירים, שמאפשרים תנועה רק למשאבים נחוצים (כמו מסד הנתונים או אשכול Kafka) ולהשבית את SSH באופן מפורש.

IAM

העיקרון של הרשאות מינימליות הוא קריטי. כברירת מחדל, Dataflow מנסה להשתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שלרוב יש לו הרשאות עריכה נרחבות.

  • שימוש בחשבון שירות של worker VM בניהול המשתמש: יוצרים חשבון שירות ייעודי ללא הרשאות, במיוחד ל-worker VMs של Dataflow, ומעבירים אותו במהלך שליחת צינור עיבוד הנתונים. לדוגמה:

    --serviceAccount=YOUR_SERVICE_ACCOUNT@YOUR_PROJECT_ID.

    אחרי שיוצרים את חשבון השירות, מקצים לו רק תפקידים מינימליים:

    • לחשבון השירות של ה-worker VM צריך להיות התפקיד roles/dataflow.worker.
    • מעניקים גישה ספציפית לקריאה או לכתיבה רק למשאבים המדויקים שצינור עיבוד הנתונים נוגע בהם. לדוגמה, צריך לתת את התפקיד roles/storage.objectViewer בקטגוריה של Cloud Storage בקלט, ואת התפקיד roles/bigquery.dataEditor בטבלה ב-BigQuery הספציפית ביעד (במקום תפקידים ברמת הפרויקט).

  • הפרדה בין הרשאות של בקרים להרשאות של עובדים: המפתח או צינור עיבוד הנתונים של CI/CD ששולחים את המשימה צריכים את ההרשאות roles/dataflow.admin ו-roles/iam.serviceAccountUser (או ההרשאה iam.serviceAccounts.actAs) כדי להפעיל את צינור עיבוד הנתונים. עם זאת, למכונות הווירטואליות של ה-worker נדרשות רק הרשאות להרצה בזמן ריצה (roles/dataflow.worker).

הגנה על נתונים והצפנה

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

  • הטמעת מפתחות הצפנה בניהול הלקוח (CMEK): אתם יכולים להשתמש ב-Cloud Key Management Service כדי ליצור ולנהל מפתחות משלכם. מעבירים את המפתח ל-Dataflow באמצעות הדגל --dataflowKmsKey. ‫Dataflow משתמש במפתח הזה כדי להצפין:
    • דיסקים לאחסון מתמיד שמחוברים למכונות ה-worker VM.
    • נתוני מצב של Shuffle לצינורות עיבוד נתונים באצווה.
    • מצב מנוע הסטרימינג של פייפליינים זורמים.
  • אבטחת הסודות: אף פעם אל תכתבו בקוד קשיח סיסמאות, מפתחות API או פרטי כניסה למסד נתונים בקוד של Apache Beam או באפשרויות של צינור עיבוד הנתונים. אפשר לגשת אליהם באופן דינמי בשלבים Setup או StartBundle של צינור עיבוד הנתונים באמצעות Secret Manager.
  • פריסת תורים להודעות שלא נמסרו (DLQ): אל תתעדו ביומן רכיבים גולמיים שלא נותחו כשיש שגיאה, כי הם יכולים להכיל פרטים אישיים מזהים (PII) או סודות. במקום זאת, צריך לזהות חריגים בעיבוד ולנתב רכיבים שנכשלו לקטגוריה מוצפנת של Cloud Storage או לנושא Pub/Sub מסוג "הודעות שלא נמסרו" (dead-letter) כדי לבדוק אותם בצורה מבודדת ומאובטחת.

קוד צינור עיבוד נתונים ובדיקת נקודות חולשה

האבטחה חלה גם על שרשרת האספקה של התוכנה של קוד Apache Beam.

  • סריקת קובצי אימג' של קונטיינרים: אם אתם משתמשים בקובצי אימג' של קונטיינרים בהתאמה אישית ל-workers של Dataflow (באמצעות הדגל --sdkContainerImage), אחסנו אותם ב-Artifact Registry והפעילו בדיקת נקודות חולשה אוטומטית.
  • עדכון קבוע של קובצי האימג': בפייפליינים זורמים שפועלים באופן רציף, חשוב לעדכן את הפייפליין באופן קבוע כדי להשתמש בגרסאות העדכניות ביותר של Apache Beam SDK. ‫Google מקשיחה ומתקנת באופן קבוע את קובצי האימג' הבסיסיים של מערכת ההפעלה שמשמשים את Dataflow.

רשימת משימות מהירה לאבטחה

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

מטרה פרמטר או כלי אבטחה מטרה
בעלות על המפתחות --dataflowKmsKey הצפנה של מצב צינור עיבוד הנתונים ודיסקים של Worker באמצעות Cloud KMS.
גישה עם הרשאות מינימליות --serviceAccount מפעיל את ה-workers בזהות מוגבלת.
אין חשיפה לאינטרנט --usePublicIps=false מונע הקצאה של כתובות IP ציבוריות ל-workers.
מניעת זליגת נתונים VPC Service Controls (VPC-SC) מגבילה את תנועת הנתונים מחוץ לגבולות האמון.
גישה מאובטחת ל-API גישה פרטית ל-Google מאפשר לעובדים לגשת ל-Cloud Storage ול-BigQuery באופן פרטי.
פרטי כניסה מאובטחים Secret Manager שליפה דינמית של סיסמאות ומפתחות בזמן הריצה.
אבטחת קטגוריות של Cloud Storage הרשאות מינימליות להגביל את ההרשאות בקטגוריות של Cloud Storage שמשמשות את Dataflow.

גישה לנתונים ואבטחה

שירות Dataflow עובד עם שני סוגים של נתונים:

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

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

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

  • שליחת צינור עיבוד נתונים לשירות
  • הערכת צינור עיבוד נתונים
  • בקשת גישה לטלמטריה ולמדדים במהלך הפעלת צינור עיבוד נתונים ואחריה
  • שימוש בשירות Dataflow כמו Shuffle או Streaming Engine

אחסון ועיבוד נתונים באופן מקומי

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

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

‫Dataflow הוא שירות אזורי. מידע נוסף על אזורים ועל אחסון ועיבוד נתונים באופן מקומי זמין במאמר אזורים ב-Dataflow.

נתונים בצינור עיבוד נתונים שנשלח

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

נתונים בהערכת צינור עיבוד נתונים

במסגרת הערכת צינור עיבוד נתונים, יכול להיות שייווצרו נתונים זמניים שיאוחסנו באופן מקומי במכונות הווירטואליות של ה-worker או ב-Cloud Storage. הנתונים הזמניים מוצפנים במנוחה ולא נשמרים אחרי שהערכת צינור עיבוד הנתונים מסתיימת. הנתונים האלה יכולים גם להישמר בשירות Shuffle או בשירות Streaming Engine (אם בחרתם להשתמש בשירות) באותו אזור שצוין בצינור עיבוד הנתונים של Dataflow.

Java

כברירת מחדל, המכונות הווירטואליות של Compute Engine נמחקות כשמשימת Dataflow מסתיימת, גם אם היא נכשלה. כתוצאה מכך, נמחק גם ה-Persistent Disk שמשויך אליו, וכל נתוני הביניים שעשויים להיות מאוחסנים בו. נתוני הביניים שמאוחסנים ב-Cloud Storage נמצאים במיקומי משנה של הנתיב ב-Cloud Storage שציינתם בתור --stagingLocation או --tempLocation. אם אתם כותבים פלט לקובץ ב-Cloud Storage, יכול להיות שייווצרו קבצים זמניים במיקום הפלט לפני שפעולת ה-"write" תסתיים.

Python

כברירת מחדל, המכונות הווירטואליות של Compute Engine נמחקות כשמשימת Dataflow מסתיימת, גם אם היא נכשלה. כתוצאה מכך, נמחק גם ה-Persistent Disk שמשויך אליו, וכל נתוני הביניים שעשויים להיות מאוחסנים בו. נתוני הביניים שמאוחסנים ב-Cloud Storage נמצאים במיקומי משנה של הנתיב ב-Cloud Storage שציינתם בתור --staging_location או --temp_location. אם אתם כותבים פלט לקובץ ב-Cloud Storage, יכול להיות שייווצרו קבצים זמניים במיקום הפלט לפני שפעולת ה-"write" תסתיים.

המשך

כברירת מחדל, המכונות הווירטואליות של Compute Engine נמחקות כשמשימת Dataflow מסתיימת, גם אם היא נכשלה. כתוצאה מכך, נמחק גם ה-Persistent Disk שמשויך אליו, וכל נתוני הביניים שעשויים להיות מאוחסנים בו. נתוני הביניים שמאוחסנים ב-Cloud Storage נמצאים במיקומי משנה של הנתיב ב-Cloud Storage שציינתם בתור --staging_location או --temp_location. אם אתם כותבים פלט לקובץ ב-Cloud Storage, יכול להיות שייווצרו קבצים זמניים במיקום הפלט לפני שפעולת ה-"write" תסתיים.

נתונים ביומנים ובנתוני הטלמטריה של צינור עיבוד הנתונים

המידע שמאוחסן ב-Cloud Logging נוצר בעיקר על ידי הקוד בתוכנית Dataflow. יכול להיות ששירות Dataflow ייצור גם נתוני אזהרות ושגיאות ב-Cloud Logging, אבל הנתונים האלה הם נתוני הביניים היחידים שהשירות מוסיף ליומנים. ‫Cloud Logging הוא שירות גלובלי.

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

נתונים בשירותי Dataflow

אם אתם משתמשים בארגון נתונים של Dataflow או ב-Dataflow Streaming ב-פייפליין, אל תציינו את האפשרויות של פייפליין באזור. במקום זאת, צריך לציין את האזור ולהגדיר את הערך לאחד מהאזורים שבהם Shuffle או Streaming זמינים. ‫Dataflow בוחר באופן אוטומטי את האזור (zone) באזור (region) שציינתם. נתוני משתמשי הקצה במעבר נשארים בתוך ה-worker VMs ובאותו אזור. משימות Dataflow האלה עדיין יכולות לקרוא ולכתוב למקורות ולכיורים שנמצאים מחוץ לאזור של ה-VM. אפשר גם לשלוח את הנתונים במעבר לשירותי Dataflow Shuffle או Dataflow Streaming. עם זאת, הנתונים תמיד נשארים באזור שצוין בקוד של צינור עיבוד הנתונים.

מומלץ להשתמש במנגנוני האבטחה שזמינים במשאבי הענן הבסיסיים של הצינור. המנגנונים האלה כוללים את יכולות אבטחת המידע של מקורות הנתונים וכיורי הנתונים, כמו BigQuery ו-Cloud Storage. בנוסף, מומלץ לא לערבב רמות אמון שונות בפרויקט אחד.