הגדרת איחוד שירותי אימות הזהות של כוח העבודה (BYOID)

במדריך הזה מוסבר איך להגדיר את Bring Your Own Identity‏ (BYOID) ל-Multi-party Compute API באמצעות איחוד שירותי אימות הזהות של כוח עבודה ואיחוד שירותי אימות הזהות של עומסי עבודה. בעזרת איחוד שירותי אימות הזהות, משתמשים אנושיים ועומסי עבודה של חתימה אוטומטית יכולים לאמת את הזהות שלהם בחישוב רב-משתתפים באמצעות ספק הזהויות (IdP) החיצוני של הארגון, כמו Okta, ‏ Microsoft Entra ID או Ping Identity. אתם לא צריכים ליצור חשבונות Google או לנהל מפתחות של חשבונות שירות לטווח ארוך.

סקירה כללית

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

  1. הרשאה של ניהול זהויות והרשאות גישה (IAM) ב-Edge: הגורמים שמבצעים את הקריאה מחליפים את פרטי הכניסה מספק זהויות (IdP) חיצוני של OpenID Connect (OIDC) או SAML 2.0 ב- Google Cloud Security Token Service (Security Token Service) כדי לקבל אסימון גישה מאוחד לטווח קצר. שער ה-API של Google Cloud בודק את הקישורים לתפקידי IAM מול ה-URI של החשבון המאומת לפני שהוא מעביר את הבקשות למכונה של החישוב הרב-משתתפים, ומפיץ את הזהות המאוחדת (principalSubject) ליומני הביקורת של Cloud.
  2. הפרדת תפקידים ואישור קריפטוגרפי: תפקידי 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 ממופים לפרסונות של חישוב רב-משתתפים.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שהתנאים הבאים מתקיימים:

  1. Google Cloud ארגון ופרויקט צרכן שהוגדרו לחישוב רב-משתתפים.
  2. התקנה של ה-CLI של gcloud ושל jq, ואימות של gcloud באמצעות חשבון אדמין עם התפקידים הבאים:
    • אדמין של מאגר כוח עבודה (roles/iam.workforcePoolAdmin) בארגון ב- Google Cloud (אם יוצרים מאגר כוח עבודה חדש בשלב 1).
    • אדמין IAM של פרויקט (roles/resourcemanager.projectIamAdmin) ואדמין של שימוש בשירות (roles/serviceusage.serviceUsageAdmin) בפרויקט הצרכן.
  3. ממשקי ה-API הנדרשים שמופעלים בפרויקט של הצרכן:

    gcloud services enable mpc.googleapis.com iam.googleapis.com sts.googleapis.com \
      --project="my-project"
    
  4. אפליקציית 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) של הארגון. לא צריך ליצור מאגרי כוח עבודה נפרדים לכל פרויקט או תפקיד.

  1. יוצרים מאגר זהויות של כוח עבודה בארגון ב- Google Cloud :

    gcloud iam workforce-pools create "mpc-workforce-pool" \
      --organization="123456789012" \
      --location="global" \
      --display-name="MPC Workforce Pool"
    
  2. יוצרים ספק של מאגר זהויות של כוח עבודה ב-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):

  1. Service Usage Consumer (roles/serviceusage.serviceUsageConsumer), שמאשר לזהות המאוחדת לשייך את מכסת ה-API והחיוב לפרויקט הצרכן שלכם.
  2. תפקיד בחישוב רב-משתתפים (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 ותנאים ברמת המשאב.