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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשמריצים באופן מקומי, צינור עיבוד הנתונים של 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 כחלק מבקשת יצירת המשימה, למשל כדי לבדוק את מכסת הפרויקט וכדי ליצור מכונות עובד בשמכם. בנוסף, חשבון השירות של Dataflow משמש את Dataflow במהלך ההרצה של המשימה לניהול המשימה. החשבון הזה נקרא גם סוכן השירות של Dataflow.

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

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

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

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

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

חשבון שירות Dataflow

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

[e-mail]

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

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

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

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

המסוף

1. עוברים לדף תפקידים.

   לדף 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

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

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

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

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

• קטגוריות של Cloud Storage
• מערכי נתונים ב-BigQuery
• נושאים ומינויים ב-Pub/Sub
• מערכי נתונים ב-Firestore

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

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

[e-mail]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. בפרויקט שמכיל את חשבון השירות של העובד (worker) שמנוהל על ידי המשתמש, לחשבון השירות של Dataflow ([e-mail]) ולסוכן השירות של Compute Engine ([e-mail]) צריכים להיות התפקידים הבאים. ‫PROJECT_NUMBER הוא מזהה הפרויקט שבו מופעלת משימת Dataflow. שני החשבונות האלה הם סוכני שירות.

   • התפקיד 'יצירת אסימונים בחשבון שירות' (iam.serviceAccountTokenCreator)
   • התפקיד 'משתמש בחשבון שירות' (iam.serviceAccountUser)

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

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

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

   Java

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

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

   Python

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

   Go

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

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

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

כדי להוסיף תפקידים לפרויקט, פועלים לפי השלבים הבאים.

המסוף

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

   כניסה לדף IAM

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

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

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

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

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

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

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

   במאמר איך נותנים תפקידים ב-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. מעניקים תפקידים לחשבון השירות של העובד. מריצים את הפקודה הבאה עבור תפקיד IAM‏ roles/dataflow.worker ועבור כל תפקיד שנדרש על ידי משאבים שמשמשים בעבודה. אם לחשבון השירות של העובד נדרש תפקיד אדמין ב-Dataflow, חוזרים על הפעולה עבור תפקיד ה-IAM‏ roles/dataflow.admin. בדוגמה הזו נעשה שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, אבל מומלץ להשתמש בחשבון שירות שמנוהל על ידי המשתמש.

   gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:[e-mail]" --role=SERVICE_ACCOUNT_ROLE
   

   • מחליפים את PROJECT_ID במזהה הפרויקט.
   • מחליפים את PROJECT_NUMBER במספר הפרויקט. כדי למצוא את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים או להשתמש בפקודה gcloud projects describe.
   • מחליפים את SERVICE_ACCOUNT_ROLE בכל אחד מהתפקידים.

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

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

• מאגרי Artifact Registry
• קטגוריות של Cloud Storage
• מערכי נתונים ב-BigQuery
• נושאים ומינויים ב-Pub/Sub
• מערכי נתונים ב-Firestore

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

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

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

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

כשמשתמשים במאגרי תגים מותאמים אישית עם Dataflow, יכול להיות שתעלו ארטיפקטים למאגר Artifact Registry.

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

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

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

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

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

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:[e-mail]" --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 שלכם. מידע נוסף על הגבלות דומיין זמין במאמר הגבלת זהויות לפי דומיין.

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

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

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

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

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

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

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

• החשבון Google Cloud שמשמש להפעלת משימת Dataflow
• חשבון השירות של העובד שמריץ את משימת 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, צריך להשתמש בתכונות של ניהול זהויות והרשאות גישה ב-Pub/Sub כדי להגדיר הרשאות לחשבון השירות של העובד.

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

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

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

גישה ל-Firestore

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

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

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

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

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

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

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

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

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

סביבת נתונים

הערה: מומלץ תמיד לציין אזור כשמריצים צינור עיבוד נתונים.

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

הלוגיקה של צינור הנתונים מוערכת במופעי worker VM בודדים. אפשר לציין את האזור שבו נמצאים המקרים האלה והרשת הפרטית שדרכה הם מתקשרים. חישובים משניים לפלטפורמה תלויים במטא-נתונים, כמו מיקומים ב-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` תושלם.

Go

כברירת מחדל, מכונות וירטואליות ב-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 בצינור עיבוד הנתונים, אל תציינו את אפשרויות הצינור של האזור. במקום זאת, צריך לציין את האזור ולהגדיר את הערך לאחד מהאזורים שבהם התכונות 'ערבוב' או 'סטרימינג' זמינות. ‫Dataflow בוחר באופן אוטומטי את האזור בתוך האזור שציינתם. הנתונים של משתמשי הקצה בזמן ההעברה נשארים במכונות הווירטואליות של העובדים ובאותו אזור. עבודות Dataflow האלה עדיין יכולות לקרוא ולכתוב למקורות וליעדים שנמצאים מחוץ לאזור של מכונת ה-VM. אפשר גם לשלוח את הנתונים במעבר לשירותים ארגון נתונים של Dataflow או Dataflow Streaming, אבל הנתונים תמיד נשארים באזור שצוין בקוד של צינור הנתונים.

שיטה מומלצת

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