אימות בחיוב ב-Cloud

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

למידע נוסף על אימות ב-Google Cloud, תוכלו לעיין בסקירה הכללית על אימות.

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

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

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

ספריות לקוח

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

Google Cloud CLI

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

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

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

REST

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

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

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

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

הגדרת האימות לחיוב ב-Cloud

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

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

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

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

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

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

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

1. Install the Google Cloud CLI, then initialize it by running the following command:

   gcloud init

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

   מסך הכניסה יופיע. אחרי שנכנסים, פרטי הכניסה נשמרים בקובץ פרטי הכניסה המקומי שמשמש את 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.

ב-Google Cloud

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

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

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

1. Install the Google Cloud CLI, then initialize it by running the following command:

   gcloud init

2. Set up authentication:

   1. Create the service account:

      gcloud iam service-accounts create SERVICE_ACCOUNT_NAME

      Replace SERVICE_ACCOUNT_NAME with a name for the service account.

   2. 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.
   3. To grant another role to the service account, run the command as you did in the previous step.

   4. 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:
   • Replace INSTANCE_NAME with your preferred instance name.
   • Set the --zone flag to the zone in which you want to create your instance.
   • Set the --service-account flag to the email address for the service account that you created.

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

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

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

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

בקרת הגישה לחיוב ב-Cloud

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

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

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

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