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

OIDC

• IdP שתומך ב-OpenID Connect 1.0.

• ל-IdP יש URI של מנפיק.

• ‫Cloud de Confiance יכול לגשת לקבוצת מפתחות אינטרנט מסוג JSON ‏ (JWKS) שמכילה מפתחות אינטרנט מסוג JSON ‏ (JWKs). מפתחות ה-JWK משמשים לאימות אסימוני טענת נכוֹנוּת (assertion) של OIDC. אתם יכולים לתת גישה ל-JWKS באחת מהדרכים הבאות:

  • Cloud de Confiance מוריד מטא-נתונים של OIDC מ-IdP, דרך כתובת URL של מסמך Discovery שזמינה לכולם, מוכרת ונגישה באינטרנט. בתוך המטא-נתונים, כתובת ה-URL של JWKS חייבת להיות מאובטחת באמצעות SSL ו-TLS. כתובת ה-URL של JWKS חייבת להתחיל ב-https://. מערכת Cloud de Confiance לא תומכת בכתובות URL של JWKS שמאובטחות באמצעות אישורים חתומים באופן עצמי.

    כברירת מחדל, Cloud de Confiance מוסיף את /.well-known/openid-configuration ל-URI של המנפיק כדי לאתר את כתובת ה-URL של מסמך Discovery. אם ספק הזהויות מארח את המטא-נתונים של הגילוי בנקודת קצה מותאמת אישית, אתם יכולים לציין URI מותאם אישית של גילוי (--discovery-uri) (גרסת טרום-השקה (Preview)).

    ה-URI המותאם אישית של הגילוי צריך לעמוד בדרישות הבאות:

    • ה-URI חייב להתחיל ב-https://.
    • ה-URI לא יכול להכיל יותר מ-2,000 תווים.
    • הסכימה, המארח והיציאה חייבים להתאים ל-URI של המנפיק.
    • נתיב ה-URI חייב להכיל את /.well-known/<suffix> (כאשר <suffix> לא ריק, כמו openid-configuration) ולעמוד באחת מהטופולוגיות הבאות של כתובת ה-URL של המנפיק:
    • קטע הנתיב well-known מוכנס לפני הנתיב של המנפיק (לדוגמה, https://example.com/.well-known/openid-configuration/tenant1 למנפיק https://example.com/tenant1).
    • מקטע הנתיב well-known מצורף מתחת לנתיב המנפיק (לדוגמה, https://example.com/tenant1/.well-known/openid-configuration למנפיק https://example.com/tenant1).

    ‫Cloud de Confiance משתמש בכתובות ה-URL האלה של נקודות הקצה כדי להוריד את מפתחות האינטרנט בפורמט JSON‏ (JWK) של ה-IdP, ומשתמש במפתחות האלה כדי לאמת אסימונים. ב-Cloud de Confiance אין הגבלה על מספר המפתחות שאפשר להוריד.

  • אתם יכולים להעלות קובץ JWKS של OIDC ישירות אל Cloud de Confiance כשאתם יוצרים או מעדכנים את הספק של מאגר הזהויות של עומסי העבודה ב-OIDC. כדי לעשות את זה, משתמשים ב---jwk-json-path כדי לספק נתיב לקובץ ה-JWKS. אתם יכולים להשתמש בשיטה הזו כשכתובת ה-URL של נקודת הקצה של המטא-נתונים של ה-OIDC של ה-IdP לא נגישה לכולם. אפשר להעלות עד 8 מפתחות אל Cloud de Confiance. מומלץ לבצע רוטציה של מפתחות JWKS באופן קבוע על ידי עדכון קובץ ה-JWKS.

• אם אתם מאחדים עומסי עבודה מ-AWS באמצעות AWS Outbound Identity Federation, ‏ AWS פועל בתור ה-OIDC IdP שלכם. כדי להכין את סביבת AWS:

  1. מפעילים איחוד זהויות יוצא בהגדרות של חשבון AWS כדי ליצור את כתובת ה-URL הייחודית של מנפיק ה-OIDC.

  2. מוודאים שלעומסי העבודה ב-AWS (כמו פרופילים של מכונות EC2 או תפקידי משימות ב-ECS) יש את מדיניות AWS IAM הנדרשת, שמעניקה הרשאה לקבל אסימוני אינטרנט מסוג JSON‏ (JWT).

SAML

• IdP שתומך ב-SAML גרסה 2.0.

• ה-IdP מציג מסמך מטא-נתונים מסוג SP של SAML שמתאר את ההגדרה של ספק השירות של SAML ומכיל את אישור החתימה של ה-IdP.

  ב-Cloud de Confiance , המערכת משתמשת באישור הזה כדי לאמת טענות נכונות ותגובות של SAML.

• אישור החתימה של ה-IdP חייב להכיל מפתח ECDSA או RSA שנמצא בתוך אישור X.509 v3.

• האלגוריתמים המומלצים לחתימה כוללים:

  • ECDSAwithSHA256
  • ‫RSAwithSHA256 עם גדלי מפתחות נתמכים של 2048, 3072 ו-4096 ביטים.

• אישור החתימה צריך לעמוד בדרישות התוקף הבאות:

  • notBefore: חותמת זמן של 7 ימים לכל היותר בעתיד
  • notAfter: חותמת זמן של 25 שנים לכל היותר בעתיד

אפשר להגדיר ספק של מאגר זהויות של עומסי עבודה ב-SAML עם שלושה אישורי חתימה של SAML לכל היותר בכל רגע נתון. המגבלה הזו לא חלה על סוגים אחרים של ספקים של מאגרי זהויות של עומסי עבודה, כמו OIDC ו-X.509. כשיש כמה אישורים, מערכת Cloud de Confiance עוברת באיטרציות על האישורים שעדיין בתוקף ומנסה להשתמש בכל אישור כדי למלא בקשות להחלפת אסימונים.

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

OIDC

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

• האסימונים נחתמים באמצעות האלגוריתם RS256 או ES256.

• האסימונים מכילים הצהרת aud עם הערך הבא:

  https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID
  

  מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_NUMBER: מספר הפרויקט ב- Cloud de Confiance שבו משתמשים כדי ליצור מאגר זהויות של עומסי עבודה.
  • POOL_ID: מזהה לבחירתכם, שמזהה את מאגר הזהויות של עומסי העבודה. בהמשך תצטרכו להשתמש במזהה הזה כשתיצרו את מאגר הזהויות של עומסי עבודה.
  • WORKLOAD_PROVIDER_ID: מזהה לבחירתכם, שמזהה את ספק מאגר הזהויות של עומסי העבודה. בהמשך תצטרכו להשתמש במזהה הזה כשתיצרו ספק של מאגר זהויות של עומסי עבודה.

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

• האסימונים מכילים הצהרת exp עתידית והצהרת iat שחלה בעבר.

  הערך של exp צריך להיות גדול מהערך של iat עד 24 שעות לכל היותר.

• אסימונים שקשורים לאישור (גרסת טרום-השקה (Preview)): אופציונלי, אסימונים יכולים לכלול הצהרת cnf (אישור) שמכילה טביעת אצבע לאישור SHA-256‏ (x5t#S256):

  "cnf": {
    "x5t#S256": "BASE64URL_SHA256_CERT_FINGERPRINT"
  }
  

  הערך של x5t#S256 חייב להיות גיבוב SHA-256 בקידוד base64url של קידוד ה-DER של אישור ה-X.509 של הלקוח. כשמציגים אסימון שמכיל את ההצהרה הזו לאיחוד שירותי אימות הזהות של עומסי עבודה דרך חיבור Mutual TLS (mTLS) (sts.mtls.googleapis.com), שירות אסימוני האבטחה מאמת שטביעת האצבע תואמת לאישור הלקוח שהוצג במהלך לחיצת היד בפרוטוקול TLS, ומנפיק אסימון גישה לטווח קצר שקשור לאישור באופן קריפטוגרפי.

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

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

• טוקני הגישה מעוצבים בפורמט JSON Web Token.

• אסימוני הגישה מכילים הצהרת ISSUER, כך שכתובת ה-URL ISSUER/.well-known/openid-configuration מפנה לנקודת הקצה של המטא-נתונים של OIDC ב-IdP.

• כדי להעלות מפתחות JWK מקומיים, קראו את המאמר ניהול מפתחות JWK ב-OIDC.

SAML

צריך להגדיר את ה-IdP כך שטענות הנכוֹנוּת (assertions) של SAML יכללו רכיבים שעומדים בקריטריונים הבאים:

• רכיב Issuer שמוגדר למזהה הישות ב-SAML בהגדרות הספק של מאגר הזהויות של עומסי העבודה. צריך להשמיט את הפורמט של המנפיק או להגדיר אותו בתור urn:oasis:names:tc:SAML:2.0:nameid-format:entity.
• רכיב Subject עם:
  • רכיב NameID.
  • רכיב SubjectConfirmation אחד בדיוק עם Method שמוגדר ל-urn:oasis:names:tc:SAML:2.0:cm:bearer.
  • רכיב SubjectConfirmationData עם NotOnOrAfter מוגדר לחותמת זמן שתתרחש בעתיד ואין לה ערך NotBefore.

• רכיב Conditions עם:

  • NotBefore שהושמט או שהוא התרחש בעבר.
  • NotOnOrAfter שהושמט או שהוא יתרחש בעתיד.

  • Audience מופיע לפי הפורמט הבא:

    https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID
    

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_NUMBER: מספר הפרויקט ב- Cloud de Confiance שבו משתמשים כדי ליצור מאגר זהויות של עומסי עבודה.
    • POOL_ID: מזהה לבחירתכם, שמזהה את מאגר הזהויות של עומסי העבודה. בהמשך תצטרכו להשתמש במזהה הזה כשתיצרו את מאגר הזהויות של עומסי עבודה.
    • WORKLOAD_PROVIDER_ID: מזהה לבחירתכם, שמזהה את ספק מאגר הזהויות של עומסי העבודה. בהמשך תצטרכו להשתמש במזהה הזה כשתיצרו ספק של מאגר זהויות של עומסי עבודה.

• לפחות רכיב אחד של AuthnStatement.

• רכיב SessionNotOnOrAfter עם חותמת זמן שתתרחש בעתיד. לחלופין, אפשר להשמיט את הרכיב.

בטענות נכוֹנוּת (assertions) של SAML שמצורפות לתגובת SAML, תגובת SAML חייבת להכיל:

• טענת נכוֹנוּת אחת בדיוק שעומדת בקריטריונים של טענת נכוֹנוּת (assertion) ב-SAML שמתוארים למעלה בקטע הזה.
• מאפיין IssueInstant עם ערך שחל לפני פחות משעה.
• קוד סטטוס urn:oasis:names:tc:SAML:2.0:status:Success.

צריך לחתום על טענת נכונות של SAML, על התגובה או על שתיהן.

OIDC

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

צריך למפות את אחת מההצהרות האלה ל-google.subject כדי לזהות את המשתמש באופן ייחודי. כדי להגן מפני איומי זיופים, צריך לבחור הצהרה עם ערך ייחודי שאי אפשר לשנות.

מזהי IdP רבים נכללים בהצהרה sub עם מזהה ייחודי שלא ניתן לשינוי. לגבי מזהי ה-IdP האלה, כדאי למפות את ההצהרה sub ל-google.subject:

google.subject=assertion.sub

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

מיפוי מאפייני משתמשים עם הקצאת זהות (גרסת טרום-השקה (Preview)): כשמשתמשים בהקצאת זהות, שירות אסימוני האבטחה משלב את ההצהרות של הנושא וההצהרות של המשתמש, וחושף את ההצהרות של המשתמש באובייקט ההצהרה act. אפשר להפנות להצהרות של שחקנים במיפוי המאפיינים באמצעות assertion.act.<claim_name>.

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

לדוגמה, אפשר למפות את מזהה הנושא ואת ה-URI של המנפיק של השחקן למאפיינים מותאמים אישית של Google:

attribute.actor_subject=assertion.act.sub,attribute.actor_issuer=assertion.act.iss

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

SAML

כשממפים את המאפיינים, אפשר להשתמש ברכיבים <Subject> ו-<Attribute> שמוטמעים בטענת הנכוֹנוּת (assertion) שהנפיק ה-IdP החיצוני. אפשר לקרוא למאפייני SAML באמצעות מילות המפתח הבאות:

• assertion.subject מכיל את ה-NameID של המשתמש המאומת שנמצא ברכיב <Subject>.
• assertion.attributes['ATTRIBUTE_NAME'] מכיל רשימת ערכים בשביל <Attribute> בשם דומה.

צריך למפות את אחת מההצהרות האלה ל-google.subject כדי לזהות את המשתמש באופן ייחודי. כדי להגן מפני איומי זיופים, צריך לבחור הצהרה עם ערך ייחודי שאי אפשר לשנות.

מזהי IdP רבים נכללים בהצהרה NameId עם מזהה ייחודי שלא ניתן לשינוי. למזהי ה-IdP האלה, כדאי למפות את המאפיין NameId ל-google.subject:

google.subject=assertion.subject

לשם כך, עדיף שלא להשתמש במאפיין כמו http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. בדרך כלל אפשר להקצות או לשנות כתובות אימייל כדי שהן לא יזהו משתמש באופן ייחודי ועקבי.

OIDC

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

לדוגמה, בעזרת התנאי הבא אפשר להגביל גישה לאסימונים שכוללים הצהרת service_account מותאמת אישית עם הערך true:

assertion.service_account==true

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

לדוגמה, התנאי הבא דורש שיהיה אסימון של גורם מבצע, ושהגורם המבצע הגיע ממנפיק צפוי:

has(assertion.act) && assertion.act.iss == 'https://actor-idp.example.com'

כדי להגביל את הגישה למזהה נושא ספציפי של שחקן:

assertion.act.sub == 'authorized-agent-worker'

SAML

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

לדוגמה, בעזרת התנאי הבא אפשר להגביל גישה לטענות נכוֹנוּת (assertions) שכוללות מאפיין https://example.com/SAML/Attributes/AllowGcpFederation מותאם אישית עם הערך true:

assertion.attributes['https://example.com/SAML/Attributes/AllowGcpFederation'][0]=='true'

המסוף

1. במסוף Cloud de Confiance , נכנסים לדף New workload provider and pool.

   לדף New workload provider and pool

2. בקטע Create an identity pool, מזינים את הפרטים הבאים:

   • Name: השם של המאגר. השם משמש גם כמזהה המאגר. אי אפשר לשנות את מזהה המאגר בשלב מאוחר יותר.
   • Description: טקסט שמתאר את המטרה של המאגר.

3. לוחצים על Continue.

4. מגדירים את הספק באופן הבא:

   OIDC

   • ב-Select a provider, בוחרים את OpenID Connect (OIDC).
   • בקטע שם הספק, מזינים שם לספק. השם משמש גם כמזהה הספק. אי אפשר לשנות את מזהה הספק אחרי שיוצרים את הספק.
   • בשדה Issuer URL, מזינים את כתובת ה-URL של מנפיק ה-IdP. כתובת ה-URL צריכה להתחיל ב-https://
   • אופציונלי: בקטע JWK file (JSON), בוחרים קובץ JWK להעלאה. אם לא מוסיפים את השדה הזה, המערכת של Cloud de Confiance תנסה לאחזר מפתח JWK מהמנפיק.
   • Allowed audiences: הקהל הצפוי של הטוקנים של המזהים.

   SAML

   • בקטע Select a provider, בוחרים באפשרות SAML.
   • בקטע שם הספק, מזינים שם לספק. השם משמש גם כמזהה הספק. אי אפשר לשנות את מזהה הספק אחרי שיוצרים את הספק.
   • בשדה IDP Metadata file (XML), מעלים את מסמך ה-XML של המטא-נתונים של SAML שקיבלתם מה-IdP.

5. לוחצים על Continue.

6. בקטע Configure provider attributes, מוסיפים את מיפויי המאפיינים שזיהיתם קודם במדריך הזה.

7. בקטע Attribute conditions, מזינים את התנאי למאפיין שזיהיתם קודם לכן במדריך הזה. אם אין לכם תנאי למאפיין, משאירים את השדה ריק.

8. כדי ליצור את מאגר הזהויות של עומסי עבודה וספק, לוחצים על Save.

gcloud

1. כדי ליצור מאגר זהויות של עומסי עבודה, מריצים את הפקודה הבאה:

   gcloud iam workload-identity-pools create POOL_ID \
       --location="global" \
       --description="DESCRIPTION" \
       --display-name="DISPLAY_NAME"
   

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

   • ‏POOL_ID: המזהה הייחודי של המאגר.
   • DISPLAY_NAME: שם המאגר.
   • DESCRIPTION: תיאור של המאגר שנבחר. התיאור הזה מופיע כשנותנים גישה לזהויות במאגר.

2. כדי להוסיף ספק של מאגר זהויות של עומסי עבודה:

   OIDC

   כדי להוסיף ספק של מאגר זהויות של עומסי עבודה ב-OIDC, מריצים את הפקודה הבאה:

   gcloud iam workload-identity-pools providers create-oidc WORKLOAD_PROVIDER_ID \
       --location="global" \
       --workload-identity-pool="POOL_ID" \
       --issuer-uri="ISSUER" \
       --discovery-uri="DISCOVERY_URI" \
       --allowed-audiences="AUDIENCE" \
       --attribute-mapping="MAPPINGS" \
       --attribute-condition="CONDITIONS" \
       --jwk-json-path="JWK_JSON_PATH" \
       --actor-providers="ACTOR_PROVIDERS"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • WORKLOAD_PROVIDER_ID: מזהה ייחודי לפי בחירתכם של ספק מאגר הזהויות של עומסי העבודה.
   • POOL_ID: מזהה מאגר הזהויות של עומסי העבודה שיצרתם קודם.
   • ISSUER: URI של מנפיק כפי שמוגדר במטא-נתונים של OIDC.
   • ‫DISCOVERY_URI גרסת טרום-השקה (Preview): כתובת URL אופציונלית של מסמך Discovery בהתאמה אישית לאחזור מטא-נתונים של OIDC, אם ה-IdP לא מארח את נקודת הקצה הידועה של מסמך Discovery של OIDC בכתובת https://<issuer_url>/.well-known/openid-configuration. הסכימה, המארח והיציאה חייבים להתאים ל-ISSUER, והנתיב חייב להתאים לטופולוגיה של כתובת ה-URL של המנפיק (שמכילה את /.well-known/<suffix>).
   • AUDIENCE: הקהל הצפוי של אסימונים מזהים, שאצל ספקים רבים תואם את מזהה הלקוח.
   • MAPPINGS: רשימה מופרדת בפסיקים של מיפויי המאפיינים שיצרת קודם לכן במדריך הזה.
   • CONDITIONS: תנאי למאפיין אפשרי שיצרת מוקדם יותר במדריך הזה. אפשר להסיר את הפרמטר אם אין לך תנאי למאפיין.
   • JWK_JSON_PATH: נתיב אופציונלי למפתחות JWK ב-OIDC שהועלו באופן מקומי. אם לא מוסיפים את הפרמטר הזה, המערכת של Cloud de Confiance תשתמש בכתובת ה-URL של מסמך Discovery (או DISCOVERY_URI או הנתיב /.well-known/openid-configuration של ה-IdP) כדי למצוא את מפתחות ה-JWK שמכילים את המפתחות הציבוריים.
   • ACTOR_PROVIDERS גרסת טרום-השקה (Preview): רשימה אופציונלית מופרדת בפסיקים של שמות המשאבים המלאים של ספקי מאגר הזהויות של עומסי העבודה באותו מאגר, שמורשים להנפיק אסימוני שחקן לספק הזה (לדוגמה, projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/ACTOR_PROVIDER_ID). מזהה מאגר הפרויקטים בשם המשאב חייב להתאים לפורמט שמשמש את ספק הנושא (שניהם משתמשים במספר הפרויקט או ששניהם משתמשים במזהה הפרויקט). אפשר לציין עד שלושה ספקי שחקנים. מידע נוסף זמין במאמר הגדרת הקצאת זהויות ואסימוני שחקנים.

   SAML

   כדי להוסיף ספק של מאגר זהויות של עומסי עבודה ב-SAML, מריצים את הפקודה הבאה:

   gcloud iam workload-identity-pools providers create-saml WORKLOAD_PROVIDER_ID \
       --location="global" \
       --workload-identity-pool="POOL_ID" \
       --idp-metadata-path="IDP_METADATA_PATH" \
       --attribute-mapping="MAPPINGS" \
       --attribute-condition="CONDITIONS"
   

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

   • ‫POOL_ID: מזהה המאגר
   • IDP_METADATA_PATH: הנתיב המקומי למסמך המטא-נתונים של ה-IdP ב-SAML
   • MAPPINGS: רשימה של מיפויי מאפייניםשמופרדים בפסיקים שיצרת קודם לכן במדריך הזה
   • CONDITIONS: אופציונלי: התנאי למאפיין שיצרת קודם לכן במדריך הזה

   התחילית gcp- שמורה ואי אפשר להשתמש בה במזהה של מאגר זהויות של כוח עבודה או במזהה של ספק של מאגר זהויות של כוח עבודה.

   אופציונלי: אישור טענות נכונות (assertions) של SAML מוצפן מ-IdP

   כדי לאפשר ל-IdP ב-SAML 2.0 ליצור טענות נכוֹנוּת (assertions) של SAML מוצפן שאיחוד שירותי אימות הזהות של עומסי עבודה יכול לאשר, צריך לבצע את הפעולות הבאות:

   • באיחוד שירותי אימות הזהות של עומסי עבודה, מבצעים את הפעולות הבאות:
   • יוצרים זוג מפתחות אסימטריים לספק מאגר הזהויות של עומסי העבודה.
   • מורידים קובץ אישור שמכיל את המפתח הציבורי.
   • מגדירים את ספק הזהויות ב-SAML כך שישתמש במפתח הציבורי להצפנה של טענות הנכוֹנוּת שהוא מנפיק ב-SAML.
   • מבצעים את הפעולות הבאות בספק הזהויות:
   • מפעילים הצפנה של טענות נכונות (assertions), שנקראת גם הצפנת אסימונים.
   • מעלים את המפתח הציבורי שיצרתם באיחוד שירותי אימות הזהות של עומסי עבודה.
   • מוודאים שה-IdP מייצר טענות נכונות (assertions) של SAML מוצפן.

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

   יצירת מפתחות הצפנה של טענות נכונות (assertions) של SAML לאיחוד שירותי אימות הזהות של עומסי עבודה

   הקטע מסביר איך ליצור זוג מפתחות אסימטריים שמאפשר לאיחוד שירותי אימות הזהות של עומסי עבודה לקבל טענות נכונות (assertions) מוצפנות של SAML.

   ב- Cloud de Confiance by S3NS , המערכת משתמשת במפתח פרטי כדי לפענח את טענות הנכוֹנוּת (assertion) ב-SAML שה-IdP מנפיק. כדי ליצור זוג מפתחות אסימטריים להצפנה ב-SAML, מריצים את הפקודה הבאה. למידע נוסף, ראו אלגוריתמים נתמכים להצפנה ב-SAML.

   gcloud iam workload-identity-pools providers keys create KEY_ID \
       --workload-identity-pool WORKLOAD_POOL_ID \
       --provider WORKLOAD_PROVIDER_ID \
       --location global \
       --use encryption \
       --spec KEY_SPECIFICATION

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫KEY_ID: שם המפתח שבחרתם
   • ‫WORKLOAD_POOL_ID: מזהה המאגר
   • ‫WORKLOAD_PROVIDER_ID: המזהה של ספק מאגר הזהויות של כוח העבודה
   • KEY_SPECIFICATION: מפרט המפתחות, שיכול להיות אחד מאלה: rsa-2048, ‏rsa-3072 או rsa-4096.

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

   gcloud iam workload-identity-pools providers keys describe KEY_ID \
       --workload-identity-pool WORKLOAD_POOL_ID \
       --provider WORKLOAD_PROVIDER_ID \
       --location global \
       --format "value(keyData.key)" \
       > CERTIFICATE_PATH

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫KEY_ID: שם המפתח
   • ‫WORKLOAD_POOL_ID: מזהה המאגר
   • ‫WORKLOAD_PROVIDER_ID: המזהה של ספק מאגר הזהויות של כוח העבודה
   • CERTIFICATE_PATH: הנתיב שבו האישור ייכתב. לדוגמה: saml-certificate.cer או saml-certificate.pem

   הגדרת ה-IdP שתואם ל-SAML 2.0 כדי להנפיק טענות נכונות (assertions) של SAML מוצפן

   צריך להגדיר את ה-IdP ב-SAML כך שישתמש באישור הציבורי שהורדת בשלב האחרון ויצפין את טענות הנכונות (assertions) של ה-SAML שהוא מנפיק. לקבלת הוראות ספציפיות, אפשר לפנות לצוות ה-IdP שלך.

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

   מחיקת מפתחות ההצפנה של איחוד שירותי אימות הזהות של עומסי עבודה

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

     gcloud iam workload-identity-pools providers keys delete KEY_ID \
         --workload-identity-pool WORKLOAD_POOL_ID \
         --provider WORKLOAD_PROVIDER_ID \
         --location global

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫KEY_ID: שם המפתח
   • ‫WORKLOAD_POOL_ID: מזהה המאגר
   • ‫WORKLOAD_PROVIDER_ID: המזהה של ספק מאגר הזהויות של כוח העבודה

   אלגוריתמי הצפנה נתמכים של SAML

   איחוד שירותי אימות הזהות של עומסי עבודה תומך באלגוריתמים הבאים לתעבורת מפתחות:

   • http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
   • http://www.w3.org/2009/xmlenc11#rsa-oaep"
   • http://www.w3.org/2001/04/xmlenc#rsa-1_5"

   באיחוד שירותי אימות הזהות של עומסי עבודה אפשר להשתמש באלגוריתמים הבאים להצפנת בלוקים:

   • http://www.w3.org/2001/04/xmlenc#aes128-cbc
   • http://www.w3.org/2001/04/xmlenc#aes192-cbc
   • http://www.w3.org/2001/04/xmlenc#aes256-cbc
   • http://www.w3.org/2009/xmlenc11#aes128-gcm
   • http://www.w3.org/2009/xmlenc11#aes256-gcm

גישה ישירה למשאבים

אתם יכולים לתת גישה לזהות מאוחדת ישירות במשאבים באמצעות מסוף Cloud de Confiance או ה-CLI של gcloud.

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

1. כדי ליצור חשבון שירות לעומס העבודה החיצוני:

   1. מפעילים את ממשקי ה-API של IAM,‏ Security Token Service ו-Service Account Credentials, אם הם עדיין לא מופעלים.

      התפקידים שנדרשים כדי להפעיל ממשקי API

      כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

      הפעלת ממשקי ה-API

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

   3. הענקת גישה לחשבון השירות למשאבים שאליהם רוצים שלזהויות חיצוניות תהיה גישה.

2. כדי לאפשר לזהות המאוחדת להתחזות לחשבון השירות:

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

פרטי כניסה שהתקבלו מקובץ הפעלה

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --sts-location=REGION \
    --output-file=FILEPATH.json \
    --executable-command=EXECUTABLE_COMMAND \
    --executable-timeout-millis=EXECUTABLE_TIMEOUT \
    --executable-output-file=EXECUTABLE_OUTPUT_FILE

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה.
• ‫POOL_ID: המזהה של מאגר הזהויות של עומסי העבודה.
• ‫WORKLOAD_PROVIDER_ID: מזהה הספק של מאגר הזהויות של עומסי העבודה.
• ‫SERVICE_ACCOUNT_EMAIL: אם אתם משתמשים בהתחזות לחשבון שירות, החליפו את הערך בכתובת האימייל של חשבון השירות. אם אתם לא משתמשים בהתחזות לחשבון שירות, אל תשתמשו בדגל הזה.
• ‫SERVICE_ACCOUNT_TOKEN_LIFETIME: אם אתם משתמשים בהתחזות לחשבון שירות, החליפו את הערך הזה במשך החיים של אסימון הגישה לחשבון השירות בשניות. אם לא ציינתם ערך, הגדרת ברירת המחדל היא שעה אחת. אם אתם לא משתמשים בהתחזות לחשבון שירות, אל תשתמשו בדגל הזה. כדי לציין משך חיים ארוך יותר משעה אחת, צריך להגדיר את אילוץ המדיניות הארגונית ‏constraints/iam.allowServiceAccountCredentialLifetimeExtension.
• ‫REGION: אופציונלי. מציינים את האזור של נקודות הקצה האזוריות של Security Token Service, אם הן זמינות.
• ‫FILEPATH: הקובץ שבו שומרים את התצורה.
• EXECUTABLE_COMMAND: הפקודה המלאה, כולל ארגומנטים, שמריצים כדי לאחזר את האסימון המזהה של OIDC, לדוגמה: --executable-command="/path/to/command --foo=bar".
• EXECUTABLE_TIMEOUT: משך הזמן האופציונלי באלפיות השנייה כדי להמתין להרצה של קובץ ההפעלה (ברירת המחדל היא 30 שניות).
• EXECUTABLE_OUTPUT_FILE: נתיב שמפנה לפרטי הכניסה 3PI שקובץ ההפעלה יצר. כדאי להיעזר בזה אם רוצים לשמור במטמון את פרטי הכניסה. כשמציינים את הנתיב הזה, ספריות Auth (אימות) יבדקו קודם אם הוא קיים לפני שיריצו את קובץ ההפעלה.

פרטי כניסה שהתקבלו מקובץ

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --sts-location=REGION \
    --output-file=FILEPATH.json \
    --credential-source-file=TOKEN_FILEPATH \
    --credential-source-type=SOURCE_TYPE \
    --credential-source-field-name=FIELD_NAME

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה.
• ‫POOL_ID: המזהה של מאגר הזהויות של עומסי העבודה.
• ‫WORKLOAD_PROVIDER_ID: מזהה הספק של מאגר הזהויות של עומסי העבודה.
• ‫SERVICE_ACCOUNT_EMAIL: אם אתם משתמשים בהתחזות לחשבון שירות, החליפו את הערך בכתובת האימייל של חשבון השירות. אם אתם לא משתמשים בהתחזות לחשבון שירות, אל תשתמשו בדגל הזה.
• ‫SERVICE_ACCOUNT_TOKEN_LIFETIME: אם אתם משתמשים בהתחזות לחשבון שירות, החליפו את הערך הזה במשך החיים של אסימון הגישה לחשבון השירות בשניות. אם לא ציינתם ערך, הגדרת ברירת המחדל היא שעה אחת. אם אתם לא משתמשים בהתחזות לחשבון שירות, אל תשתמשו בדגל הזה. כדי לציין משך חיים ארוך יותר משעה אחת, צריך להגדיר את אילוץ המדיניות הארגונית ‏constraints/iam.allowServiceAccountCredentialLifetimeExtension.
• ‫REGION: אופציונלי. מציינים את האזור של נקודות הקצה האזוריות של Security Token Service, אם הן זמינות.
• ‫FILEPATH: הקובץ שבו שומרים את ההגדרות האישיות.
• ‫TOKEN_FILEPATH: הנתיב שבו שמורים טוקנים של מזהה של OIDC.
• ‫SOURCE_TYPE: פורמט הקובץ של אסימון מזהה של OIDC, שמוגדר ל-text (ברירת המחדל) או ל-json.
• ‫FIELD_NAME: השדה בקובץ הטקסט שמכיל את האסימון (אם SOURCE_TYPE הוא json).

פרטי כניסה שהתקבלו מכתובת URL

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --sts-location=REGION \
    --output-file=FILEPATH.json \
    --credential-source-url="TOKEN_URL" \
    --credential-source-headers="KEY_1=VALUE_1,KEY_2=VALUE_2" \
    --credential-source-type=SOURCE_TYPE \
    --credential-source-field-name=FIELD_NAME

מחליפים את מה שכתוב בשדות הבאים:

• PROJECT_NUMBER: מספר הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה.
• ‫POOL_ID: מזהה מאגר הזהויות של עומסי העבודה.
• ‫WORKLOAD_PROVIDER_ID: מזהה הספק של מאגר הזהויות של עומסי העבודה
• ‫SERVICE_ACCOUNT_EMAIL: אם אתם משתמשים בהתחזות לחשבון שירות, החליפו את הערך בכתובת האימייל של חשבון השירות. אם אתם לא משתמשים בהתחזות לחשבון שירות, אל תשתמשו בדגל הזה.
• ‫SERVICE_ACCOUNT_TOKEN_LIFETIME: אם אתם משתמשים בהתחזות לחשבון שירות, החליפו את הערך הזה במשך החיים של אסימון הגישה לחשבון השירות בשניות. אם לא ציינתם ערך, הגדרת ברירת המחדל היא שעה אחת. אם אתם לא משתמשים בהתחזות לחשבון שירות, אל תשתמשו בדגל הזה. כדי לציין משך חיים ארוך יותר משעה אחת, צריך להגדיר את אילוץ המדיניות הארגונית ‏constraints/iam.allowServiceAccountCredentialLifetimeExtension.
• ‫REGION: אופציונלי. מציינים את האזור של נקודות הקצה האזוריות של Security Token Service, אם הן זמינות.
• ‫FILEPATH: הקובץ שבו שומרים את התצורה.
• TOKEN_URL: כתובת URL שממנה מאחזרים טוקן של מזהה OIDC
• KEY_n, VALUE_n: כותרות מותאמות אישית שצריך לכלול בבקשת HTTP ל-TOKEN_URL
• ‫SOURCE_TYPE: פורמט הקובץ של אסימון מזהה של OIDC, שמוגדר ל-text (ברירת המחדל) או ל-json
• FIELD_NAME: שדה בקובץ הטקסט שמכיל את האסימון (אם SOURCE_TYPE הוא json)