במסמך הזה מוסבר איך לבצע את הפעולות הבאות ב-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.
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 serviceusage.services.enable permission. If you
created the project, then you likely already have this permission through the
Owner role (roles/owner). Otherwise, you can get this permission through the
Service Usage Admin role (roles/serviceusage.serviceUsageAdmin).
Learn how to grant roles.
מתן הרשאות הגישה הנדרשות ל-Dataform
בקטע הזה מוסבר איך להקצות את התפקידים של ניהול הזהויות והרשאות הגישה (IAM) שסוכני השירות של Dataform וחשבונות השירות בהתאמה אישית צריכים כדי להריץ תהליכי עבודה ב-BigQuery.
מידע על חשבונות שירות בהתאמה אישית וסוכני שירות של Dataform
אתם יכולים להגדיר חשבונות שירות בהתאמה אישית כדי להריץ תהליכי עבודה בשמכם בדרכים הבאות:
- ברמת המאגר, כדי להריץ את כל תהליכי העבודה במאגר נתון.
- בנפרד לכל הגדרת תהליך עבודה.
כשיוצרים מאגר או הגדרת תהליך עבודה ב-Dataform, אפשר לבחור כל חשבון שירות שיש לכם בו הרשאות לפעול בשם החשבון. צריך להגדיר את ההרשאות הנדרשות לפעולה בשם אחר לכל חשבונות השירות שמשויכים למשאבי Dataform.
כשיוצרים את המאגר הראשון ב-Dataform, המערכת יוצרת באופן אוטומטי סוכן שירות. Dataform משתמש בסוכן השירות כדי לקיים אינטראקציה עם BigQuery בשמכם.
מזהה סוכן השירות של Dataform הוא בפורמט הבא:
service-PROJECT_NUMBER@gcp-sa-dataform.
מחליפים את PROJECT_NUMBER במזהה המספרי של הפרויקט ב-Google Cloud . מזהה הפרויקט של Google Cloud מופיע במרכז הבקרה במסוףGoogle Cloud . מידע נוסף זמין במאמר איתור השם, המספר והמזהה של הפרויקט.
התפקידים הנדרשים לסוכני שירות של Dataform, לחשבונות שירות בהתאמה אישית ולחשבונות Google
כדי להריץ תהליכי עבודה ב-BigQuery, סוכני השירות של Dataform, חשבונות שירות בהתאמה אישית ופרטי כניסה של משתמשים לחשבון Google שמשמש לאימות ב-Dataform צריכים את התפקידים הבאים של BigQuery ב-IAM:
- עריכת נתונים ב-BigQuery (
roles/bigquery.dataEditor) בפרויקטים שבהם נדרשת ל-Dataform גישת קריאה וכתיבה. בדרך כלל, הפרויקטים האלה כוללים את הפרויקט שמארח את המאגר של Dataform. - BigQuery Data Viewer (
roles/bigquery.dataViewer) בפרויקטים שבהם נדרשת ל-Dataform גישה לקריאה בלבד. - BigQuery Job User
(
roles/bigquery.jobUser) בפרויקט שמארח את המאגר של Dataform. - BigQuery Data Owner
(
roles/bigquery.dataOwner) אם רוצים לשלוח שאילתות למערכי נתונים ב-BigQuery. - תפקידים ב-BigQuery לבקרת גישה ברמת העמודה, אם רוצים להשתמש בתגי מדיניות ב-BigQuery.
בנוסף, מקצים לסוכן השירות של Dataform את התפקידים הבאים בחשבון השירות בפועל של הגדרת תהליך העבודה. התפקידים האלה נדרשים כדי שמצב act-as המחמיר יפעל.
- משתמש בחשבון שירות (
roles/iam.serviceAccountUser) - יצירת אסימונים בחשבון שירות
(
roles/iam.serviceAccountTokenCreator)
כדי להפעיל גרסאות אוטומטיות של מאגרים והרצות אוטומטיות של תהליכי עבודה, צריך לתת לסוכן השירות של Dataform את ההרשאה iam.serviceAccounts.actAs בחשבון השירות בפועל.
כדי להפעיל העשרת מטא-נתונים ב-Knowledge Catalog ושילוב של כרטיס מידע על איכות הנתונים, צריך להקצות את התפקיד Dataplex Catalog Editor (roles/dataplex.catalogEditor) בפרויקט או בקבוצת הרשומות @bigquery לחשבונות השירות בהתאמה אישית או לחשבונות Google שמשמשים להרצת תהליכי עבודה.
שיקולי אבטחה
כשמקצים את התפקידים שנדרשים ל-Dataform לסוכן שירות של Dataform, לחשבון שירות בהתאמה אישית או לחשבון Google של משתמש, צריך להביא בחשבון את שיקולי האבטחה הבאים:
כל חשבון שירות בהתאמה אישית שקיבל את התפקידים הנדרשים יכול לקבל גישה ל-BigQuery, ל-Secret Manager או ל-Knowledge Catalog בפרויקט שחשבון השירות שייך אליו, בלי קשר ל-VPC Service Controls. כש-Dataform משתמש בחשבון שירות בהתאמה אישית כדי להריץ תהליכי עבודה, הבקשות של Dataform מטופלות כאילו הן מגיעות מתוך גבולות הגזרה של VPC Service Controls בפרויקט שמכיל את המאגר. לכן, ב-VPC Service Controls לא נחסמת התקשורת בין Dataform לבין שירותים אחרים, כמו BigQuery, Secret Manager או Knowledge Catalog, אם המשאבים האלה נמצאים באותם גבולות גזרה לשירות.
לפרטים נוספים על ניהול גבולות האבטחה האלה, קראו את המאמר הגדרת 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, ולהפנות להגדרת גרסה עם לוח זמנים.
כדי לא לאפשר שימוש בפרטי הכניסה של משתמשי קצה בחשבון Google, Organization Administrator יכול ליצור אילוץ מותאם אישית של מדיניות הארגון שמונע את ההגדרה של
end_user_auth_config. מידע נוסף זמין במאמר יצירת אילוצים בהתאמה אישית של מדיניות הארגון.
הקצאת התפקידים הנדרשים ב-BigQuery
כדי להקצות את תפקידי ה-IAM הנדרשים ב-BigQuery לסוכן השירות של Dataform, לחשבון שירות בהתאמה אישית שבו אתם רוצים להשתמש ב-Dataform או לחשבון Google של משתמש שבו אתם רוצים להשתמש לאימות ב-Dataform, בצעו את השלבים הבאים:
נכנסים לדף 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, וברשימה Select a role בוחרים את התפקיד BigQuery Data Viewer.
לוחצים על Save.
הקצאת התפקידים שנדרשים לתהליכי עבודה אוטומטיים
כדי להשתמש בחשבון שירות בהתאמה אישית ב-Dataform, סוכן השירות של Dataform צריך להיות מסוגל לגשת לחשבון השירות בהתאמה אישית. כך Dataform יכול להריץ את תהליכי העבודה באמצעות ההרשאות שהוגדרו בחשבון השירות בהתאמה אישית, במקום בחשבון של סוכן השירות.
כדי לתת את הגישה הזו, צריך להקצות את התפקיד "יצירת אסימונים בחשבון שירות" (roles/iam.serviceAccountTokenCreator) לסוכן השירות של Dataform כחשבון המשתמש. כך סוכן השירות של Dataform יכול להתחזות לחשבון השירות על ידי יצירת פרטי כניסה לטווח קצר שנקראים אסימונים. האסימונים האלה נדרשים כדי ש-Dataform יריץ תהליכי עבודה באמצעות הזהות של חשבון השירות בהתאמה אישית.
צריך גם להקצות לסוכן השירות של Dataform את התפקיד "משתמש בחשבון שירות" (roles/iam.serviceAccountUser). כך סוכן השירות של 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.ברשימה Select a role, בוחרים את התפקידים Service Account Token Creator ו-Service Account User.
לוחצים על Save.
עכשיו חשבון השירות בהתאמה אישית מוכן להגדרה במאגר של Dataform.
בדיקת ההגדרות של חשבונות השירות
בקטע הזה מוסבר איך לבדוק את המשאבים של Dataform כדי לוודא שאתם משתמשים נכון בחשבון השירות ונותנים את ההרשאות המתאימות. הביקורת חשובה במיוחד כשמשתמשים בחשבונות שירות בהתאמה אישית, כי הם דורשים הרשאות ספציפיות כדי שסוכן השירות של Dataform יפעל.
כשמשתמשים בחשבון שירות בהתאמה אישית למאגר או להגדרת תהליך עבודה ב-Dataform, צריך לוודא שלסוכן השירות של Dataform יש את התפקיד "משתמש בחשבון שירות" (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 ולחפש ממצאים שקשורים לחשבונות שירות ולסוכני שירות עם הרשאות יתר.
במאמרים ממצאי המלצות של IAM ובדיקת ממצאי זהות במסוף מוסבר איך לבדוק וליישם ממצאי תיקון ב-Security Command Center.
כשמתקנים ממצא של 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 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 ואת היכולת לנהל מטא-נתונים ב-Knowledge Catalog.
מכיוון שמצב act-as מחמיר נאכף בכל המאגרים, ההרשאה dataform.repositories.create דורשת באופן משתמע שלמשתמש יהיו הרשאות act-as בחשבון השירות בהתאמה אישית, כדי להריץ תהליכי עבודה עוקבים. כך רק משתמשים עם זכויות התחזות מפורשות יכולים להריץ קוד באמצעות הזהות של חשבון השירות.
ההרשאה dataform.repositories.create כלולה בתפקידי ה-IAM הבאים:
- אדמין ב-BigQuery (
roles/bigquery.admin) - BigQuery Job User (
roles/bigquery.jobUser) (שימוש במשימות BigQuery) - BigQuery Studio User (
roles/bigquery.studioUser) - משתמש BigQuery (
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.
גישה לסודות במהלך התקנת חבילה
אם אתם מגדירים חבילות NPM פרטיות באמצעות סודות של Secret Manager, יכול להיות שמשתמשים עם הרשאות לשינוי קוד או להפעלת הידור של קוד מ-Git commit ספציפי במאגר יוכלו לגשת לסודות האלה.
במהלך התקנת החבילה – שמופעלת כשמתקינים חבילות באופן ידני בסביבת עבודה או כשמבצעים קומפילציה של קוד מ-Git commit ספציפי – לקוח ה-NPM קורא את פרטי הכניסה מהקובץ .npmrc ומעביר את אסימון האימות למרשם ה-NPM שהוגדר. משתמש עם הרשאות לשינוי הקובץ .npmrc בסביבת העבודה שלו יכול להגדיר את הגישה לסודות על ידי הפניית בקשות הרישום לשרת חיצוני.
ההתקנה הזו והחשיפה הפוטנציאלית של האסימון יכולות להתרחש בתרחישים הבאים:
התקנת חבילת Workspace: מופעלת באופן ידני בתוך סביבת עבודה. כדי לעשות את זה, צריך הרשאות עריכה של סביבת העבודה, שנמצאות בתפקידים עריכת Dataform (
roles/dataform.editor) או עריכת קוד ב-Dataform (roles/dataform.codeEditor).הידור של Git commitish: מופעל באופן אוטומטי כשיוצרים תוצאת הידור ל-Git commitish, כמו הסתעפות, תג או SHA של commit, במאגר. בתרחיש הזה נדרשת ההרשאה
dataform.compilationResults.create.
כדי לאבטח את פרטי הכניסה, מומלץ לבצע את הפעולות הבאות:
הקצו תפקידים עם הרשאות עריכה של מאגרים (כמו Dataform Code Editor) או הרשאות קומפילציה (כמו Dataform Code Viewer) רק למשתמשים מהימנים.
להגביל את מאגרי Git המרוחקים ש-Dataform יכול להתחבר אליהם באמצעות כללי מדיניות של הארגון. מידע נוסף זמין במאמר הגבלת מאגרים מרוחקים.
הגבילו את הגישה של סוכן השירות של Dataform ל-Secret Manager רק לסודות הנדרשים.
כדי למנוע שימוש בפרטי הכניסה של משתמשי הקצה, אפשר להשתמש באילוצים של מדיניות הארגון בהתאמה אישית שדוחים את ההגדרה
end_user_auth_config. מידע נוסף זמין במאמר יצירת אילוצים בהתאמה אישית של מדיניות הארגון.
הצגת התפקידים ב-Dataform
במסוף Google Cloud :
נכנסים לדף IAM & Admin > Roles.
בשדה Filter, בוחרים באפשרות Used in, מקלידים
Dataformולוחצים על Enter.לוחצים על אחד מהתפקידים שברשימה כדי לראות את ההרשאות שלו בחלונית השמאלית.
לדוגמה, לתפקיד "אדמין ב-Dataform" יש גישה מלאה לכל המשאבים ב-Dataform.
איך נותנים תפקיד בפרויקט כך אפשר להקצות תפקידים מוגדרים מראש או תפקידים בהתאמה אישית.
שליטה בגישה למאגר ספציפי
כדי לשלוט בגישה ל-Dataform באמצעות הרשאות מפורטות, אתם יכולים להגדיר תפקידי IAM של Dataform במאגרים ספציפיים באמצעות בקשת repositories.setIamPolicy ב-Dataform API.
כדי להגדיר תפקידי IAM של Dataform במאגר ספציפי של Dataform:
במסוף, מעבירים את בקשת ה-API של Dataform
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" בכל המאגרים.
הפקודה הבאה מעבירה את בקשת ה-API של repositories.setIamPolicy ב-Dataform, שמעניקה את התפקיד "עריכה ב-Dataform" במאגר 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:
במסוף, מעבירים את בקשת ה-API של Dataform
repositories.setIamPolicyעם מדיניות גישה.במדיניות, מקשרים את חשבון המשתמש
allAuthenticatedUsersלתפקיד שנבחר בפורמט הבא:{ "policy": { "bindings": [ { "role": "roles/ROLE", "members": [ "allAuthenticatedUsers", ] }, ], } }מחליפים את
ROLEבתפקיד IAM ב-Dataform שרוצים להקצות לכל המשתמשים המאומתים.
הפקודה הבאה מעבירה את בקשת ה-API של repositories.setIamPolicy Dataform, שמעניקה את התפקיד "צפייה ב-Dataform" במאגר 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 עם הצהרת DCL של GRANT לקובץ ההגדרה .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" שניתן למשתמש בטבלה:
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" של משתמש בטבלה:
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 .
בוחרים מאגר ואז בוחרים סביבת עבודה.
בחלונית Files, ליד
definitions/, לוחצים על תפריט האפשרויות הנוספות
More.לוחצים על יצירת קובץ.
בשדה Add a file path, מזינים את שם הקובץ ואחריו את
.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מהקובץ אחרי ההפעלה הראשונה של ההצהרה.
- אם נתתם או ביטלתם גישה בטבלה מצטברת, הסירו את ההצהרה
שימוש ב-API של Config כדי להתאים אישית את ההתנהגות של IAM
אתם יכולים להשתמש בשיטה projects.locations.updateConfig של Dataform API כדי להתאים אישית את ההתנהגות של IAM ולשפר את האבטחה.
הקצאת תפקיד ספציפי בזמן יצירת המשאב
כשמגדירים את השדה setAuthenticatedUserAdmin לערך true במשאב projects.locations.repositories, Dataform מקצה באופן אוטומטי למשתמש שיוצר את המאגר את התפקיד אדמין ב-Dataform (roles/dataform.admin) במאגר הזה. בנוסף, Dataform מעניק לכל משתמש שיוצר סביבת עבודה במאגר הזה את התפקיד "אדמין ב-Dataform" בסביבת העבודה החדשה.
כדי לשנות את ההתנהגות הזו, אתם יכולים להשתמש בשדה creator_role (גרסת טרום-השקה (Preview)) בשיטה projects.locations.updateConfig. אם הערך של setAuthenticatedUserAdmin הוא true ומגדירים את השדה creator_role עם תפקיד בהתאמה אישית, Dataform מקצה את התפקיד בהתאמה אישית במקום את תפקיד ברירת המחדל dataform.admin.
הטמעת הרשאות תזמון משופרות
כדי לדרוש שלמשתמשים יהיו הרשאות מפורשות לתזמון תהליכי עבודה ב-Dataform, מגדירים את השדה enable_project_checks_for_scheduling לערך true בשיטה projects.locations.updateConfig.
כשמפעילים את הבדיקות האלה לתזמון, המשתמש צריך את ההרשאות הבאות:
כדי ליצור הגדרת תהליך עבודה:
- ההרשאה
dataform.workflowConfigs.createבפרויקט, שניתנת באמצעות התפקיד "תזמון קוד" (roles/dataform.codeScheduler). - ההרשאה
dataform.repositories.scheduleWorkflowבמאגר, שניתנת על ידי התפקיד "אדמין ב-Dataform" (roles/dataform.admin).
- ההרשאה
כדי ליצור הגדרות לגרסה:
- ההרשאה
dataform.releaseConfigs.createבפרויקט, שניתנת באמצעות התפקיד "תזמון קוד" (roles/dataform.codeScheduler). - ההרשאה
dataform.repositories.scheduleReleaseבמאגר, שניתנת על ידי התפקיד "אדמין ב-Dataform" (roles/dataform.admin).
- ההרשאה
הפעלת סביבות עבודה פרטיות
כדי להגביל את הגישה לסביבת העבודה ב-Dataform כך שרק מי שיצר את סביבת העבודה יוכל לקרוא ולכתוב קוד בסביבת העבודה הזו, מגדירים את השדה enable_private_workspace לערך true ב-method projects.locations.updateConfig.
ההגבלה הזו חלה גם על הצגת פריטי מידע שנוצרו, כמו SQL שעבר קומפילציה, שגיאות קומפילציה ויומני הרצה של קומפילציות או הפעלות של תהליכי עבודה בסביבת העבודה.
ההגדרה הזו מבטלת את תפקידי ה-IAM הרגילים שנותנים גישה לסביבת העבודה למשתמשים אחרים במאגר.
המאמרים הבאים
- לסקירה כללית על IAM
- איך מנהלים את הגישה לפרויקטים, לתיקיות ולארגונים
- מידע נוסף על המושגים המרכזיים של איחוד שירותי אימות הזהות של כוח עבודה, אפשר לקרוא במאמר איחוד שירותי אימות הזהות של כוח עבודה.
- במאמר בקרת גישה באמצעות IAM תוכלו לקרוא מידע נוסף על התפקידים וההרשאות של IAM ב-BigQuery.
- במאמר שליטה בגישה למערכי נתונים מוסבר איך נותנים הרשאות ספציפיות למערכי נתונים ב-BigQuery.