שימוש במצב קפדני של פעולה בתור

מצב קפדני של פעולה בשם משתמש מאפשר בדיקת אבטחה נוספת לפעולות המשתמש הבאות ב-Dataform:

• יצירה או עדכון של מאגר.
• יצירה או עדכון של הגדרת תהליך עבודה.
• יצירת הפעלה של תהליך עבודה.
• עדכון של הגדרת הפצה.

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

מצב פעולה קפדני מופעל בכל המאגרים.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לביצוע המשימות שמתוארות במסמך הזה, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

• משתמש בחשבון שירות (roles/iam.serviceAccountUser) בחשבון השירות המותאם אישית
• צפייה ביומנים ב-Cloud Logging: מציג היומנים (roles/logging.viewer) בפרויקט
• מקצים תפקידי IAM למשתמשים או לחשבונות שירות: אדמין של חשבון שירות (roles/iam.serviceAccountAdmin) בפרויקט

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

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

אימות הרשאות הפעולה בשם חשבון השירות האפקטיבי

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

קביעת חשבון השירות בפועל

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

סוג המשאב	חשבון שירות אפקטיבי
מאגרים	חשבון השירות המותאם אישית שהוגדר למאגר. נדרש חשבון שירות בהתאמה אישית לכל המאגרים. חשבון השירות הזה מופיע בשדה Repository.ServiceAccount.
הגדרת תהליך עבודה	בהגדרות חדשות של תהליכי עבודה, נעשה שימוש בחשבון השירות המותאם אישית שבוחרים כשיוצרים הגדרות של תהליך עבודה. אם לא נבחר חשבון שירות, המערכת משתמשת בחשבון השירות של המאגר.
הפעלת תהליך עבודה	אם תוצאת הקומפילציה היא משאב WORKFLOW_CONFIG, נעשה שימוש בחשבון השירות האפקטיבי של הגדרת תהליך העבודה. אם יוצרים הפעלה של תהליך עבודה מתוצאת קומפילציה, נעשה שימוש בחשבון השירות שמופיע בשדה WorkflowInvocation.InvocationConfig אם הוא מוגדר. אחרת, ברירת המחדל היא חשבון השירות שהוגדר ברמת המאגר.

הערה: אי אפשר להשתמש בסוכן השירות שמוגדר כברירת מחדל ב-Dataform כדי להריץ תהליכי עבודה. חובה להשתמש בחשבון שירות בהתאמה אישית או בפרטי הכניסה של המשתמש בחשבון Google.

בדיקה של בעיות בהרשאות ב-Cloud Logging

כדי לשפר את האבטחה, Dataform בודק אם חסרה ההרשאה iam.serviceAccounts.actAs בחשבונות השירות שמשמשים את משאבי Dataform.

התוצאות של הבדיקות האלה, כולל בעיות אפשריות בהרשאות, מתועדות ב-Cloud Logging. חשוב לבדוק את היומנים האלה באופן קבוע כדי לזהות הרשאות חסרות ולהעניק אותן.iam.serviceAccounts.actAs בדיקת היומנים האלה מבטיחה שתהליכי העבודה וההגדרות של Dataform ימשיכו לפעול ללא הפרעה.

צפייה ביומנים ב-Cloud Logging

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

   כניסה לדף Logs Explorer

2. בוחרים את Google Cloud הפרויקט שרוצים לבדוק את היומנים שלו.

3. משתמשים בעורך השאילתות כדי לסנן את היומנים של Dataform actAs באמצעות האפשרויות הבאות:

   • כדי להציג רק את הבדיקות actAs שנכשלו ונדרשת פעולה כדי לתקן אותן, משתמשים בשאילתה הבאה:

     logName: "projects/PROJECT_ID/logs/dataform.googleapis.com%2Factas_dry_run_result"
     jsonPayload.dryRunResult = false
     

   • כדי לראות רשימה של כל הבדיקות של actAs, משתמשים בשאילתה הבאה:

     logName: "projects/PROJECT_ID/logs/dataform.googleapis.com%2Factas_dry_run_result"
     

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

4. לוחצים על Run query.

פירוש רשומות ביומן

מרחיבים רשומה ביומן בתוצאות השאילתה כדי לראות את השדות הבאים: jsonPayload

שדה	סוג	תיאור
dryRunResult	בוליאני	‫true: בדיקת ההרשאה עברה בהצלחה. false: הבדיקה נכשלה. לחשבון הראשי שמבצע את הקריאה חסרה ההרשאה iam.serviceAccounts.actAs בחשבון השירות.
caller	String	כתובת האימייל של הישות המורשית (משתמש או חשבון שירות) שהפעילה את הקריאה ל-API.
serviceAccount	String	חשבון השירות שהחשבון הראשי של המתקשר ניסה לפעול בשמו. השדה הזה מופיע בדרך כלל כשהערך של השדה dryRunResult הוא false.
apiMethod	String	שיטת Dataform API שהפעילה את הבדיקה, למשל CreateWorkflowInvocation או UpdateRepository.
*_context	אובייקט	אובייקט שמכיל שמות של משאבים שרלוונטיים לשיטת ה-API שנקראה. מידע נוסף זמין במאמר בנושא אובייקטים של הקשר.

חשוב: יש יוצא מן הכלל כש-dryRunResult הוא false, serviceAccount ריק, ו-apiMethod הוא CreateWorkflowConfig, UpdateWorkflowConfig או CreateWorkflowInvocation. החריגה הזו מציינת שהבדיקה נכשלה, כי לא צוין חשבון שירות בקריאה ל-API במקום שבו הוא נדרש. צריך לעדכן את התהליך כדי לספק חשבון שירות לפעולות האלה.

אובייקטים של הקשר

הרשומה ביומן כוללת אובייקט הקשר בשדות jsonPayload. השדות באובייקט הזה מכילים את שמות המשאבים המוגדרים במלואם של ישויות Dataform שמעורבות בתהליך. Google Cloud השמות האלה מבוססים על המבנים הסטנדרטיים שמוצגים ברשימה הבאה, ומאפשרים לכם לזהות את המשאבים בצורה מדויקת.

• ‫create_workflow_invocation_context: מופיע כששיטת ה-API היא CreateWorkflowInvocation.

  • ‫workflowInvocation: שם המשאב של הפעלת תהליך העבודה.
    • הפורמט של שם המשאב הוא: projects/PROJECT_ID/locations/LOCATION_ID/repositories/REPOSITORY_ID/workflowInvocations/WORKFLOW_INVOCATION_ID.
  • ‫compilationResult או workflowConfig: שם המשאב של המקור שנעשה בו שימוש להפעלת הפונקציה.
    • הפורמט של שם המשאב של compilationResult הוא: projects/PROJECT_ID/locations/LOCATION_ID/repositories/REPOSITORY_ID/compilationResults/COMPILATION_RESULT_ID.
    • הפורמט של שם המשאב של workflowConfig הוא: projects/PROJECT_ID/locations/LOCATION_ID/repositories/REPOSITORY_ID/workflowConfigs/WORKFLOW_CONFIG_ID.

• ‫create_repository_context או update_repository_context: המאפיין הזה מופיע כששיטת ה-API היא CreateRepository או UpdateRepository.

  • ‫repository: שם המשאב של מאגר Dataform.
    • הפורמט של שם המשאב הוא: projects/PROJECT_ID/locations/LOCATION_ID/repositories/REPOSITORY_ID

• ‫update_release_config_context: מופיע כששיטת ה-API היא UpdateReleaseConfig.

  • ‫releaseConfig: שם המשאב של הגדרות הגרסה.
    • הפורמט של שם המשאב הוא: projects/PROJECT_ID/locations/LOCATION_ID/repositories/REPOSITORY_ID/releaseConfigs/RELEASE_CONFIG_ID.

• ‫create_workflow_config_context או update_workflow_config_context: מופיע כששיטת ה-API היא CreateWorkflowConfig או UpdateWorkflowConfig.

  • ‫workflowConfig: שם המשאב של הגדרות תהליך העבודה.
    • הפורמט של שם המשאב הוא: projects/PROJECT_ID/locations/LOCATION_ID/repositories/REPOSITORY_ID/workflowConfigs/WORKFLOW_CONFIG_ID.

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

• ‫PROJECT_ID: המזהה הייחודי של הפרויקט ב-Google Cloud .
• ‫LOCATION_ID: האזור שבו נמצא מאגר Dataform.
• ‫REPOSITORY_ID: המזהה שמוגדר על ידי המשתמש של מאגר Dataform. זה השם שניתן למאגר כשהוא נוצר.
• ‫COMPILATION_RESULT_ID: המזהה הייחודי שנוצר על ידי המערכת לתוצאת הידור (compilation) ב-Dataform.
• ‫RELEASE_CONFIG_ID: המזהה שמוגדר על ידי המשתמש של הגדרת הגרסה ב-Dataform.
• ‫WORKFLOW_CONFIG_ID: המזהה שמוגדר על ידי המשתמש של הגדרת תהליך העבודה ב-Dataform.

פתרון בעיות שקשורות להרשאות

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

מתן הרשאות חסרות של פעולה בשם משתמש

אם מצאתם רשומות ביומן שבהן השדה dryRunResult הוא false, צריך לבצע את הפעולות הבאות:

1. בפרטים של jsonPayload, שימו לב לכתובת האימייל בשדה caller כדי לזהות את החשבון הראשי.

2. שימו לב לכתובת האימייל בשדה serviceAccount כדי לזהות את חשבון השירות.

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

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

אחרי שמעניקים את התפקיד, ביומנים עתידיים של השילוב הזה של המתקשר וחשבון השירות אמור להופיע dryRunResult: true.

טיפול בצירוף של חשבונות שירות בין פרויקטים

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

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

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

הקצאת התפקידים הנדרשים ב-IAM

התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) כולל את ההרשאה iam.serviceAccounts.actAs, שנדרשת למצב 'פועל בשם' מחמיר. כשמשתמשים ב-Dataform API, צריך לקבל את התפקיד Service Account User עבור חשבון השירות הרלוונטי, בהתאם לשיטה projects.locations.repositories שקוראים לה:

• ‫create או patch
  • אם הנכס Repository.ServiceAccount מוגדר, צריך לקבל את התפקיד Service Account User עבור הנכס הזה.
  • אם אתם קוראים לשיטה patch, צריך להקצות את התפקיד Service Account User לכל חשבונות השירות הרלוונטיים בכל הגדרות זרימת העבודה במאגר.
• ‫workflowConfigs.create או workflowConfigs.patch
  • צריך לקבל את התפקיד Service Account User עבור חשבון השירות האפקטיבי שמשמש בהגדרת תהליך העבודה.
• releaseConfigs.patch
  • צריך להקצות את התפקיד 'משתמש בחשבון שירות' לכל חשבונות השירות הרלוונטיים שמשמשים בהגדרות של תהליכי העבודה באמצעות הגדרת הגרסה הזו.
• workflowInvocations.create
  • צריך לקבל את התפקיד Service Account User עבור חשבון השירות האפקטיבי שמשמש להפעלת תהליך העבודה.

כדי להעניק את התפקיד Service Account User לחשבון שירות בהתאמה אישית:

1. במסוף Google Cloud , נכנסים אל IAM > Service accounts.

   כניסה לדף Service accounts

2. בוחרים פרויקט.

3. בדף Service accounts for project "PROJECT_NAME", בוחרים את חשבון השירות המותאם אישית.

4. עוברים אל Principals with access ולוחצים על Grant Access.

5. בשדה New principals, מזינים את מזהה סוכן השירות שמוגדר כברירת מחדל ב-Dataform.

   מזהה סוכן השירות שמוגדר כברירת מחדל ב-Dataform הוא בפורמט הבא:

   [e-mail]
   

   מחליפים את PROJECT_NUMBER במספר הפרויקט ב-Google Cloud .

6. ברשימה Select a role בוחרים בתפקיד Service Account User.

7. לוחצים על Add another role ובוחרים את התפקיד Service Account Token Creator.

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

8. לוחצים על Save.

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

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

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

למאגרים שלא מקושרים למאגרי צד שלישי:

• אי אפשר להגדיר תזמון Cron להפצות אוטומטיות בהגדרות ההפצה. האכיפה הזו נועדה למנוע פריסה אוטומטית של שינויים בקוד שבוצעו על ידי משתמשים שאולי חסרות להם הרשאות iam.serviceAccounts.actAs בחשבונות שירות במורד הזרם.
• הפעלות מתוזמנות של תהליכי עבודה באמצעות תזמון Cron בהגדרות של תהליכי עבודה נשארות מופעלות. כדי שהרצות אוטומטיות כאלה יצליחו, צריך להעניק לסוכן השירות שמוגדר כברירת מחדל ב-Dataform את ההרשאה iam.serviceAccounts.actAs בחשבון השירות האפקטיבי שצוין בהגדרת תהליך העבודה.

למאגרים שמקושרים למאגרים של צד שלישי:

• מותרות הפצות מתוזמנות והפעלות מתוזמנות של תהליכי עבודה.
• כדי להפעיל הפצה אוטומטית מהגדרות ההפצה או הפעלה אוטומטית מהגדרות תהליך העבודה, צריך להעניק לסוכן השירות שמוגדר כברירת מחדל ב-Dataform את ההרשאה iam.serviceAccounts.actAs בחשבון השירות הרלוונטי:
  • בהגדרת הפצה אוטומטית, צריך להעניק את ההרשאה לחשבונות השירות האפקטיביים של כל הגדרות זרימת העבודה שמופעלות על ידי הגדרת ההפצה הזו.
  • כדי להגדיר תהליך עבודה אוטומטי, צריך להעניק את ההרשאה לחשבון השירות האפקטיבי שמשמש להגדרת תהליך העבודה.

אזהרה: מכיוון שאין ערובה לכך שלמשתמש שכותב את הקוד יש את ההרשאה iam.serviceAccounts.actAs בחשבונות השירות הרלוונטיים עבור מאגר צד שלישי, באחריותכם לשלוט בשינויים בקוד במאגרי צד שלישי באמצעות תהליך סקר הקוד.

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

• במאמר יצירת מאגר מוסבר איך ליצור מאגר.
• מידע נוסף על אופן הפעולה של Dataform עם BigQuery זמין במאמר בנושא סקירה כללית של תהליכי עבודה.
• כדי ללמוד איך יוצרים הגדרת תהליך עבודה, אפשר לעיין במאמר בנושא תזמון הרצות.
• כדי ללמוד איך ליצור הגדרת הפצה, אפשר לעיין במאמר הגדרת קומפילציות.