במאמר הזה נסביר איך לבצע את הפעולות הבאות ב-Dataform:
- איך מעניקים ל-Dataform את הגישה הנדרשת
- שליטה בגישה ל-Dataform באמצעות IAM
- שליטה בגישה לטבלאות נפרדות באמצעות IAM.
לפני שמתחילים
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles. - Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
Verify that billing is enabled for your Google Cloud project.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM
role (roles/serviceusage.serviceUsageAdmin), which
contains the serviceusage.services.enable permission. Learn how to grant
roles.
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
Verify that billing is enabled for your Google Cloud project.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM
role (roles/serviceusage.serviceUsageAdmin), which
contains the serviceusage.services.enable permission. Learn how to grant
roles.
הענקת הגישה הנדרשת ל-Dataform
בקטע הזה מוסבר איך להעניק את התפקידים לניהול זהויות והרשאות גישה (IAM) שסוכני השירות של Dataform וחשבונות שירות בהתאמה אישית צריכים כדי להריץ תהליכי עבודה ב-BigQuery.
מידע על חשבונות שירות בהתאמה אישית וסוכני שירות של Dataform
אפשר להגדיר חשבונות שירות בהתאמה אישית כדי להריץ תהליכי עבודה בשמכם באחת מהדרכים הבאות:
- ברמת המאגר, כדי להריץ את כל תהליכי העבודה במאגר נתון.
- בנפרד לכל הגדרת תהליך עבודה.
כשיוצרים מאגר Dataform או הגדרת תהליך עבודה, אפשר לבחור כל חשבון שירות שיש לכם הרשאות act-as לגביו. אתם צריכים להגדיר את הרשאות הפעולה הנדרשות לכל חשבונות השירות שמשויכים למשאבי Dataform.
כשיוצרים את מאגר Dataform הראשון, Dataform יוצר באופן אוטומטי סוכן שירות שמוגדר כברירת מחדל. Dataform משתמש בסוכן השירות שמוגדר כברירת מחדל כדי ליצור אינטראקציה עם BigQuery בשמכם.
מזהה סוכן השירות שמוגדר כברירת מחדל ב-Dataform הוא בפורמט הבא:
service-PROJECT_NUMBER@gcp-sa-dataform.iam.gserviceaccount.com
מחליפים את PROJECT_NUMBER במזהה המספרי שלGoogle Cloud הפרויקט. אפשר לראות את Google Cloud מזהה הפרויקט בלוח הבקרה של המסוף.Google Cloud מידע נוסף זמין במאמר איך מוצאים את השם, המספר והמזהה של הפרויקט.
תפקידים נדרשים לסוכני שירות של Dataform, לחשבונות שירות בהתאמה אישית ולחשבונות Google
סוכני שירות שמוגדרים כברירת מחדל ב-Dataform, חשבונות שירות בהתאמה אישית ופרטי כניסה של משתמשים בחשבון Google (בגרסת Preview) שמשמשים לאימות ב-Dataform, צריכים את תפקידי ה-IAM הבאים ב-BigQuery כדי להריץ תהליכי עבודה ב-BigQuery:
- BigQuery Data Editor
(
roles/bigquery.dataEditor) בפרויקטים שבהם ל-Dataform צריכה להיות גישת קריאה וכתיבה. בדרך כלל הם כוללים את הפרויקט שמארח את מאגר Dataform. - BigQuery Data Viewer (
roles/bigquery.dataViewer) בפרויקטים ש-Dataform צריכה גישה לקריאה בלבד אליהם. - BigQuery Job User
(
roles/bigquery.jobUser) בפרויקט שמארח את מאגר Dataform. - בעלים של נתונים ב-BigQuery
(
roles/bigquery.dataOwner) אם רוצים להריץ שאילתות במערכי נתונים ב-BigQuery. - תפקידים ב-BigQuery לבקרת גישה ברמת העמודה אם רוצים להשתמש בתגי מדיניות של BigQuery.
בנוסף, מקצים לסוכן השירות שמוגדר כברירת מחדל ב-Dataform את התפקידים הבאים בחשבון השירות האפקטיבי של הגדרת תהליך העבודה. התפקידים האלה נדרשים כדי שהמצב 'פועל כ' יפעל בצורה מדויקת.
- משתמש בחשבון שירות
(
roles/iam.serviceAccountUser) - יצירת אסימונים בחשבון שירות
(
roles/iam.serviceAccountTokenCreator)
כדי להפעיל יצירת גרסאות אוטומטית של מאגרים והרצות אוטומטיות של תהליכי עבודה, צריך להעניק לסוכן השירות שמוגדר כברירת מחדל ב-Dataform את ההרשאה iam.serviceAccounts.actAs בחשבון השירות בפועל.
שיקולי אבטחה
כשמקצים את התפקידים שנדרשים ל-Dataform לסוכן שירות של Dataform, לחשבון שירות בהתאמה אישית או לחשבון Google של משתמש (גרסת Preview), צריך לקחת בחשבון את שיקולי האבטחה הבאים:
כל חשבון שירות בהתאמה אישית שקיבל את התפקידים הנדרשים עשוי לקבל גישה ל-BigQuery או ל-Secret Manager בפרויקט שאליו חשבון השירות משויך, ללא קשר ל-VPC Service Controls. כש-Dataform משתמש בחשבון שירות בהתאמה אישית כדי להריץ תהליכי עבודה, הבקשות של Dataform נחשבות כבקשות שמקורן בתוך גבולות הגזרה של VPC Service Controls של הפרויקט שמכיל את המאגר. לכן, VPC Service Controls לא חוסם את התקשורת בין Dataform לבין שירותים אחרים, כמו BigQuery או Secret Manager, אם המשאבים האלה נמצאים באותם גבולות גזרה לשירות.
פרטים נוספים על ניהול גבולות האבטחה האלה זמינים במאמר בנושא הגדרת VPC Service Controls.
כל משתמש שיש לו הרשאת IAM
dataform.repositories.createיכול להריץ קוד באמצעות סוכן השירות שמוגדר כברירת מחדל ב-Dataform וכל ההרשאות שניתנו לסוכן השירות או לחשבון השירות הזה.מידע נוסף זמין במאמר בנושא שיקולי אבטחה לגבי הרשאות ב-Dataform.
כדי לשמור על מודל הרשאות מאובטח, מומלץ לבדוק באופן קבוע את הקישורים של תפקידי סוכן השירות ב-Dataform. הוראות מפורטות למעקב מופיעות במאמר מעקב אחרי הרשאות של סוכני שירות באמצעות Security Command Center.
כדי להגביל את הנתונים שמשתמש, סוכן שירות או חשבון שירות יכולים לקרוא או לכתוב ב-BigQuery, אפשר להעניק הרשאות IAM מדויקות ב-BigQuery למערכי נתונים או לטבלאות נבחרים ב-BigQuery. מידע נוסף זמין במאמרים שליטה בגישה למערכי נתונים ושליטה בגישה לטבלאות ולתצוגות.
כדי למנוע ממשתמשים לבצע פעולות בזמן שהם משתמשים בפרטי הכניסה של משתמש אחר לחשבון Google, נאכפות ההגבלות הבאות:
- כדי לשנות הגדרת תהליך עבודה באמצעות פרטי הכניסה של משתמש בחשבון Google אחר שמצורף אליה, צריך לצרף את פרטי הכניסה של המשתמש בחשבון Google שלכם להגדרת תהליך העבודה, או לשנות את הגדרת תהליך העבודה כך שתתבצע אימות באמצעות חשבון שירות בהתאמה אישית.
- אי אפשר לשנות תוצאת קומפילציה של הגדרת הפצה אם יש הגדרות של תהליכי עבודה שמפנות להגדרת ההפצה, וצורפו אליהן פרטי כניסה של משתמש אחר בחשבון Google.
אי אפשר להגדיר אימות של תהליך עבודה באמצעות פרטי כניסה של משתמש בחשבון Google ולהפנות להגדרת הפצה עם לוח זמנים. המגבלה הזו מובילה לתוצאות הבאות:
- אי אפשר לעדכן את הגדרות הגרסה כך שישתמשו בלוח זמנים אם יש הגדרות של תהליכי עבודה שמפנות להגדרות הגרסה ומוגדרות לאימות באמצעות פרטי משתמש בחשבון Google.
- אי אפשר ליצור הגדרת תהליך עבודה שמאמתת באמצעות פרטי כניסה של משתמש בחשבון Google ומפנה להגדרת הפצה עם לוח זמנים.
- אי אפשר ליצור או לעדכן הגדרת תהליך עבודה כדי להשתמש בפרטי משתמש בחשבון Google ולהפנות להגדרת הפצה עם לוח זמנים.
הקצאת התפקידים הנדרשים ב-BigQuery
כדי להעניק את תפקידי ה-IAM הנדרשים ב-BigQuery לסוכן השירות שמוגדר כברירת מחדל ב-Dataform, לחשבון שירות בהתאמה אישית שרוצים להשתמש בו ב-Dataform או לחשבון Google של משתמש שרוצים להשתמש בו כדי לבצע אימות ב-Dataform (גרסת Preview), פועלים לפי השלבים הבאים:
נכנסים לדף Dataform במסוף Google Cloud .
בוחרים מאגר או יוצרים מאגר.
נכנסים לדף IAM במסוף Google Cloud .
לוחצים על הענקת גישה.
בשדה New principals, מזינים את מזהה סוכן השירות, מזהה חשבון השירות או כתובת האימייל של חשבון Google של המשתמש (תצוגה מקדימה).
ברשימה Select a role בוחרים בתפקיד BigQuery Job User.
לוחצים על Add another role, ואז ברשימה Select a role בוחרים בתפקיד BigQuery Data Editor.
לוחצים על Add another role ובוחרים את התפקיד BigQuery Data Viewer מהרשימה Select a role.
לוחצים על Save.
מתן התפקידים הנדרשים לתהליכי עבודה אוטומטיים
כדי להשתמש בחשבון שירות בהתאמה אישית ב-Dataform, לסוכן השירות שמוגדר כברירת מחדל ב-Dataform צריכה להיות גישה לחשבון השירות בהתאמה אישית. כך, Dataform יכול להריץ את תהליכי העבודה שלכם באמצעות ההרשאות שמוגדרות בחשבון השירות המותאם אישית, ולא בחשבון של סוכן השירות שמוגדר כברירת מחדל.
כדי להעניק את הגישה הזו, צריך להקצות לסוכן השירות של Dataform שמוגדר כברירת מחדל את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) כחשבון המשתמש. כך סוכן השירות של Dataform שמוגדר כברירת מחדל יכול להתחזות לחשבון השירות על ידי יצירת פרטי כניסה לטווח קצר שנקראים אסימונים. האסימונים האלה נדרשים כדי ש-Dataform יפעיל תהליכי עבודה באמצעות הזהות של חשבון השירות בהתאמה אישית.
צריך גם להקצות את התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) לסוכן השירות של Dataform שמוגדר כברירת מחדל. כך סוכן השירות שמוגדר כברירת מחדל ב-Dataform יכול להתחיל הפעלות אוטומטיות חדשות של תהליכי עבודה, עבור הגדרות של תהליכי עבודה שמופעלים על ידי חשבון השירות בהתאמה אישית.
כדי להעניק לסוכן השירות שמוגדר כברירת מחדל של Dataform גישה לחשבון שירות בהתאמה אישית:
במסוף Google Cloud , נכנסים אל IAM > Service accounts.
בוחרים את הפרויקט שבו נמצא חשבון השירות המותאם אישית. Google Cloud
בדף Service accounts for project "PROJECT_NAME", בוחרים את חשבון השירות המותאם אישית.
עוברים אל Principals with access ולוחצים על Grant Access.
בשדה New principals, מזינים את מזהה סוכן השירות שמוגדר כברירת מחדל ב-Dataform.
מזהה סוכן השירות שמוגדר כברירת מחדל ב-Dataform הוא בפורמט הבא:
service-PROJECT_NUMBER@gcp-sa-dataform.iam.gserviceaccount.comברשימה Select a role בוחרים את התפקיד Service Account Token Creator ואת התפקיד Service Account User.
לוחצים על Save.
עכשיו אפשר להגדיר את חשבון השירות המותאם אישית במאגר Dataform.
ביקורת על הגדרות של חשבונות שירות
בקטע הזה מוסבר איך לבצע ביקורת על משאבי Dataform כדי לוודא שנעשה שימוש נכון בחשבונות שירות ושההרשאות ניתנו בצורה תקינה. ביקורת חשובה במיוחד כשמשתמשים בחשבונות שירות בהתאמה אישית, כי הם דורשים הרשאות ספציפיות כדי שסוכן השירות של Dataform יוכל לפעול.
כשמשתמשים בחשבון שירות בהתאמה אישית עבור מאגר או הגדרת תהליך עבודה של Dataform, צריך לוודא שלסוכן השירות של Dataform שמוגדר כברירת מחדל יש את התפקיד Service Account User (roles/iam.serviceAccountUser) בחשבון השירות בהתאמה אישית. התפקיד הזה מעניק את ההרשאה iam.serviceAccounts.actAs, שמאפשרת להפעלות מתוזמנות, שהופעלו על ידי סוכן השירות שמוגדר כברירת מחדל ב-Dataform, להתחזות לחשבון השירות בהתאמה אישית. בנוסף, מוודאים שלסוכן השירות של Dataform שמוגדר כברירת מחדל יש את התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) בחשבון השירות הרלוונטי.
אימות חשבונות שירות של מאגרים
קודם כל, צריך לזהות את dataform.Repository הנכסים שנכללים בתזמון ובהרצה של Dataform. לאחר מכן, מאמתים את ההגדרות של חשבונות השירות במאגרי המידע האלה.
משתמשים במאגר משאבי הענן כדי להציג רשימה של כל המשאבים מסוג
dataform.Repository. מידע נוסף מופיע במאמר בנושא צפייה בנכסים.לגבי כל מאגר בתוצאות של מאגר משאבי ענן, בודקים את השדה
resource.data.labelsכדי לראות אם הוא בהיקף. הנתיב המדויק עשוי להשתנות מעט בהתאם לפורמט הייצוא.כדי לזהות מאגרי מידע שלא נכללים בהיקף, בודקים את מפת התוויות לפי המפתח
single-file-asset-type. הנוכחות של המפתח הזה מציינת שהמאגר נמצא בשימוש של תכונה ב-BigQuery. אם הערך הואsqlאוdata_canvas, אפשר להחריג את המאגר מבדיקות ההרשאות של חשבון השירות.המאגרים הנותרים שחסר בהם המפתח או הערכים האלה נמצאים בהיקף של בדיקות ההרשאות של חשבון השירות.
לכל מאגר שנכלל בהיקף, בודקים את השדה
resource.data.serviceAccountבפלט של מאגר משאבי הענן כדי לקבוע אם מוגדר חשבון שירות בהתאמה אישית:- אם השדה
resource.data.serviceAccountקיים והערך שלו שונה מכתובת האימייל של סוכן השירות שמוגדר כברירת מחדל ב-Dataform, המשמעות היא שהמאגר משתמש בחשבון שירות בהתאמה אישית. אם השדה
resource.data.serviceAccountלא מופיע, או אם הערך של השדה תואם לסוכן השירות שמוגדר כברירת מחדל בפרויקט Dataform, המאגר ישתמש בסוכן השירות שמוגדר כברירת מחדל.
- אם השדה
אם משתמשים בחשבון שירות בהתאמה אישית, צריך לוודא שלסוכן השירות שמוגדר כברירת מחדל ב-Dataform יש את התפקידים 'משתמש בחשבון שירות' (
roles/iam.serviceAccountUser) ו'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) בחשבון השירות בהתאמה אישית.
אימות חשבונות השירות של תהליך העבודה
שימוש בחשבונות שירות ייעודיים בהתאמה אישית להגדרות של תהליכי עבודה ב-Dataform הוא שיטה מומלצת לאבטחה, בהתאם לעיקרון של הרשאות מינימליות.
כדי לאמת את השימוש בחשבון שירות ב-dataform.WorkflowConfig resources, צריך לבצע את הפעולות הבאות:
אפשר להשתמש במאגר משאבי הענן כדי להציג רשימה של כל המשאבים מסוג
dataform.WorkflowConfig.לכל הגדרת תהליך עבודה, בודקים את הפלט של מאגר משאבי ענן כדי לקבוע את חשבון השירות בפועל:
- אם השדה
resource.data.serviceAccountמופיע, הערך שלו הוא כתובת האימייל של חשבון השירות שהוגדרה באופן מפורש בהגדרות של תהליך העבודה. - אם השדה
resource.data.serviceAccountלא מופיע, חשבון השירות עובר בירושה מהמאגר הראשי של הגדרת תהליך העבודה. כדי למצוא את חשבון השירות האפקטיבי, צריך לבדוק את ההגדרה של מאגר האב העליון.
- אם השדה
כדי לדעת אם נעשה שימוש בחשבון שירות בהתאמה אישית, משווים את כתובת האימייל של חשבון השירות בפועל לכתובת האימייל של סוכן השירות שמוגדר כברירת מחדל בפרויקט של Dataform. אם הם שונים, נעשה שימוש בחשבון שירות בהתאמה אישית.
אם משתמשים בחשבון שירות בהתאמה אישית, צריך לוודא שלסוכן השירות של Dataform שמוגדר כברירת מחדל יש את התפקידים 'משתמש בחשבון שירות' (
roles/iam.serviceAccountUser) ו'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) בחשבון השירות הזה בהתאמה אישית. ההרשאות האלה מאפשרות לסוכן השירות של Dataform שמוגדר כברירת מחדל להתחיל הרצות של תהליכי עבודה תוך התחזות לחשבון השירות המותאם אישית.
מעקב אחרי הרשאות של סוכני שירות באמצעות Security Command Center
כדי לוודא שאתם ממשיכים לפעול לפי העיקרון של הרשאות מינימליות, כדאי לעקוב באופן פעיל אחרי הפרויקט ב-Security Command Center ולחפש ממצאים שקשורים לחשבונות שירות ולסוכני שירות עם הרשאות מוגזמות.
הוראות לבדיקה וליישום של ממצאי תיקון ב-Security Command Center זמינות במאמרים ממצאי IAM Recommender ובדיקת ממצאי זהות במסוף.
כשמבצעים פעולות לתיקון ממצא SERVICE_AGENT_GRANTED_BASIC_ROLE של סוכן שירות של Dataform, מחליפים את התפקיד עם יותר מדי הרשאות בתפקיד מוגדר מראש עם ההרשאות המינימליות שנדרשות, בהיקף של המשאב הספציפי. לדוגמה, אפשר להעניק את התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) בחשבון שירות ספציפי.
שליטה בגישה ל-Dataform באמצעות IAM
בקטע הזה מוסבר על אפשרויות בקרת הגישה ב-Dataform ואיך צופים בתפקידים ב-Dataform ומעניקים אותם. Dataform משתמש בניהול זהויות והרשאות גישה (IAM) לבקרת גישה. מידע נוסף על תפקידים והרשאות ב-IAM זמין במאמר אינדקס של תפקידים והרשאות ב-IAM.
תפקידים מוגדרים מראש ב-Dataform
בטבלה הבאה מפורטים התפקידים המוגדרים מראש שנותנים לכם גישה למשאבי Dataform:
| Role | Permissions |
|---|---|
Dataform Admin( Full access to all Dataform resources. |
|
Dataform Editor( Edit access to Workspaces and Read-only access to Repositories. |
|
Dataform Viewer( Read-only access to all Dataform resources. |
|
Code Commenter Beta( Permissions to comment, at the repository level. Grants CRUD access over commentThread and comment resources. |
|
Code Creator( Access only to private and shared code resources. The permissions in the Code Creator let you create and list code in Dataform, and access only the code that you created and code that was explicitly shared with you. |
|
Code Editor( Edit access code resources. |
|
Code Owner( Full access to code resources. |
|
Code Scheduler Beta( Access for scheduling workflows and releases. |
|
Code Viewer( Read-only access to all code resources. |
|
Team Folder Commenter Beta( View and comment access to a team folder and its contents. |
|
Team Folder Contributor( Edit access to a team folder and its contents. |
|
Team Folder Creator( Access to create new team folders. |
|
Team Folder Owner( Full access to a team folder and its contents. Can share the team folder and its contents. |
|
Team Folder Viewer( View access to a team folder and its contents. |
|
Service agent roles
Service agent roles should only be granted to service agents.
| Role | Permissions |
|---|---|
Dataform Service Agent( Gives permission for the Dataform API to access a secret from Secret Manager |
|
תפקידים מותאמים אישית ב-Dataform
תפקידים בהתאמה אישית יכולים לכלול כל הרשאה שתציינו. אתם יכולים ליצור תפקידים בהתאמה אישית שכוללים הרשאות לביצוע פעולות אדמיניסטרטיביות ספציפיות, כמו יצירת סביבות עבודה לפיתוח או יצירת קבצים וספריות בסביבת עבודה לפיתוח. במאמר יצירה וניהול של תפקידים בהתאמה אישית מוסבר איך יוצרים תפקידים כאלה.
שיקולי אבטחה לגבי הרשאות ב-Dataform
כל משתמש שיש לו הרשאת dataform.repositories.create יכול להריץ קוד ב-BigQuery באמצעות חשבון שירות מותאם אישית וכל ההרשאות שניתנו לחשבון השירות הזה. זה כולל את ההפעלה של תהליכי עבודה ב-Dataform.
מכיוון שמצב act-as מחמיר נאכף בכל המאגרים, ההרשאה dataform.repositories.create מחייבת באופן מרומז שלמשתמש יהיו הרשאות act-as בחשבון השירות המותאם אישית להרצת תהליכי עבודה עוקבים. כך אפשר לוודא שרק משתמשים עם הרשאות התחזות מפורשות יכולים להריץ קוד באמצעות הזהות של חשבון השירות.
ההרשאה dataform.repositories.create כלולה בתפקידי ה-IAM הבאים:
- BigQuery Admin (
roles/bigquery.admin) - BigQuery Job User (
roles/bigquery.jobUser) - BigQuery Studio User (
roles/bigquery.studioUser) - BigQuery User (
roles/bigquery.user) - Code Creator (
roles/dataform.codeCreator) - עורך קוד (
roles/dataform.codeEditor) - בעלים של קוד (
roles/dataform.codeOwner) - משתמש ב-Colab Enterprise (
roles/aiplatform.colabEnterpriseUser) - אדמין של Dataform (
roles/dataform.admin)
כדי להגביל את הנתונים שמשתמש או חשבון שירות יכולים לקרוא או לכתוב ב-BigQuery, אפשר להעניק הרשאות IAM מדויקות ב-BigQuery למערכי נתונים או לטבלאות נבחרים ב-BigQuery. מידע נוסף זמין במאמרים שליטה בגישה למערכי נתונים ושליטה בגישה לטבלאות ולתצוגות.
מידע נוסף על חשבונות שירות בהתאמה אישית, על התפקידים וההרשאות שנדרשים להם, זמין במאמר מתן גישה נדרשת ל-Dataform.
הצגת התפקידים ב-Dataform
במסוף Google Cloud , מבצעים את השלבים הבאים:
עוברים לדף IAM & Admin > Roles.
בשדה Filter (סינון), בוחרים באפשרות Used in (בשימוש ב), מקלידים
Dataformולוחצים על Enter.לוחצים על אחד מהתפקידים שמופיעים ברשימה כדי לראות את ההרשאות של התפקיד בחלונית השמאלית.
לדוגמה, לתפקיד Dataform Admin יש גישה מלאה לכל המשאבים של Dataform.
מידע נוסף על הקצאת תפקיד בפרויקט מופיע במאמר הקצאת תפקיד. אפשר להקצות כך תפקידים מוגדרים מראש או תפקידים בהתאמה אישית.
שליטה בגישה למאגר יחיד
כדי לשלוט בגישה ל-Dataform באמצעות הרשאות גרנולריות, אפשר להגדיר תפקידי IAM ב-Dataform במאגרי נתונים נפרדים באמצעות בקשת Dataform API repositories.setIamPolicy.
כדי להגדיר תפקידי IAM ב-Dataform במאגר Dataform ספציפי, פועלים לפי השלבים הבאים:
במסוף, מעבירים את בקשת Dataform API
repositories.setIamPolicyעם מדיניות גישה.במדיניות, מקשרים משתמש, קבוצה, דומיין, סוכן שירות או חשבון שירות לתפקיד שנבחר בפורמט הבא:
{ "policy": { "bindings": [ { "role": "roles/ROLE", "members": [ "TYPE:IDENTIFIER", ] }, ], } }מחליפים את מה שכתוב בשדות הבאים:
-
ROLE: תפקיד ה-IAM ב-Dataform שרוצים להקצות למאגר. TYPE:user,group,domainאוserviceAccount.-
IDENTIFIER: המשתמש, הקבוצה, הדומיין או חשבון השירות שרוצים להקצות לו את התפקיד.
-
בדף IAM, מוודאים שכל המשתמשים יכולים לראות את הרשימה המלאה של מאגרי Dataform באמצעות תפקיד Dataform עם ההרשאה
dataform.repositories.list.ב-IAM, מוודאים שרק למשתמשים שזקוקים לגישה מלאה לכל מאגרי Dataform מוענק התפקיד Dataform Admin בכל המאגרים.
הפקודה הבאה מעבירה את בקשת repositories.setIamPolicy Dataform API שמעניקה למשתמש יחיד את התפקיד Dataform Editor במאגר sales:
curl -H "Content-Type: application/json" -X POST -d '{ "policy": { "bindings": [{ "role": "roles/dataform.editor", "members": ["user:sasha@examplepetstore.com"]}] }}' "https://dataform.googleapis.com/v1/projects/examplepetstore/locations/us-central1/repositories/sales:setIamPolicy"
מתן גישה ציבורית למאגר
כדי להעניק גישה ציבורית למאגר Dataform, צריך להקצות תפקידי IAM במאגר לחשבון המשתמש allAuthenticatedUsers.
כשמקצים תפקיד IAM לחשבון הראשי allAuthenticatedUsers, חשבונות השירות וכל המשתמשים באינטרנט שאומתו באמצעות חשבון Google מקבלים את התפקיד הזה. הוא כולל חשבונות שלא מחוברים לחשבון Google Workspace או לדומיין ב-Cloud Identity, כמו חשבונות Gmail אישיים. משתמשים לא מאומתים, כמו מבקרים אנונימיים, לא נכללים בו. מידע נוסף זמין במאמר בנושא כל המשתמשים המאומתים.
לדוגמה, כשנותנים את התפקיד 'צפייה ב-Dataform' ל-allAuthenticatedUsers במאגר sales, לכל חשבונות השירות ולכל המשתמשים באינטרנט שאומתו באמצעות חשבון Google יש גישת קריאה בלבד לכל משאבי הקוד של sales.
כדי לתת גישה ציבורית למאגר Dataform, פועלים לפי השלבים הבאים:
במסוף, מעבירים את בקשת Dataform API
repositories.setIamPolicyעם מדיניות גישה.במדיניות, מקשרים את חשבון המשתמש
allAuthenticatedUsersלתפקיד שנבחר בפורמט הבא:{ "policy": { "bindings": [ { "role": "roles/ROLE", "members": [ "allAuthenticatedUsers", ] }, ], } }מחליפים את
ROLEבתפקיד IAM ב-Dataform שרוצים להעניק לכל המשתמשים המאומתים.
הפקודה הבאה מעבירה את הבקשה repositories.setIamPolicy Dataform API שמעניקה את התפקיד Dataform Viewer במאגר sales ל-allAuthenticatedUsers:
curl -H "Content-Type: application/json" -X POST -d '{ "policy": { "bindings": [{ "role": "roles/dataform.viewer", "members": ["allAuthenticatedUsers"]}] }}' "https://dataform.googleapis.com/v1/projects/examplepetstore/locations/us-central1/repositories/sales:setIamPolicy"
מניעת גישה ציבורית למאגרי קוד
כדי לוודא שלא ניתנת גישה לציבור לאף מאגר Dataform, אתם יכולים להגביל את העיקרון allAuthenticatedUsers בפרויקט.
כדי להגביל את השימוש ב-allAuthenticatedUsers בפרויקט, אפשר להגדיר את המדיניות בנושא iam.allowedPolicyMemberDomains ולהסיר את allAuthenticatedUsers מהרשימה של allowed_values.
כשמגבילים את allAuthenticatedUsers במדיניות iam.allowedPolicyMemberDomains, אי אפשר להשתמש בחשבון המשתמש allAuthenticatedUsers באף מדיניות IAM בפרויקט, וכך נמנעת הענקת גישה ציבורית לכל המשאבים, כולל מאגרי Dataform.
מידע נוסף על המדיניות iam.allowedPolicyMemberDomains והוראות להגדרתה זמין במאמר הגבלת זהויות לפי דומיין.
איחוד שירותי אימות הזהות של כוח העבודה ב-Dataform
איחוד שירותי אימות הזהות של כוח עבודה מאפשר להשתמש בספק זהויות חיצוני (IdP) כדי לאמת משתמשים ולהעניק להם הרשאה לגשת לשירותי Google Cloud באמצעות IAM.
Dataform תומך באיחוד שירותי אימות הזהות של כוח העבודה ללא מגבלות ידועות.
שליטה בגישה לטבלאות נפרדות באמצעות IAM
בקטע הזה מוסבר איך להעניק ולבטל תפקידי IAM ב-BigQuery לטבלאות ולתצוגות ספציפיות ב-Dataform.
כשמריצים טבלה או תצוגה ב-Dataform, המשאב נוצר ב-BigQuery. במהלך הפיתוח ב-Dataform, אפשר להקצות תפקידים ב-BigQuery לטבלאות ולתצוגות בודדות כדי לשלוט בגישה אליהן ב-BigQuery אחרי ההרצה.
מידע נוסף על הענקת גישה למשאבים וביטול הגישה אליהם זמין במאמר הענקת גישה למשאב.
הענקת תפקידים ב-BigQuery לטבלה או לתצוגה
אפשר להעניק תפקידים ב-BigQuery לטבלה או לתצוגה ב-Dataform על ידי הוספת בלוק post_operations עם הצהרת GRANT DCL לקובץ ההגדרה .sqlx של הטבלה או התצוגה שנבחרו.
כדי להעניק תפקידים ב-BigQuery לטבלה או לתצוגה שנבחרו, פועלים לפי השלבים הבאים:
נכנסים לדף Dataform במסוף Google Cloud .
בוחרים מאגר ואז בוחרים סביבת עבודה.
בחלונית Files, מרחיבים את הספרייה
definitions/.בוחרים את קובץ ההגדרה
.sqlxשל הטבלה או התצוגה שרוצים להעניק להם גישה.מזינים את קטע הקוד הבא בקובץ:
post_operations { GRANT "ROLE_LIST" ON "RESOURCE_TYPE" ${self()} TO "USER_LIST" }מחליפים את מה שכתוב בשדות הבאים:
ROLE_LIST: התפקיד ב-BigQuery או רשימת התפקידים ב-BigQuery שרוצים להעניק, מופרדים באמצעות פסיקים.
RESOURCE_TYPE:
TABLEאוVIEW.USER_LIST: רשימה מופרדת בפסיקים של המשתמשים שהתפקיד הוקצה להם.
רשימה של פורמטים תקינים מופיעה במאמר בנושא user_list.
אופציונלי: לוחצים על עיצוב.
מריצים את הטבלה או התצוגה.
אם הענקתם גישה לטבלה מצטברת, צריך להסיר את ההצהרה
GRANTמקובץ הגדרת הטבלה אחרי ההרצה הראשונה.
בדוגמת הקוד הבאה מוצג התפקיד BigQuery Viewer שהוענק למשתמש בטבלה:
config { type: "table" }
SELECT ...
post_operations {
GRANT `roles/bigquery.dataViewer`
ON TABLE ${self()}
TO "user:222larabrown@gmail.com"
}
ביטול תפקידים ב-BigQuery מטבלה או מתצוגה
כדי לבטל תפקידים ב-BigQuery מטבלה או מתצוגה, מוסיפים בלוק post_operations עם הצהרת DCL REVOKE לקובץ ההגדרה .sqlx של הטבלה או התצוגה שנבחרו.
כדי לבטל תפקידים ב-BigQuery מטבלה או מתצוגה שנבחרו, פועלים לפי השלבים הבאים:
נכנסים לדף Dataform במסוף Google Cloud .
בוחרים מאגר ואז בוחרים סביבת עבודה.
בחלונית Files, מרחיבים את הספרייה
definitions/.בוחרים את קובץ ההגדרה
.sqlxשל הטבלה או התצוגה שרוצים לבטל את הגישה אליהם.בבלוק
post_operations, מזינים את ההצהרהREVOKEהבאה:REVOKE "ROLE_LIST" ON "RESOURCE_TYPE" ${self()} FROM "USER_LIST"מחליפים את מה שכתוב בשדות הבאים:
- ROLE_LIST: התפקיד ב-BigQuery או רשימת התפקידים ב-BigQuery שמופרדים בפסיקים שרוצים לבטל.
- RESOURCE_TYPE:
TABLEאוVIEW. - USER_LIST: רשימה מופרדת בפסיקים של המשתמשים שהתפקיד בוטל עבורם. רשימה של פורמטים תקינים מופיעה במאמר בנושא user_list.
כדי לבטל את הגישה שניתנה בהצהרת
GRANTבקובץ, מחליפים את ההצהרהGRANTבהצהרהREVOKE.אופציונלי: לוחצים על עיצוב.
מריצים את הטבלה או התצוגה.
אם ביטלתם את הגישה לטבלה מצטברת, צריך להסיר את ההצהרה
REVOKEמקובץ הגדרת הטבלה אחרי ההרצה הראשונה.
בדוגמת הקוד הבאה מוצג ביטול של התפקיד BigQuery Viewer (צפייה ב-BigQuery) ממשתמש בטבלה:
config { type: "table" }
SELECT ...
post_operations {
REVOKE `roles/bigquery.dataViewer`
ON TABLE ${self()}
FROM "user:222larabrown@gmail.com"
}
ניהול משותף של תפקידים ב-BigQuery עבור טבלאות ותצוגות
כדי לשלוט בגישה ל-BigQuery לטבלאות ולתצוגות נפרדות במיקום יחיד, אפשר ליצור קובץ type: "operations" ייעודי עם הצהרות DCL של GRANT ושל REVOKE.
כדי לנהל את הגישה לטבלאות BigQuery בקובץ type: "operations"אחד, פועלים לפי השלבים הבאים:
נכנסים לדף Dataform במסוף Google Cloud .
בוחרים מאגר ואז בוחרים סביבת עבודה.
בחלונית קבצים, לצד
definitions/, לוחצים על התפריט
אפשרויות נוספות.לוחצים על יצירת קובץ.
בשדה הוספת נתיב קובץ, מזינים את שם הקובץ ואחריו את התו
.sqlxאחריdefinitions/. לדוגמה,definitions/table-access.sqlx.שמות הקבצים יכולים לכלול רק מספרים, אותיות, מקפים וקווים תחתונים.
לוחצים על יצירת קובץ.
בחלונית Files (קבצים), מרחיבים את הספרייה
definitions/ובוחרים את הקובץ החדש שנוצר.מזינים את קטע הקוד הבא בקובץ:
config { type: "operations" } GRANT "ROLE_LIST" ON RESOURCE_TYPE RESOURCE_NAME TO "USER_LIST" REVOKE "ROLE_LIST" ON { "<var>" }}RESOURCE_TYPE RESOURCE_NAME TO "USER_LIST"מחליפים את מה שכתוב בשדות הבאים:
- ROLE_LIST: התפקיד ב-BigQuery או רשימה של תפקידים ב-BigQuery שמופרדים בפסיקים שרוצים להעניק או לבטל.
- RESOURCE_TYPE:
TABLEאוVIEW. - RESOURCE_NAME: השם של הטבלה או התצוגה.
- USER_LIST: רשימה מופרדת בפסיקים של המשתמשים שהתפקיד מוקצה להם או מבוטל מהם. רשימה של פורמטים תקינים מופיעה במאמר בנושא user_list.
מוסיפים משפטי
GRANTו-REVOKEלפי הצורך.כדי לבטל את הגישה שניתנה בהצהרה
GRANTבקובץ, מחליפים את ההצהרהGRANTבהצהרהREVOKE.הסרת ההצהרה
GRANTבלי להוסיף את ההצהרהREVOKEלא מבטלת את הגישה.
אופציונלי: לוחצים על עיצוב.
מריצים את הקובץ אחרי כל עדכון.
- אם הענקתם או ביטלתם גישה בטבלה מצטברת, צריך להסיר את ההצהרה
GRANTאוREVOKEמהקובץ אחרי ההפעלה הראשונה של ההצהרה.
- אם הענקתם או ביטלתם גישה בטבלה מצטברת, צריך להסיר את ההצהרה
שימוש ב-Config API כדי להתאים אישית את ההתנהגות של IAM
אתם יכולים להשתמש ב-method projects.locations.updateConfig Dataform API כדי להתאים אישית את ההתנהגות של IAM ולשפר את האבטחה.
הקצאת תפקיד ספציפי כשיוצרים משאב
כשמגדירים את השדה setAuthenticatedUserAdmin לערך true בprojects.locations.repositories resource, Dataform מעניק באופן אוטומטי למשתמש שיוצר את המאגר את תפקיד האדמין ב-Dataform (roles/dataform.admin) במאגר הזה. בנוסף, Dataform מעניק לכל משתמש שיוצר סביבת עבודה במאגר הזה את תפקיד האדמין של Dataform בסביבת העבודה החדשה.
כדי לשנות את ההתנהגות הזו, אפשר להשתמש בשדה creator_role (תצוגה מקדימה) בשיטה projects.locations.updateConfig. אם setAuthenticatedUserAdmin הוא true ומגדירים את השדה creator_role עם תפקיד בהתאמה אישית, Dataform מעניק את התפקיד בהתאמה אישית במקום תפקיד ברירת המחדל dataform.admin.
הטמעה של הרשאות מתקדמות לתזמון
כדי לדרוש מהמשתמשים הרשאות מפורשות לתזמון של תהליכי עבודה ב-Dataform, צריך להגדיר את השדה enable_project_checks_for_scheduling לערך true ב-method projects.locations.updateConfig.
כשמפעילים את הבדיקות האלה לתזמון, המשתמש צריך את ההרשאות הבאות:
כדי ליצור הגדרה של תהליך עבודה:
- ההרשאה
dataform.workflowConfigs.createבפרויקט, שמוענקת על ידי התפקיד Code Scheduler (roles/dataform.codeScheduler). - ההרשאה
dataform.repositories.scheduleWorkflowבמאגר, שניתנת על ידי התפקיד Dataform Admin (roles/dataform.admin).
- ההרשאה
כדי ליצור הגדרת הפצה:
- ההרשאה
dataform.releaseConfigs.createבפרויקט, שמוענקת על ידי התפקיד Code Scheduler (roles/dataform.codeScheduler). - ההרשאה
dataform.repositories.scheduleReleaseבמאגר, שניתנת על ידי התפקיד Dataform Admin (roles/dataform.admin).
- ההרשאה
הפעלת סביבות עבודה פרטיות
כדי להגביל את הגישה לסביבת העבודה של Dataform כך שרק יוצר סביבת העבודה יוכל לקרוא ולכתוב קוד בסביבת העבודה הזו, צריך להגדיר את השדה enable_private_workspace לערך true בשיטה projects.locations.updateConfig.
ההגבלה הזו חלה גם על צפייה בארטיפקטים שנוצרו, כמו SQL מהודר, שגיאות הידור ויומני הרצה של הידורים או הפעלות של תהליכי עבודה בסביבת העבודה.
ההגדרה הזו מבטלת את התפקידים הרגילים ב-IAM שנותנים למשתמשים אחרים במאגר גישה לסביבת העבודה.
המאמרים הבאים
- מידע נוסף על IAM זמין במאמר סקירה כללית על IAM.
- מידע נוסף על ניהול הגישה למשאבים זמין במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים.
- מידע נוסף על המושגים המרכזיים של איחוד שירותי אימות הזהות של כוח עבודה זמין במאמר איחוד שירותי אימות הזהות של כוח עבודה.
- במאמר בקרת גישה באמצעות IAM יש מידע נוסף על תפקידים והרשאות של IAM ב-BigQuery.
- מידע נוסף על מתן הרשאות מפורטות למערכי נתונים ב-BigQuery זמין במאמר שליטה בגישה למערכי נתונים.