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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. יכול להיות שחשבון השירות שלכם יזדקק לתפקידים נוספים כדי להשתמש במשאבים שנדרשים לעבודה, כמו BigQuery,‏ Pub/Sub או Cloud Storage. Google Cloudלדוגמה, אם העבודה קוראת מ-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

   המשך

   משתמשים באפשרות --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 API זמין במאמר בקרת גישה ב-BigQuery.

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

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

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

Java

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

Python

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

המשך

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

שיטה מומלצת

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