במאמר הזה מוסבר איך לבצע אימות ב-Pub/Sub באופן פרוגרמטי. האופן שבו מבצעים אימות ב-Pub/Sub משתנה לפי הממשק שמשמש לגישה ל-API ולסביבה שבה הקוד פועל.
הערה: Pub/Sub לא תומך במפתחות API כשיטת אימות.למידע נוסף על אימות ב- Cloud de Confiance אתם יכולים לעיין בשיטות האימות.
גישה באמצעות ממשק API
ב-Pub/Sub יש תמיכה בגישה פרוגרמטית. הגישה ל-API אפשרית בדרכים הבאות:
ספריות לקוח
ספריות הלקוח של Pub/Sub מספקות שפות תמיכה ברמה גבוהה לצורך אימות פרוגרמטי ב-Pub/Sub. כדי לאמת קריאות לממשקי ה-API של Cloud de Confiance by S3NS , ספריות הלקוח תומכות ב-Application Default Credentials (ADC). בספריות מתבצע חיפוש של פרטי כניסה בקבוצה של מיקומים מוגדרים, והמערכת משתמשת בפרטי הכניסה האלה כדי לאמת בקשות ל-API. בעזרת ADC, פרטי הכניסה לאפליקציה יכולים להיות זמינים בסביבות שונות, כמו בפיתוח מקומי או בייצור, גם בלי לשנות את קוד האפליקציה.
Google Cloud CLI
כשמשתמשים ב-CLI של gcloud כדי להיכנס ל-Pub/Sub, מתחברים ל-CLI של gcloud באמצעות חשבון משתמש שמספק את פרטי הכניסה שבהם משתמשות פקודות ה-CLI של gcloud.
אם מדיניות האבטחה של הארגון לא מאפשרת הקצאה של ההרשאות הנדרשות לחשבונות משתמשים, תוכלו להשתמש בתכונה התחזות לחשבון שירות.
למידע נוסף, תוכלו לקרוא על אימות לשימוש ב-CLI של gcloud. למידע נוסף על השימוש ב-CLI של gcloud עם Pub/Sub, אפשר לעיין בדפי העזר של gcloud CLI.
REST
אתם יכולים לאמת את Pub/Sub API באמצעות פרטי הכניסה ל-CLI של gcloud, או באמצעות Application Default Credentials. למידע נוסף על אימות של בקשות REST, אפשר לעיין במאמר אימות לשימוש ב-REST. למידע נוסף על הסוגים השונים של פרטי כניסה, אפשר לעיין במאמר פרטי כניסה ל-CLI של gcloud ו-ADC.
פרטי כניסה של משתמשים ו-ADC ל-Pub/Sub
אחת מהדרכים לספק פרטי כניסה ל-ADC היא באמצעות CLI של gcloud, כדי להזין את פרטי הכניסה לקובץ של פרטי כניסה. הקובץ מאוחסן במערכת הקבצים המקומית, ושם מערכת ADC יכולה למצוא אותו. לאחר מכן, מערכת ADC משתמשת בפרטי הכניסה שסופקו כדי לאמת בקשות. השיטה הזו נפוצה מאוד בפיתוח מקומי.
אם בחרתם להשתמש בשיטה הזו, יכול להיות שתקבלו שגיאת אימות כשתנסו לבצע אימות ב-Pub/Sub. כדי לדעת יותר על השגיאה ואיך מטפלים בה, ראו פרטי הכניסה של משתמשים לא פועלים.
הגדרת אימות ל-Pub/Sub
הגדרת האימות משתנה בהתאם לסביבה שבה הקוד פועל.
האפשרויות הבאות הן הנפוצות ביותר להגדרת אימות. למידע נוסף על אימות ואפשרויות אימות נוספות, ראו שיטות אימות.
לסביבת פיתוח מקומית
אפשר להגדיר פרטי כניסה לסביבת פיתוח מקומית בדרכים הבאות:
- פרטי כניסה של משתמשים בספריות לקוח או בכלים של צד שלישי
- פרטי כניסה של משתמשים בבקשות REST משורת הפקודה
- התחזות לחשבון שירות
ספריות לקוח או כלים של צד שלישי
מגדירים את Application Default Credentials (ADC) בסביבה המקומית:
-
התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם. אחרי שנכנסתם לחשבון, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:
gcloud init -
יוצרים פרטי כניסה לאימות מקומי עבור חשבון המשתמש:
gcloud auth application-default login
אם מוחזרת שגיאת אימות ואתם משתמשים בספק זהויות חיצוני (IdP), ודאו ש נכנסתם ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
מסך הכניסה יופיע. אחרי שנכנסים, פרטי הכניסה נשמרים בקובץ פרטי הכניסה המקומי שמשמש את ADC.
למידע נוסף על עבודה עם ADC בסביבה מקומית תוכלו לעיין במאמר הגדרת ADC לסביבת פיתוח מקומית.
הפעלת בקשות REST משורת הפקודה
כשמפעילים בקשת REST משורת הפקודה, אפשר להשתמש בפרטי הכניסה ל-CLI של gcloud. כדי לעשות את זה, מוסיפים את gcloud auth print-access-token כחלק מהפקודה ששולחת את הבקשה.
הדוגמה הבאה מפרטת את חשבונות השירות של הפרויקט שצוין. אפשר להשתמש באותו דפוס בכל בקשה ל-REST.
לפני שמשתמשים בנתוני הבקשה צריך להחליף את הנתונים האלה:
- PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance .
כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות האלה:
למידע נוסף על אימות באמצעות 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
Cloud de Confiance by S3NSמופעל
כדי לאמת עומס עבודה שפועל ב- Cloud de Confiance, צריך להשתמש בפרטי הכניסה של חשבון השירות שמקושר למשאב המחשוב שבו הקוד פועל. למשל, מכונה וירטואלית (VM) של Compute Engine. זאת שיטת האימות המועדפת לקוד שפועל במשאב מחשוב של Cloud de Confiance .
ברוב השירותים צריך לקשר את חשבון השירות בזמן שיוצרים את המשאב שמפעיל את הקוד. אי אפשר להוסיף או להחליף את חשבון השירות מאוחר יותר. Compute Engine הוא יוצא מן הכלל, ומאפשר לקשר חשבון שירות למכונה וירטואלית בכל שלב.
אפשר להשתמש ב-CLI של gcloud כדי ליצור חשבון שירות ולקשר אותו למשאב:
-
התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם. אחרי שנכנסתם לחשבון, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:
gcloud init -
מגדירים את האימות:
-
מוודאים שיש לכם את תפקיד ה-IAM Create Service Accounts (
roles/iam.serviceAccountCreator) ואת תפקיד ה-IAM Project Admin (roles/resourcemanager.projectIamAdmin). איך מקצים תפקידים -
יוצרים את חשבון השירות:
gcloud iam service-accounts create SERVICE_ACCOUNT_NAME
מחליפים את הערך
SERVICE_ACCOUNT_NAMEבשם שרוצים לתת לחשבון השירות. -
כדי לתת גישה לפרויקט ולמשאבים, מקצים תפקיד לחשבון השירות:
gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com" --role=ROLE
מחליפים את מה שכתוב בשדות הבאים:
SERVICE_ACCOUNT_NAME: השם של חשבון השירותPROJECT_ID: מזהה הפרויקט שבו יצרתם את חשבון השירותROLE: התפקיד שאתם רוצים לתת
- כדי להקצות תפקיד נוסף לחשבון השירות, מריצים שוב את הפקודה שמו שעשיתם בשלב הקודם.
-
מקצים את התפקיד הנדרש לחשבון המשתמש שיצרף את חשבון השירות למשאבים אחרים.
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com --member="principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ID" --role=roles/iam.serviceAccountUser
מחליפים את מה שכתוב בשדות הבאים:
-
SERVICE_ACCOUNT_NAME: השם של חשבון השירות. PROJECT_ID: מזהה הפרויקט שבו יצרתם את חשבון השירות.-
POOL_ID: מזהה מאגר הזהויות של כוח העבודה. -
SUBJECT_ID: מזהה נושא. בדרך כלל זה המזהה של משתמש במאגר זהויות של כוח עבודה. לפרטים נוספים, קראו את המאמר ייצוג המשתמשים במאגרי כוח עבודה בכללי מדיניות IAM.
-
-
מוודאים שיש לכם את תפקיד ה-IAM Create Service Accounts (
-
יוצרים את המשאב שיפעיל את הקוד ומקשרים אליו את חשבון השירות. לדוגמה, אם משתמשים ב-Compute Engine:
יוצרים מכונה של Compute Engine. מגדירים את המכונה באופן הבא:-
מחליפים את הערך
INSTANCE_NAMEבשם המכונה המועדף. -
מגדירים את הדגל
--zoneלתחום (zone) שבו רוצים ליצור את המכונה. -
מגדירים את הדגל
--service-accountלכתובת האימייל של חשבון השירות שיצרתם.
gcloud compute instances create INSTANCE_NAME --zone=ZONE --service-account=SERVICE_ACCOUNT_EMAIL
-
מחליפים את הערך
למידע נוסף על אימות של ממשקי Google API, ראו שיטות אימות.
בארגון או אצל ספק אחר של שירותי ענן
השיטה המועדפת להגדרת אימות מחוץ ל- Cloud de Confiance היא שימוש באיחוד זהויות של עומסי עבודה. למידע נוסף אפשר לעיין במאמר הגדרת ADC לספק שירותי ענן מקומי או אחר במסמכי האימות.
בקרת גישה ב-Pub/Sub
אחרי שאתם מבצעים אימות ב-Pub/Sub, צריכה להיות לכם הרשאה לגשת למשאבים של Cloud de Confiance . Pub/Sub משתמש בניהול זהויות והרשאות גישה (IAM) לצורך אימות.
מידע נוסף על התפקידים ב-Pub/Sub מופיע במאמר בקרת גישה באמצעות IAM. לפרטים נוספים על ניהול זהויות והרשאות גישה (IAM) ועל אימות, קראו את הסקירה הכללית על IAM.
המאמרים הבאים
- מידע נוסף על היקפי הרשאות של OAuth 2.0 ב-Pub/Sub
- מידע על שיטות האימות ב-Cloud de Confiance
- כאן יש רשימה של תרחישי אימות לדוגמה.