אימות ב-Dataflow

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

‫Dataflow משתמש במודל אימות רב-שכבתי שכולל את חשבון המשתמש, את סוכן השירות של Dataflow ואת חשבון השירות של העובד.

למידע נוסף על אימות ב- Google Cloud אתם יכולים לעיין בשיטות האימות.

גישה באמצעות ממשק API

ב-Dataflow יש תמיכה בגישה פרוגרמטית. הגישה ל-API אפשרית בדרכים הבאות:

• ספריות לקוח
• Google Cloud CLI
• REST

ספריות לקוח

ממשקי ה-API וההפניות מספקים תמיכה בשפות ברמה גבוהה לצורך אימות פרוגרמטי ב-Dataflow. כדי לאמת קריאות לממשקי Google Cloud Platform API, ספריות הלקוח תומכות ב-Application Default Credentials ‏ (ADC). בספריות מתבצע חיפוש של פרטי כניסה בקבוצה של מיקומים מוגדרים, והמערכת משתמשת בפרטי הכניסה האלה כדי לאמת בקשות ל-API. בעזרת ADC, פרטי הכניסה לאפליקציה יכולים להיות זמינים בסביבות שונות, כמו בפיתוח מקומי או בייצור, בלי שיהיה צריך לשנות את קוד האפליקציה.

Google Cloud CLI

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

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

למידע נוסף, תוכלו לקרוא על אימות לשימוש ב-CLI של gcloud. למידע נוסף על השימוש ב-CLI של gcloud עם Dataflow, אפשר לעיין בדפי העזר של gcloud CLI בנושא Dataflow.

REST

אתם יכולים לאמת את Dataflow API באמצעות פרטי הכניסה ל-CLI של gcloud, או באמצעות Application Default Credentials. למידע נוסף על אימות של בקשות REST, אפשר לעיין במאמר אימות לשימוש ב-REST. למידע נוסף על הסוגים השונים של פרטי כניסה, אפשר לעיין במאמר פרטי כניסה ל-CLI של gcloud ו-ADC.

פרטי כניסה של משתמשים ו-ADC ל-Dataflow

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

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

הגדרת אימות ל-Dataflow

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

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

לסביבת פיתוח מקומית

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

• פרטי כניסה של משתמשים בספריות לקוח או בכלים של צד שלישי
• פרטי כניסה של משתמשים בבקשות REST משורת הפקודה
• התחזות לחשבון שירות

ספריות לקוח או כלים של צד שלישי

מגדירים את Application Default Credentials (ADC) בסביבה המקומית:

1. Install the Google Cloud CLI. After installation, initialize the Google Cloud CLI by running the following command:

   gcloud init

   If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

2. If you're using a local shell, then create local authentication credentials for your user account:

   gcloud auth application-default login

   You don't need to do this if you're using Cloud Shell.

   Note: If the gcloud CLI prints a warning that your account doesn't have the serviceusage.services.use permission, then some gcloud CLI commands and client libraries might not work. Ask an administrator to grant you the Service Usage Consumer IAM role (roles/serviceusage.serviceUsageConsumer), then run the following command:

   gcloud auth application-default set-quota-project PROJECT_ID

   If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

   מסך הכניסה יופיע. אחרי שנכנסים, פרטי הכניסה נשמרים בקובץ פרטי הכניסה המקומי שמשמש את ADC.

למידע נוסף על עבודה עם ADC בסביבה מקומית תוכלו לעיין במאמר הגדרת ADC לסביבת פיתוח מקומית.

הפעלת בקשות REST משורת הפקודה

כשמפעילים בקשת REST משורת הפקודה, אפשר להשתמש בפרטי הכניסה ל-CLI של gcloud. כדי לעשות את זה, מוסיפים את gcloud auth print-access-token כחלק מהפקודה ששולחת את הבקשה.

הדוגמה הבאה מפרטת את חשבונות השירות של הפרויקט שצוין. אפשר להשתמש באותו דפוס בכל בקשה ל-REST.

לפני שמשתמשים בנתוני הבקשה צריך להחליף את הנתונים האלה:

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות האלה:

‏Curl (Linux,‏ macOS או Cloud Shell)

מריצים את הפקודה הבאה:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "x-goog-user-project: PROJECT_ID" \
     "https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts"

‎PowerShell (Windows)

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred"; "x-goog-user-project" = "PROJECT_ID" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts" | Select-Object -Expand Content

 

למידע נוסף על אימות באמצעות REST ו-gRPC, ראו אימות לשימוש ב-REST. למידע על ההבדל בין פרטי הכניסה המקומיים של ADC לפרטי הכניסה ל-CLI של gcloud, תוכלו לעיין במאמר הגדרת אימות ב-CLI של gcloud והגדרת ADC.

התחזות לחשבון שירות

ברוב המקרים תוכלו להשתמש בפרטי הכניסה שלכם כדי לבצע אימות בסביבת פיתוח מקומית. אם זה לא אפשרי, או אם אתם צריכים לבדוק את ההרשאות שהוקצו לחשבון שירות, תוכלו להתחזות לחשבון שירות. אתם צריכים את ההרשאה iam.serviceAccounts.getAccessToken, שכלולה בתפקיד Service Account Token Creator ‏(roles/iam.serviceAccountTokenCreator) ב-IAM.

אתם יכולים להגדיר את ה-CLI של gcloud כך שיתחזה לחשבון שירות באמצעות הפקודה gcloud config set:

gcloud config set auth/impersonate_service_account SERVICE_ACCT_EMAIL

בחלק מהשפות אפשר להתחזות לחשבון שירות כדי ליצור קובץ ADC מקומי שישמש את ספריות הלקוח של Go, ‏ Java, ‏ Node.js ו-Python (אבל לא שפות תכנות אחרות). כדי להגדיר קובץ ADC מקומי עם התחזות לחשבון שירות, משתמשים בדגל --impersonate-service-account עם הפקודה gcloud auth application-default login:

gcloud auth application-default login --impersonate-service-account=SERVICE_ACCT_EMAIL

איך מתחזים לחשבון שירות?

ב-Google Cloud Platform

כדי לאמת עומס עבודה שפועל ב- Google Cloud, צריך להשתמש בפרטי הכניסה של חשבון השירות שמקושר למשאב המחשוב שבו הקוד פועל. למשל, מכונה וירטואלית (VM) של Compute Engine. זאת שיטת האימות המועדפת לקוד שפועל במשאב מחשוב של Google Cloud .

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

אפשר להשתמש ב-CLI של gcloud כדי ליצור חשבון שירות ולקשר אותו למשאב:

1. התקינו את ה-CLI של Google Cloud. אחר כך, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:

   gcloud init

   אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

2. Set up authentication:

   1. Ensure that you have the Create Service Accounts IAM role (roles/iam.serviceAccountCreator) and the Project IAM Admin role (roles/resourcemanager.projectIamAdmin). Learn how to grant roles.

   2. Create the service account:

      gcloud iam service-accounts create SERVICE_ACCOUNT_NAME

      Replace SERVICE_ACCOUNT_NAME with a name for the service account.

   3. To provide access to your project and your resources, grant a role to the service account:

      gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com" --role=ROLE

      Replace the following:

      • SERVICE_ACCOUNT_NAME: the name of the service account
      • PROJECT_ID: the project ID where you created the service account
      • ROLE: the role to grant
      Note: The --role flag affects which resources the service account can access in your project. You can revoke these roles or grant additional roles later. In production environments, do not grant the Owner, Editor, or Viewer roles. Instead, grant a predefined role or custom role that meets your needs.
   4. To grant another role to the service account, run the command as you did in the previous step.

   5. Grant the required role to the principal that will attach the service account to other resources.

      gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com --member="user:USER_EMAIL" --role=roles/iam.serviceAccountUser

      Replace the following:

      • SERVICE_ACCOUNT_NAME: the name of the service account
      • PROJECT_ID: the project ID where you created the service account
      • USER_EMAIL: the email address for a Google Account

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

   Create a Compute Engine instance. Configure the instance as follows:
   • מחליפים את הערך INSTANCE_NAME בשם המכונה המועדף.
   • מגדירים את הדגל --zone לתחום (zone) שבו רוצים ליצור את המכונה.
   • מגדירים את הדגל --service-account לכתובת האימייל של חשבון השירות שיצרתם.

   gcloud compute instances create INSTANCE_NAME --zone=ZONE --service-account=SERVICE_ACCOUNT_EMAIL

אפשר לקרוא מידע נוסף על אימות של ממשקי Google API במאמר בנושא שיטות אימות.

בארגון או אצל ספק אחר של שירותי ענן

השיטה המועדפת להגדרת אימות מחוץ ל- Google Cloud היא שימוש באיחוד זהויות של עומסי עבודה. למידע נוסף אפשר לעיין במאמר הגדרת ADC לספק שירותי ענן מקומי או אחר במסמכי האימות.

בקרת גישה ל-Dataflow

אחרי שאתם מבצעים אימות ב-Dataflow, צריכה להיות לכם הרשאה לגשת למשאבים של Google Cloud . ‫Dataflow משתמש בניהול זהויות והרשאות גישה (IAM) לצורך אימות.

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

מודל אימות של Dataflow

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

שכבות אימות

• אימות API: אתם מאמתים את ממשקי Dataflow API ‏(REST, ספריות לקוח או Google Cloud CLI) באמצעות פרטי הכניסה של המשתמש או חשבון שירות.
• שליחת משימה: כדי להריץ משימה, צריכות להיות לכם הרשאות IAM שנדרשות להפעלת רץ, ואם אתם משתמשים בחשבון שירות בניהול המשתמש, צריכה להיות לכם הרשאה להתחזות לחשבון הזה.
• אימות של עובדים: בזמן שהעבודה פועלת, העובדים של Dataflow משתמשים בזהות של חשבון שירות כדי לקרוא ולכתוב בשירותים אחרים של Google Cloud , כמו Cloud Storage או BigQuery.
• הרצה מקומית: כשמשתמשים ב-Direct Runner כדי להריץ עבודה באופן מקומי, צינור הנתונים משתמש בפרטי הכניסה שלכם ב-CLI של gcloud.

עקרונות מרכזיים

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

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

• הגדרת אבטחה והרשאות לצינורות ב-Google Cloud Platform.
• ההרשאה הדרושה כדי לצרף חשבונות שירות
• מידע על שיטות האימות ב-Google Cloud
• כאן יש רשימה של תרחישי אימות לדוגמה.