במדריך הזה מוסבר איך להגדיר את Bring Your Own Identity (BYOID) ל-Multi-party Compute API באמצעות איחוד שירותי אימות הזהות של כוח עבודה ואיחוד שירותי אימות הזהות של עומסי עבודה. בעזרת איחוד שירותי אימות הזהות, משתמשים אנושיים ועומסי עבודה של חתימה אוטומטית יכולים לאמת את הזהות שלהם בחישוב רב-משתתפים באמצעות ספק הזהויות (IdP) החיצוני של הארגון, כמו Okta, Microsoft Entra ID או Ping Identity. אתם לא צריכים ליצור חשבונות Google או לנהל מפתחות של חשבונות שירות לטווח ארוך.
סקירה כללית
איחוד שירותי אימות הזהות משתלב עם מודל האבטחה "הגנה לעומק" של חישוב רב-משתתפים בשכבות הבאות:
- הרשאה של ניהול זהויות והרשאות גישה (IAM) ב-Edge: הגורמים שמבצעים את הקריאה מחליפים את פרטי הכניסה מספק זהויות (IdP) חיצוני של OpenID Connect (OIDC) או SAML 2.0 ב- Google Cloud Security Token Service (Security Token Service) כדי לקבל אסימון גישה מאוחד לטווח קצר. שער ה-API של Google Cloud בודק את הקישורים לתפקידי IAM מול ה-URI של החשבון המאומת לפני שהוא מעביר את הבקשות למכונה של החישוב הרב-משתתפים, ומפיץ את הזהות המאוחדת (
principalSubject) ליומני הביקורת של Cloud. - הפרדת תפקידים ואישור קריפטוגרפי: תפקידי IAM מפרידים בין הקצאת הרשאות ניהול (
roles/mpc.admin), השתתפות תפעולית (roles/mpc.editor) ופיקוח לקריאה בלבד (roles/mpc.viewer). בתוך המכונה, אדמינים, כותבי מדיניות וחותמים צריכים גם משתמש שהמכונה בודקת את התפקיד שלו (ADMIN,POLICY_AUTHORאוSIGNER) כדי למצוא שיטות שפועלות בשם המשתמש, והאישורים חייבים להיחתם באמצעות מפתח ההרשאה שרשום אצל אותו משתמש. מידע נוסף זמין במאמר איך בקשה מקבלת הרשאה.
בהתאם לסוג הגורם שמבצע את הקריאה, אתם יכולים להשתמש בשני מנגנונים של איחוד שירותי אימות הזהות:
- איחוד שירותי אימות הזהות של כוח עבודה (
locations/global/workforcePools/...): מאמת משתמשים אנושיים (אדמינים, כותבי מדיניות, חותמים וצוות תאימות) באמצעות מאגרי כוח עבודה ברמת הארגון שממופים ל-IdP של הארגון. במדריך הזה מוסבר איך להגדיר את איחוד שירותי אימות הזהות של כוח העבודה מקצה לקצה. - איחוד שירותי אימות הזהות של עומסי עבודה (
projects/.../locations/global/workloadIdentityPools/...): מאמת עומסי עבודה אוטומטיים (כמו תהליכי רקע של חתימה משותפת ללא ממשק משתמש שפועלים ב-AWS, ב-Azure או ב-Kubernetes) באמצעות מאגרי זהויות של עומסי עבודה ברמת הפרויקט.
במאמר אבטחה והרשאה מוסבר איך התפקידים ב-IAM ממופים לפרסונות של חישוב רב-משתתפים.
לפני שמתחילים
לפני שמתחילים, חשוב לוודא שהתנאים הבאים מתקיימים:
- Google Cloud ארגון ופרויקט צרכן שהוגדרו לחישוב רב-משתתפים.
- התקנה של ה-CLI של
gcloudושלjq, ואימות שלgcloudבאמצעות חשבון אדמין עם התפקידים הבאים:- אדמין של מאגר כוח עבודה (
roles/iam.workforcePoolAdmin) בארגון ב- Google Cloud (אם יוצרים מאגר כוח עבודה חדש בשלב 1). - אדמין IAM של פרויקט (
roles/resourcemanager.projectIamAdmin) ואדמין של שימוש בשירות (roles/serviceusage.serviceUsageAdmin) בפרויקט הצרכן.
- אדמין של מאגר כוח עבודה (
ממשקי ה-API הנדרשים שמופעלים בפרויקט של הצרכן:
gcloud services enable mpc.googleapis.com iam.googleapis.com sts.googleapis.com \ --project="my-project"אפליקציית OIDC או SAML 2.0 חיצונית שמוגדרת ב-IdP של הארגון. אם אתם מתכננים להשתמש בכניסה אינטראקטיבית לדפדפן באמצעות ה-CLI של
gcloud, הגדירו את ה-URI להפניה אוטומטית של Google Cloud באפליקציית ה-IdP (ראו את מדריכי ההגדרה של Okta ו-Microsoft Entra ID).
הגדרה
מעדכנים את המשתנים הבאים כדי לאכלס את הפקודות במדריך הזה.
פרמטרים נדרשים להגדרה
צריך להתאים אישית את הפרמטרים האלה בהתאם לסביבת Google Cloud ולהגדרות של ה-IdP החיצוני.
| פרמטר | ערך | תיאור |
|---|---|---|
| מזהה הארגון | 123456789012 |
Google Cloud מזהה הארגון המספרי. |
| מזהה פרויקט | my-project |
מזהה הפרויקט של הצרכן שרשום למכונה של חישוב רב-משתתפים. |
| מזהה הדומיין | 67317436-0f29-ba9e-9146-d11c0bd8df9b |
מזהה הדומיין הייחודי שהוקצה למכונה של החישוב הרב-משתתפים. |
| מזהה נתיב המופע | mpc-unit-bob-123 |
מזהה נתיב המכונה שהוקצה למכונה שלכם ב-Multi-party Compute. |
| Location | us-central1 |
מיקום הפריסה (us-central1). מידע נוסף זמין במאמר מיקומים של חישוב רב-משתתפים. |
| מזהה מאגר כוח העבודה | mpc-workforce-pool |
המזהה של מאגר הזהויות של כוח העבודה ברמת הארגון. |
| מזהה הספק | mpc-oidc-provider |
המזהה של ספק מאגר הזהויות של כוח העבודה. |
| מזהה URI של מנפיק ה-IdP | https://idp.example.com |
ה-URI של מנפיק ה-IdP החיצוני של OIDC. |
| מזהה הלקוח של ה-IdP | mpc-client |
מזהה הלקוח ב-OAuth 2.0 שמוגדר ב-IdP החיצוני. |
שלב 1: הגדרת ספק ומאגר זהויות של כוח עבודה
מאגרי זהויות של כוח עבודה (locations/global/workforcePools/mpc-workforce-pool) הם משאבים ברמת הארגון שממופים לדייר של ספק הזהויות (IdP) של הארגון. לא צריך ליצור מאגרי כוח עבודה נפרדים לכל פרויקט או תפקיד.
יוצרים מאגר זהויות של כוח עבודה בארגון ב- Google Cloud :
gcloud iam workforce-pools create "mpc-workforce-pool" \ --organization="123456789012" \ --location="global" \ --display-name="MPC Workforce Pool"יוצרים ספק של מאגר זהויות של כוח עבודה ב-OIDC שנותן אמון ב-IdP החיצוני וממפה את הצהרות הנושא והקבוצה:
gcloud iam workforce-pools providers create-oidc "mpc-oidc-provider" \ --workforce-pool="mpc-workforce-pool" \ --location="global" \ --display-name="MPC Enterprise OIDC Provider" \ --issuer-uri="https://idp.example.com" \ --client-id="mpc-client" \ --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups" \ --web-sso-response-type="id-token" \ --web-sso-assertion-claims-behavior="only-id-token-claims"
שלב 2: הקצאת תפקידי IAM לחשבונות משתמשים מאוחדים
כדי לשלוח קריאה ל-MPC API, חשבונות משתמשים מאוחדים צריכים שני סוגים של קישורי תפקידים ב-IAM בפרויקט הצרכן (my-project):
- Service Usage Consumer (
roles/serviceusage.serviceUsageConsumer), שמאשר לזהות המאוחדת לשייך את מכסת ה-API והחיוב לפרויקט הצרכן שלכם. - תפקיד בחישוב רב-משתתפים (
roles/mpc.admin,roles/mpc.editorאוroles/mpc.viewer), שמאשר פעולות ספציפיות של חישוב רב-משתתפים.
בסביבת הייצור, מקשרים תפקידי IAM לקבוצות IdP נפרדות במאגר הזהויות של כוח העבודה:
# 1. Allow members of the workforce pool to consume APIs through the consumer project
gcloud projects add-iam-policy-binding "my-project" \
--role="roles/serviceusage.serviceUsageConsumer" \
--member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/*"
# 2. Grant MPC Admin to the enterprise administrators group
gcloud projects add-iam-policy-binding "my-project" \
--role="roles/mpc.admin" \
--member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-admins"
# 3. Grant MPC Editor to Policy Authors and Signers groups
gcloud projects add-iam-policy-binding "my-project" \
--role="roles/mpc.editor" \
--member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-policy-authors"
gcloud projects add-iam-policy-binding "my-project" \
--role="roles/mpc.editor" \
--member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-signers"
# 4. Grant MPC Viewer to the Compliance group
gcloud projects add-iam-policy-binding "my-project" \
--role="roles/mpc.viewer" \
--member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-auditors"
עומסי עבודה של חתימה אוטומטית (איחוד שירותי אימות הזהות של עומסי עבודה)
אם אתם מריצים דמונים אוטומטיים של חתימה משותפת מחוץ ל- Google Cloud (לדוגמה, ב-AWS, ב-Azure או ב-Kubernetes), אתם צריכים להגדיר מאגר וספק של זהויות של עומסי עבודה ברמת הפרויקט. נותנים את ההרשאות roles/serviceusage.serviceUsageConsumer ו-roles/mpc.editor לחשבון הראשי של עומס העבודה (principal://iam.googleapis.com/projects/<var>PROJECT_NUMBER</var>/locations/global/workloadIdentityPools/<var>WORKLOAD_POOL_ID</var>/subject/<var>SIGNER_NODE_SUBJECT</var>, מחליפים את <var>PROJECT_NUMBER</var>, <var>WORKLOAD_POOL_ID</var> ו-<var>SIGNER_NODE_SUBJECT</var> במספר הפרויקט, במזהה של מאגר עומסי העבודה ובדרישה sub של עומס העבודה), ויוצרים קובץ Application Default Credentials באמצעות gcloud iam workload-identity-pools create-cred-config.
הוספת זהויות מאוחדות כמשתמשים בגרסה v1beta
ב-v1beta API, תפקידי ה-IAM מהשלב הזה מאפשרים לזהות מאוחדת לשלוח קריאה למכונה שלכם. כדי לבצע פעולות בתוך המכונה כאדמין, כיוצר מדיניות או כחותם, הזהות צריכה גם משתמש. המכונה מזהה את מבצע הקריאה על ידי התאמת חשבון המשתמש של מבצע הקריאה לשדה principal של כל משתמש.
בזהות של איחוד שירותי אימות הזהות של כוח העבודה, מגדירים את principal למזהה הראשי של נושא הזהות:
principal://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/subject/SUBJECT_ID
מחליפים את SUBJECT_ID בערך שהספק ממפה ל-google.subject. במיפוי המאפיינים בשלב 1, זוהי ההצהרה sub של טוקן המזהה של המשתמש.
כשמגדירים את principal, חשוב לזכור:
- צריך להשתמש במזהה
principal://, ולא במזההprincipalSet://. משתמש הוא אדם אחד. מזהי קבוצות ומאגרים כמוprincipalSet://.../group/mpc-signersפועלים בקישורי תפקידים של IAM, אבל הם אף פעם לא תואמים למבצע הקריאה, ולכן משתמש שנוצר עם אחד מהם לא יכול לפעול במכונה. - התאמה מדויקת לנושא. המופע משווה בין נושאים של כוח עבודה ושל עומס עבודה תוך הבחנה בין אותיות רישיות וקטנות, אז צריך להעתיק את הנושא כמו שהוא מונפק על ידי ה-IdP. כתובות אימייל של חשבונות Google, כמו
alice@example.com, מושוות ללא תלות ברישיות. - לא תוכלו לשנות את
principalאחר כך. כדי לשנות את הזהות של משתמש, צריך להשבית את המשתמש וליצור משתמש חדש.
שלב 3: אימות וקבלת טוקן גישה מאוחד
MPC API לא מקבל אסימוני OIDC או טענות נכוֹנוּת (assertion) של SAML ישירות מספק הזהויות (IdP). לפני שקוראים לנקודת הקצה של המכונה לחישוב רב-משתתפים (*.mpc.goog), מחליפים את פרטי הכניסה של ספק הזהויות (IdP) באסימון גישה מאוחד ( Google Cloud ) באמצעות Security Token Service.
אתם יכולים לקבל ולנהל טוקני גישה מאוחדים באופן אוטומטי באמצעות Application Default Credentials (ADC) ו-CLI של gcloud, או באופן פרוגרמטי באמצעות Security Token Service API.
Application Default Credentials וה-CLI של gcloud
באפליקציות לקוח בסביבת ייצור ובסשנים אינטראקטיביים של CLI, משתמשים בקובץ תצורה כדי ש-Google Cloud SDK וספריות הלקוח ב-Cloud יטפלו באופן אוטומטי בהחלפה, בשמירה במטמון וברענון של אסימוני Security Token Service ברקע.
אפשרות א': כניסה אינטראקטיבית בדפדפן
יוצרים קובץ תצורה לכניסה ומאמתים את ה-CLI של gcloud ואת Application Default Credentials (ADC) באמצעות ה-IdP של הארגון:
gcloud iam workforce-pools create-login-config \
"locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
--activate \
--output-file="login-config.json"
gcloud config set billing/quota_project "my-project"
gcloud auth login --login-config="login-config.json"
gcloud auth application-default login --login-config="login-config.json"
אפשרות ב': כניסה לא אינטראקטיבית באמצעות קובץ תצורה של פרטי כניסה (ADC)
אם תהליך חיצוני מספק ומרענן אסימון OIDC חתום בקובץ מקומי (לדוגמה, /var/run/secrets/tokens/oidc-token) לפני שתוקף האסימון פג, צריך ליצור קובץ תצורה של פרטי כניסה חיצוניים:
gcloud iam workforce-pools create-cred-config \
"locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
--subject-token-type="urn:ietf:params:oauth:token-type:id_token" \
--credential-source-file="/var/run/secrets/tokens/oidc-token" \
--workforce-pool-user-project="my-project" \
--output-file="credential-config.json"
export GOOGLE_APPLICATION_CREDENTIALS="$(pwd)/credential-config.json"
מייצאים את אסימון הגישה לבקשות של curl:
אחרי שמסיימים את אפשרות א' או אפשרות ב', מייצאים את אסימון הגישה המאומת מ-ADC אל ACCESS_TOKEN:
export ACCESS_TOKEN="$(gcloud auth application-default print-access-token)"
החלפה ישירה של אסימון STS ב-REST
אם אתם משלבים לקוח בהתאמה אישית בלי ערכות ה-SDK של Google Cloud , אתם צריכים להחליף טוקן של מזהה OIDC חתום (<var>IDP_ID_TOKEN</var>) ישירות עם Security Token Service. כוללים את userProject בשדה options כדי ש- Google Cloud ישייך את האסימון לפרויקט הצרכן:
# Set IDP_ID_TOKEN to the signed OIDC JWT assertion from your external IdP
# export IDP_ID_TOKEN="eyJhbGciOiJSUzI1NiIs..."
STS_RESPONSE=$(curl -sS -X POST "https://sts.googleapis.com/v1/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
--data-urlencode "audience=//iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
--data-urlencode "scope=https://www.googleapis.com/auth/cloud-platform" \
--data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:access_token" \
--data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:id_token" \
--data-urlencode "subject_token=${IDP_ID_TOKEN}" \
--data-urlencode 'options={"userProject":"my-project"}')
export ACCESS_TOKEN=$(echo "${STS_RESPONSE}" | jq -er '.access_token') || echo "${STS_RESPONSE}" | jq .
שלב 4: מאמתים את הגישה המשותפת ל-API
כדי לוודא שפרטי הכניסה המאומתים, השיוך (Attribution) של userProject וקישורי התפקידים ב-IAM פועלים, מציגים את המשתמשים במכונה של החישוב הרב-משתתפים. מכיוון ש-mpc.googleapis.com/users.list נכלל ב-roles/mpc.viewer, ב-roles/mpc.editor וב-roles/mpc.admin, כל זהות מאוחדת מורשית יכולה להריץ את הבדיקה הזו:
curl -sS -X GET \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "X-Goog-User-Project: my-project" \
"https://67317436-0f29-ba9e-9146-d11c0bd8df9b.us-central1.mpc.goog/v1beta/projects/my-project/locations/us-central1/instances/mpc-unit-bob-123/users" | jq .
תגובת JSON מסוג 200 OK ({} במכונה חדשה או רשימה של users) מאשרת שהזהות המאוחדת שלכם מאומתת ומורשית לשלוח קריאה למכונה שלכם לחישוב רב-משתתפים.
הבדיקה הזו משתמשת רק ב-IAM. כדי לוודא שהמכונה גם מזהה את הזהות שלכם כמשתמשים, צריך לבדוק שאחד מהמשתמשים שהוחזרו מכיל את המזהה שלכם ב-principal:// בשדה principal. מידע נוסף זמין במאמר הוספת זהויות מאוחדות כמשתמשי v1beta.
פתרון בעיות
אם נתקלתם בשגיאות אימות או הרשאה כשאתם קוראים לחישוב רב-משתתפים עם פרטי כניסה מאוחדים, ודאו שהדרישות הבאות מתקיימות:
שיוך פרויקט של משתמש (401 UNAUTHENTICATED: Unable to determine client project number)
- הסיבה: פרטי הכניסה של מאגר כוח העבודה ברמת הארגון לא קשורים באופן מהותי לפרויקט אחד ב- Google Cloud , אלא אם צוין פרויקט של משתמש במהלך המרת האסימון או בבקשה.
- פתרון: צריך לכלול את
options: {"userProject": "<var>PROJECT_ID</var>"}בגוף הבקשה להחלפת אסימון של Security Token Service (או את--workforce-pool-user-projectב-gcloud iam workforce-pools create-cred-config), ולכלול את הכותרתX-Goog-User-Project: <var>PROJECT_ID</var>בקריאות ל-MPC API.
חסרה הרשאה לשימוש בשירות (403 PERMISSION_DENIED)
- הסיבה: לחשבון המשתמש או לקבוצה המאומתים אין הרשאה לשייך את השימוש ב-API לפרויקט הצרכן שצוין ב-
userProjectאו ב-X-Goog-User-Project. - הפתרון: נותנים את ההרשאה
roles/serviceusage.serviceUsageConsumerלחברprincipal://אוprincipalSet://בפרויקט הצרכן (ראו שלב 2).
אי-התאמה בפרויקט הצרכן (403 PERMISSION_DENIED: Project is not allowed to call the API through this host)
- הסיבה: כל נקודת קצה ייעודית של מכונה לחישוב רב-משתתפים מקבלת רק בקשות מהפרויקט של הצרכן שהוגדר לאותה מכונה.
- פתרון: מוודאים שהערך של
<var>PROJECT_ID</var>בנתיב כתובת ה-URL של הבקשה ובכותרתuserProjectאוX-Goog-User-Projectתואם לפרויקט הצרכן שהוקצה למכונה של החישוב הרב-משתתפים.
פרטי כניסה לא תקינים (401 UNAUTHENTICATED: Request credential is invalid)
- הסיבה: אסימון OIDC או טענת נכוֹנוּת (assertion) של SAML של צד שלישי נשלחו ישירות לנקודת הקצה של החישוב הרב-משתתפים, בלי להחליף אותם קודם באמצעות Security Token Service.
- פתרון: מחליפים את פרטי הכניסה של ספק הזהויות באמצעות
https://sts.googleapis.com/v1/token(או משתמשים ב-Application Default Credentials) ומעבירים את טוקן הגישה של Google Cloud בכותרתAuthorization: Bearer.
מדיניות הגבלה לפי דומיין חוסמת קישורי תפקידים (400 FAILED_PRECONDITION)
- הסיבה: בארגון שלכם ( Google Cloud ) נאכפת מדיניות הארגון (
constraints/iam.allowedPolicyMemberDomains), שמגבילה את הדומיינים של חשבונות המשתמשים שאפשר להקצות להם תפקידי IAM בפרויקטים. - פתרון: מבקשים מהאדמין של מדיניות הארגון להוסיף את קבוצת הישויות המורשות של מאגר כוח העבודה לדומיינים המורשים של גורמי המדיניות בפרויקט או בארגון של הצרכן, או לבדוק בפרויקט שבו
constraints/iam.allowedPolicyMemberDomainsמאפשר את מאגר כוח העבודה.
המאמרים הבאים
- כדי ליצור משתמשים, צוותים, כללי מדיניות של עסקאות ומפתחות, וכדי לחתום על עסקאות באמצעות הזהות המאוחדת, פועלים לפי המדריך למשתמש בנושא חישוב רב-משתתפים. מגדירים את חשבון המשתמש של כל משתמש למזהה
principal://שמתואר בקטע הוספת זהויות מאוחדות כמשתמשים בגרסת v1beta. - המדריך למשתמש מאחזר את אסימון הגישה של כל פרסונה באמצעות
gcloud auth print-access-token, שמשתמש בפרטי הכניסה של ה-CLI שלgcloud, ולא ב-Application Default Credentials. להיכנס לכל משתמש מאוחד באמצעותgcloud auth login --login-config, כפי שמוצג באפשרות א' של שלב 3. - במאמר אבטחה והרשאות מוסבר בהרחבה על תפקידי משתמשים, הרשאות IAM ותנאים ברמת המשאב.