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

שותפי עריכה של נתונים

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

• נתונים מוצפנים, שמאוחסנים ב- Google Cloud.

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

בנוסף, שותפי הנתונים צריכים לבחור איפה לאחסן את התוצאות של עומס העבודה ב-Confidential Space, ואם התוצאות האלה יהיו ייחודיות לכל שותף או משותפות. לדוגמה, אתם יכולים לבחור להוציא את אותה תוצאה לכמה קטגוריות של Cloud Storage ששייכות לכל אחד מהשותפים בנתונים.

הערה: אם המשאבים של שותפי המידע לא מנוהלים על ידי Google CloudIAM, אפשר לנהל את הגישה למשאבים האלה על ידי בקשה של אסימוני אימות עם קהלים בהתאמה אישית ומספרי nonce אופציונליים. כדי להטמיע את זה, צריך לפנות ליוצר של עומס העבודה. למידע נוסף, קראו את המאמר גישה למשאבים שלא מנוהלים על ידי Google Cloud IAM.

אחסון הנתונים המוצפנים

אתם יכולים להשתמש בכל שירות של Google Cloud שמאחסן נתונים כדי לארח את הנתונים הסודיים שלכם. לדוגמה, אתם יכולים להשתמש באחד מהשירותים הבאים:

• BigQuery

• Cloud SQL

• Cloud Storage

• Filestore

• Persistent Disk

חשוב לוודא שהנתונים האלה מוצפנים במנוחה, באמצעות תכונות מובנות או באמצעות שירות כמו Cloud Key Management Service ‏ (Cloud KMS).

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

אישור עומס העבודה באמצעות WIP

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

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

• שירות אימות (attestation): השירות הזה מאמת שעומס העבודה הוא Confidential VMs, ובסופו של דבר מחזיר אסימון אימות של OpenID Connect (OIDC) לספק ה-WIP. מפעיל עומס העבודה מגדיר את שירות האימות שבו משתמשים, והוא חייב להתאים לשירות האימות שנוסף לספק ה-WIP כדי שתהיה גישה.

• מיפוי מאפיינים: מאפיינים בטוקני גישה של שירות אבטחת הטוקנים שממופים לטענות נכונות של הישות המאמתת – במקרה הזה, המכונה הווירטואלית שמריצה את עומס העבודה. הטענות מועלות על ידי מכונת ה-VM עצמה, קובץ האימג' של Confidential Space והקונטיינר של עומס העבודה, ומועברות לספק ה-WIP על ידי עומס העבודה. המאפיינים האלה משמשים לדברים כמו נתיבי ביקורת ב-Cloud Logging, ולהקצאת תפקידים באמצעות IAM על סמך טענות נכוֹנוּת (assertions) של ישויות אימות, כמו תקצירי מאגרים של קובצי אימג' של קונטיינרים של עומסי עבודה. מידע נוסף על מיפוי מאפיינים

• מדיניות אימות: סדרה של תנאים שישויות האימות צריכות לעמוד בהם כדי לקבל גישה, על סמך טענות הנכוֹנוּת שהן מציגות.

כשעומס עבודה מתחיל, מרכז האפליקציות של Confidential Space שולח את דוח האימות שלו לשירות אימות שמוגדר על ידי מפעיל עומס העבודה. השירות מאמת את המכונה הווירטואלית ב-Confidential VM ומחזיר אסימון אימות של OIDC. הטוקן הזה תקף לשעה אחת, ומתרענן באופן אוטומטי.

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

הערה: במקום להשתמש בשרתים של Google לאימות טוקנים, אתם יכולים לאמת טוקנים של אימות בעצמכם באמצעות אישורים לטווח ארוך.

גישה לעומסי עבודה חיצוניים

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

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

אנחנו ממליצים על שיטת הגישה הישירה למשאבים בשביל עומסי עבודה.

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

אלה היתרונות של גישה ישירה למשאבים:

• הגדרת סביבה של Confidential Space דורשת פחות שלבים, כי שותפי הנתונים לא צריכים להגדיר חשבונות שירות כדי שחשבון שירות של עומס עבודה יתחזה אליהם.

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

• כל גישה למשאב מתועדת ביומן עם הזהות המאוחדת של מכונה וירטואלית של עומס עבודה, במקום עם הזהות של חשבון שירות שהתחזה, שיכול להיות משותף לכמה עומסי עבודה. הזהות של מכונת VM של עומס עבודה יכולה לכלול פרטים כמו סיכום קריפטוגרפי של קובץ אימג' של קונטיינר, מספר הפרויקט שממנו פועל עומס העבודה ומזהה מכונת ה-VM שמריצה את עומס העבודה, וכך לספק נתיב ביקורת מפורט יותר.

• לא צריך למפות את המאפיין selfLink של המכונה הווירטואלית למאפיין google.subject בספק WIP. ערכים ארוכים מאוד של selfLink יכולים לחרוג מהמגבלה של 127 בייטים של המאפיין הזה, ולגרום לכשל באימות של ספק ה-WIP.

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

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

צריך להשתמש בהתחזות לחשבון שירות רק בתרחישים הבאים:

• כשצריך להשתמש בחתימות של תמונות בתור פרטי כניסה לאימות, כי התחביר שמשמש לחתימות לא פועל עם מיפויים של מאפיינים.

• כשניגשים לממשקי API שלא תומכים בזהויות מאוחדות.

יכול להיות ששיטת ההתחזות לחשבון שירות לא תצליח לבצע אימות מול ספק WIP אם למכונה הווירטואלית יש מאפיין selfLink ארוך מאוד. הסיבה לכך היא שההצהרה sub באסימון האימות – שמוגדרת לערך selfLink – ממופה בספק ה-WIP למאפיין google.subject, שמוגבל ל-127 בייטים.

אם הערכים של selfLink במכונות הווירטואליות גדולים מ-127 בייטים, צריך לשנות את השם של המכונות הווירטואליות כדי לקצר את selfLink, או להשתמש בשיטת הגישה הישירה למשאבים.

הגדרת WIP וספק

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

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

בשיטת הגישה הישירה למשאבים, מגדירים ספק ו-WIP, ואז מגדירים תפקידי IAM על סמך תקציר ספציפי של קובץ אימג' של קונטיינר של עומס עבודה.

הגדרת WIP וספק

כדי להגדיר WIP וספק, פועלים לפי ההוראות הבאות:

1. יוצרים את ה-WIP:

   gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
       --location=global
   

2. יוצרים ספק OIDC ב-WIP:

   gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
       --location=global \
       --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
       --issuer-uri="ISSUER_URI" \
       --allowed-audiences="https://sts.googleapis.com" \
       --attribute-mapping="google.subject=\"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest" \
       --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' \
           && 'STABLE' in assertion.submods.confidential_space.support_attributes"
   

   בדוגמה הזו נעשה שימוש בערכים הבאים:

   • issuer-uri שתואם לשירות האימות שבו אתם משתמשים:

     • ‫Google Cloud Attestation: ‏https://confidentialcomputing.googleapis.com

     • ‫Intel Trust Authority: https://portal.trustauthority.intel.com

   • ‫allowed-audiences מתוך https://sts.googleapis.com. זהו Security Token Service של Google, שממיר את פרטי הכניסה בטוקני גישה.

   • ‫attribute-mapping של google.subject, עם הערך הבא:

     \"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest
     

     הערך הזה נוצר באמצעות Common Expression Language ‏(CEL). הערכים הבאים מוקצים למאפיין gcpcs, ומופיעים ב-Cloud Logging בכל פעם שעומס העבודה ניגש למשאבים:

     • ‫assertion.submods.container.image_digest: תקציר קובץ האימג' של קונטיינר עומס העבודה.

     • ‫assertion.submods.gce.project_number: מספר הפרויקט של המכונה הווירטואלית.

     • ‫assertion.submods.gce.instance_id: המזהה של המכונה הווירטואלית.

     בנוסף, הערך של attribute.image_digest מוגדר ל-assertion.submods.container.image_digest, תקציר קובץ האימג' של קונטיינר עומס העבודה. המאפיין הזה ממופה כדי שתוכלו להקצות לזהות המאוחדת תפקידי IAM על סמך תקציר תמונה ספציפי.

     אתם יכולים למפות כל אחת מטענות הנכונות של עומס העבודה, כל עוד האורך הכולל של הערך google.subject קטן מ-127 בייטים.

   • הערכים הבאים של attribute-conditions, שיוצרים מדיניות אימות. אם התנאים האלה תואמים לטענות הנכונות של עומס העבודה, עומס העבודה יכול לגשת למשאבים הסודיים כזהות מאוחדת:

     • assertion.swname == 'CONFIDENTIAL_SPACE': אימות ש-Confidential Space היא התוכנה שפועלת במכונה הווירטואלית, עם כל אמצעי האבטחה המובנים שלה.

     • ‫'STABLE' in assertion.submods.confidential_space.support_attributes: מוודא שנעשה שימוש בתמונה של Confidential Space בסביבת הייצור, ושיש לה את מאפיין התמיכה STABLE.

     במאמר יצירת מדיניות אימות מפורטים תנאים נוספים של מאפיינים שאפשר להשתמש בהם.

הקצאת תפקידי IAM לזהות המאוחדת

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

בדוגמה הבאה מוסבר איך נותנים לזהות מאוחדת את היכולת לפענח מפתח ספציפי של Cloud Key Management Service:

gcloud kms keys add-iam-policy-binding \
    projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
    --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/attribute.image_digest/WORKLOAD_CONTAINER_IMAGE_DIGEST" \
    --role=roles/cloudkms.cryptoKeyDecrypter

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

השיטה של התחזות לחשבון שירות כוללת את השלבים הבאים:

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

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

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

הגדרת חשבונות שירות לפענוח נתונים סודיים

1. יוצרים את חשבונות השירות בפרויקטים של שותפי המידע:

   gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME
   

   נותנים לחשבונות השירות את ההרשאות שנדרשות כדי לפענח את הנתונים הסודיים. לדוגמה, יכול להיות שאתם מצפינים קבצים סודיים ב-Cloud Storage באמצעות Cloud KMS, ולכן אתם צריכים לתת לחשבון השירות הרשאה לפענח את הנתונים האלה:

   gcloud kms keys add-iam-policy-binding \
       projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
       --member=serviceAccount:DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/cloudkms.cryptoKeyDecrypter
   

הגדרת WIP וספק

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

1. יוצרים את ה-WIP:

   gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
       --location=global
   

2. מקשרים את חשבון השירות שרוצים להתחזות אליו ל-WIP, עם התפקיד roles/iam.workloadIdentityUser:

   gcloud iam service-accounts add-iam-policy-binding \
       DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
       --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/*" \
       --role=roles/iam.workloadIdentityUser
   

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

   gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
       --location=global \
       --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
       --issuer-uri="https://confidentialcomputing.googleapis.com/" \
       --allowed-audiences="https://sts.googleapis.com" \
       --attribute-mapping="google.subject=assertion.sub" \
       --attribute-condition="assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST' \
   && 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts \
   && assertion.swname == 'CONFIDENTIAL_SPACE' \
   && 'STABLE' in assertion.submods.confidential_space.support_attributes"
   

   בדוגמה הזו נעשה שימוש בערכים הבאים:

   • הערך https://confidentialcomputing.googleapis.com/ בשדה issuer-uri, כלומר שירות האימות הוא Google Cloud Attestation.

   • ‫allowed-audiences מתוך https://sts.googleapis.com. זהו Security Token Service של Google, שממיר את פרטי הכניסה בטוקני גישה.

   • ‫attribute-mapping של google.subject, עם הערך assertion.sub. זהו ה-selfLink של המכונה הווירטואלית, כפי שמוגדר בטענת הנכוֹנוּת (claim) של sub באסימון האימות.

     מכונת ה-VM‏ selfLink מופיעה ב-Cloud Logging בכל פעם שעומס העבודה ניגש למשאבים.

   • הערכים הבאים של attribute-conditions, שיוצרים מדיניות אימות. אם התנאים האלה תואמים לטענות הנכונות (assertions) של עומס העבודה, עומס העבודה יכול לגשת למשאבים כזהות מאוחדת:

     • ‫assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': מאמת שהתקציר של קובץ האימג' של הקונטיינר של עומס העבודה תואם לערך הצפוי.

     • ‫'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts: מאמת שחשבון השירות שמצורף לעומס העבודה תואם לחשבון השירות הצפוי, ואז משתמש בו כדי להתחזות לחשבון השירות של שותף המידע.

     • assertion.swname == 'CONFIDENTIAL_SPACE': אימות ש-Confidential Space היא התוכנה שפועלת במכונה הווירטואלית, עם כל אמצעי האבטחה המובנים שלה.

     • ‫'STABLE' in assertion.submods.confidential_space.support_attributes: מוודא שנעשה שימוש בתמונה של Confidential Space בסביבת הייצור, ושיש לה את מאפיין התמיכה STABLE.

     במאמר יצירת מדיניות אימות מפורטים תנאים נוספים של מאפיינים שאפשר להשתמש בהם.

יצירת מדיניות אימות

כחלק מיצירת WIP, צריך ליצור מדיניות אימות. כדי לקבל גישה לנתונים, טענות הנכוֹנוּת של ישות האימות צריכות להתאים למדיניות שלכם.

כללי המדיניות כתובים ב-Common Expression Language (CEL), והם מורכבים מסדרה של הצהרות שאפשר לשרשר יחד באמצעות האופרטור &&.

ההצהרות משתמשות בטענות נכונות (assertions) מקובץ האימג' של Confidential Space, מקובץ האימג' של קונטיינר עומס העבודה או ממכונה וירטואלית כמשתנים, ובערך שציינתם כביטוי. לדוגמה, הנה מדיניות שאוכפת את השימוש של עומס העבודה ב-Confidential Space, מחייבת שימוש בתמונת Confidential Space של STABLE ומחייבת שהאזור שבו פועל המכונה הווירטואלית של עומס העבודה יהיה us-central1-a:

assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes" \
&& assertion.submods.gce.zone == "us-central1-a"

מידע נוסף זמין במאמר בנושא טענות נכונות (assertion) של אימות.

טענות נכונות (assertions) של אימות (attestation)

בטבלה הבאה מפורטות ההצהרות הזמינות ליצירת מדיניות אימות. כללי המדיניות יכולים לאמת טענות נכוֹנוּת (assertions) שנוצרו על ידי קובץ האימג' של Confidential Space, קונטיינר עומס העבודה והמכונה הווירטואלית.

הצהרות לגבי תמונות

טענת נכוֹנוּת (assertion)	סוג	תיאור
assertion.dbgstat אינטראקציה עם: מפעיל של עומס עבודה: הערך של --image-family.	ערכי ספירה	מאמת שהתמונה של Confidential Space היא גרסת ניפוי הבאגים או גרסת הייצור. הערכים התקינים הם: ‫enable: מוודאים שנעשה שימוש בתמונת ניפוי הבאגים. disabled-since-boot: מוודאים שמשתמשים בתמונת הייצור. דוגמאות הקוד הבא מאמת שנעשה שימוש בגרסת ניפוי הבאגים של קובץ האימג' של Confidential Space: assertion.dbgstat == "enable" הקוד הבא מאמת שנעשה שימוש בגרסת הייצור של קובץ האימג' של Confidential Space: assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes	מערך של מחרוזות	אימות שגרסת האבטחה של ה-TEE היא תמונה של Confidential Space בסביבת ייצור. לתמונות של Confidential Space לניפוי באגים אין מאפיין תמיכה מוגדר. בטבלה הבאה מתוארים מאפייני התמיכה שנמצאים בתמונות של Confidential Space בסביבת הייצור. מאפיין תמיכה תיאור LATEST לתמונות של LATEST יש גם את מאפייני התמיכה הבאים: STABLE USABLE משך החיים של התמונה: בערך חודש. אחרי התאריך הזה, מאפיין התמיכה LATEST יוסר. זו הגרסה העדכנית של התמונה של Confidential Space, והיא נתמכת ומנוטרת כדי לאתר נקודות חולשה. בעומסי עבודה שפועלים לאורך זמן, מומלץ לא לציין את LATEST כחלק ממדיניות האימות. הסיבה לכך היא שהתמונה של Confidential Space עשויה להתעדכן בזמן שעומס העבודה פועל, כך שהתמונה של Confidential Space שבה אתם משתמשים כבר לא תהיה LATEST, ועומס העבודה ייכשל באימות כשהאסימון שמוגדר כברירת מחדל של Confidential Space יתעדכן בפעם הבאה. STABLE לתמונות של STABLE יש גם את מאפייני התמיכה הבאים: USABLE משך החיים של התמונה: כחצי שנה. החל מ-1 באפריל 2027, מאפיין התמיכה STABLE יוסר אחרי שתוקף התמונה יפוג. תמונות עם המאפיין STABLE נתמכות ומנוטרות לאיתור נקודות חולשה למשך שישה חודשים. מומלץ לכתוב מדיניות אימות שמבוססת על המאפיין STABLE. במקרים נדירים, יכול להיות שהמאפיין STABLE יוסר במהלך תקופת הזכאות לתמיכה הרגילה של שישה חודשים, למשל אם מתגלות נקודות חולשה קריטיות. USABLE עדיין אפשר להשתמש בתמונות עם המאפיין USABLE בלבד, אבל הן נחשבות ככאלה שהוצאו משימוש. תמונות שהוצאו משימוש לא נתמכות, והן בנות יותר משישה חודשים. השימוש בהם הוא באחריותכם בלבד. לתמונות USABLE יש מאפיין deprecated.deprecated. הערך שלו הוא חותמת הזמן של המועד שבו התמונה צפויה לצאת משימוש. אפשר להציג את המאפיינים של תמונה באמצעות הפקודה gcloud compute images describe או באמצעות ה-method‏ images.get ב-REST. לדוגמה: gcloud compute images describe confidential-space-240800 \ --format=json \ --project=confidential-space-images EXPERIMENTAL תמונות שכוללות רק את המאפיין הזה משתמשות בתכונות בגרסת טרום-השקה (Preview). EXPERIMENTAL מיועדות למטרות בדיקה בלבד, ואסור להשתמש בהן בסביבת ייצור. לתמונה מסוג EXPERIMENTAL אף פעם אין את המאפיינים LATEST,‏ STABLE או USABLE. מומלץ לעדכן את קובץ האימג' של Confidential Space באופן שוטף. במאמר עדכון קובצי אימג' של Confidential Space מוסבר איך לעדכן את קובץ האימג' של Confidential Space. חשוב: יכול להיות שתמונות של Confidential Space יבוטלו בגלל אירועים כמו גילוי של נקודות חולשה קריטיות. כשהאישור של קובץ אימג' מבוטל, הטענה swname באסימון האימות מוגדרת כ-GCE, או שעומס העבודה מקבל הודעת RIMS_VALIDATION_FAILED כשמבקשים את האסימון. דוגמה הקוד הבא מאמת שנעשה שימוש בגרסה יציבה של קובץ האימג' של Confidential Space: "STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname	ערכי ספירה	מאמת את התוכנה שפועלת בישות המאמתת. הערך הוא תמיד CONFIDENTIAL_SPACE. דוגמה assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion	מערך של מחרוזות	מאמת את גרסת התוכנה של התמונה של Confidential Space. אנחנו ממליצים להשתמש ב-assertion.submods.confidential_space.support_attributes במקום זאת כדי לטרגט את הגרסה העדכנית של תמונה. דוגמה int(assertion.swversion[0]) == 230103

טענות נכונות (assertions) של קונטיינרים

טענת נכוֹנוּת (assertion)	סוג	תיאור
assertion.submods.container.cmd_override אינטראקציה עם: מחבר עומס העבודה: מדיניות ההפעלה של allow_cmd_override. מפעיל של עומס עבודה: משתנה המטא-נתונים tee-cmd.	מערך של מחרוזות	אימות של הפקודות והפרמטרים של CMD שמשמשים בתמונת עומס העבודה. דוגמאות הקוד הבא מאמת שה-CMD של קובץ האימג' של עומס העבודה לא הוחלף: size(assertion.submods.container.cmd_override) == 0 הקוד הבא מוודא ש-program הוא התוכן היחיד בשינויים של CMD: assertion.submods.container.cmd_override == ['program']
assertion.submods.container.env אינטראקציה עם: מחבר עומס העבודה: מדיניות ההשקה של allow_env_override. ‫Workload operator: משתנה המטא-נתונים tee-env-ENVIRONMENT_VARIABLE_NAME .	אובייקט JSON	מוודא שמשתני הסביבה והערכים שלהם הועברו באופן מפורש לקונטיינר. דוגמה הקוד הבא מוודא שמשתנה הסביבה example-env-1 מוגדר ל-value-1, ו-example-env-2 מוגדר ל-value-2. assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}
assertion.submods.container.env_override אינטראקציה עם: מחבר עומס העבודה: מדיניות ההשקה של allow_env_override. ‫Workload operator: משתנה המטא-נתונים tee-env-ENVIRONMENT_VARIABLE_NAME .	String	בודק אם מפעיל עומס העבודה החליף את משתני הסביבה בקונטיינר. דוגמאות הקוד הבא מוודא שמפעיל עומס העבודה לא שינה את משתנה הסביבה example: !has(assertion.submods.container.env_override.example) הקוד הבא מוודא שמפעיל עומס העבודה לא החליף אף משתנה סביבה: size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest	String	מאמת את תקציר התמונה של קונטיינר עומס העבודה. הגדרת התנאי הזה מאפשרת לכמה גורמים להסכים על עומס עבודה מורשה שיכול לגשת לנתונים שלהם. דוגמה assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id	String	מאמת את מזהה התמונה של קונטיינר עומס העבודה. דוגמה assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"
assertion.submods.container.image_reference אינטראקציה עם: ‫Workload operator: משתנה המטא-נתונים tee-image-reference.	String	אימות המיקום של קונטיינר עומס העבודה שפועל מעל התמונה של Confidential Space. דוגמה assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"
assertion.submods.container.image_signatures אינטראקציה עם: ‫Workload operator: משתנה המטא-נתונים tee-signed-image-repos.	אובייקט JSON	הפונקציה מאמתת שלתמונה יש חתימה מסוימת או שהיא חתומה על ידי מפתח ציבורי ואלגוריתם חתימה. הגדרת התנאי הזה מאפשרת לכמה גורמים להסכים על עומס עבודה מורשה שיכול לגשת לנתונים שלהם. הטענה יכולה לכלול את הרכיבים הבאים: ‫key_id: טביעת האצבע ההקסדצימלית של המפתח הציבורי. כדי לקבל את טביעת האצבע, אפשר להריץ את הפקודה הבאה: openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256 כאשר public_key.pem הוא המפתח הציבורי בפורמט PEM. ‫signature: החתימה על מטען ייעודי (payload) שמשויך לקונטיינר החתום, בהתאם ל פורמט Simple Signing. ‫signature_algorithm: האלגוריתם שמשמש לחתימה על המפתח. אחת מהאפשרויות הבאות: RSASSA_PSS_SHA256 (RSASSA-PSS עם תקציר SHA-256) RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 עם תקציר SHA-256) ECDSA_P256_SHA256 (ECDSA בעקומת P-256 עם תקציר SHA-256) דוגמה ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id))
assertion.submods.container.restart_policy אינטראקציה עם: ‫Workload operator: משתנה המטא-נתונים tee-restart-policy.	ערכי ספירה	מאמת את מדיניות ההפעלה מחדש של מרכז האפליקציות של הקונטיינר, למקרה שעומס העבודה נפסק. הערכים התקינים הם: Never (ברירת מחדל) Always OnFailure דוגמה assertion.submods.container.restart_policy == "Never"

טענות נכונות (assertions) של VM

טענת נכוֹנוּת (assertion)	סוג	תיאור
assertion.google_service_accounts אינטראקציה עם: מפעיל של עומס עבודה: משתנה המטא-נתונים tee-impersonate-service-accounts והערך --service-account .	מערך של מחרוזות	אימות שחשבון שירות מסוים מחובר למכונה הווירטואלית שמריצה את עומס העבודה, או שהוא מופיע באמצעות tee-impersonate-service-accounts במטא-נתונים של המכונה הווירטואלית. דוגמה [e-mail] in assertion.google_service_accounts
assertion.hwmodel	String	מאמת את טכנולוגיית Confidential Computing הבסיסית. אלה הפלטפורמות הנתמכות: GCP_AMD_SEV INTEL_TDX דוגמה assertion.hwmodel == "GCP_AMD_SEV"
assertion.submods.confidential_space.monitoring_enabled אינטראקציה עם: יוצר עומס העבודה: מדיניות ההשקה של monitoring_memory_allow. מפעיל של עומס עבודה: משתנה המטא-נתונים tee-monitoring-memory-enable.	בוליאני	אימות מצב המעקב בישות המאשרת. דוגמה assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id	String	מאמת את המזהה של המכונה הווירטואלית. דוגמה assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name	String	מאמת את השם של המכונה הווירטואלית. דוגמה assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id	String	בדיקה שהמכונה הווירטואלית מריצה פרויקט Google Cloud עם מזהה הפרויקט שצוין. דוגמה assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number	String	בדיקה שהמכונה הווירטואלית פועלת בפרויקט ב- Google Cloud עם מספר הפרויקט שצוין. דוגמה assertion.submods.gce.project_number == "00000000000"
assertion.submods.gce.zone אינטראקציה עם: מפעיל של עומס עבודה: הערך של --zone.	String	מוודא שהמכונה הווירטואלית פועלת באזור שצוין. דוגמה assertion.submods.gce.zone == "us-central1-a"
assertion.submods.nvidia_gpu.cc_feature אינטראקציה עם: ‫Workload operator: משתנה המטא-נתונים tee-install-gpu-driver.	ערכי ספירה	מאמת את התכונות של Confidential Computing שנתמכות על ידי NVIDIA GPU. ב-Confidential Space יש תמיכה רק במצב מעבר GPU יחיד (SPT), כך שהערך הוא תמיד SPT. למידע נוסף על התמיכה של NVIDIA ב-Confidential Computing, קראו את המאמר NVIDIA Trusted Computing Solutions (PDF). דוגמה assertion.submods.nvidia_gpu.cc_feature == "SPT"
assertion.submods.nvidia_gpu.cc_mode אינטראקציה עם: ‫Workload operator: משתנה המטא-נתונים tee-install-gpu-driver.	ערכי ספירה	מאמת את הסטטוס של מנהל ההתקן של NVIDIA למחשוב סודי. הערכים התקינים הם: ‫OFF: אף אחת מהתכונות של NVIDIA Confidential Computing לא פעילה. ‫ON: החומרה, הקושחה והתוכנה של NVIDIA H100 הפעילו באופן מלא את התכונות של Confidential Computing. ‫DEVTOOLS: ה-GPU נמצא במצב חלקי של Confidential Computing שתואם לתהליכי העבודה של מצב ON, אבל משבית את אמצעי ההגנה. דוגמה assertion.submods.nvidia_gpu.cc_mode == "ON"
assertion.submods.nvidia_gpu.gpus אינטראקציה עם: ‫Workload operator: משתנה המטא-נתונים tee-install-gpu-driver.	מערך של אובייקטים	מאמת את הטענות לגבי כל GPU מאושר של NVIDIA. ב-Confidential Space אפשר להצהיר רק על GPU אחד. אובייקט gpus נראה בערך כך: { "hwmodel": "GCP_NVIDIA_H100", "ueid": "490457405999046854973671575630853621547794591064", "l4_serial_number": "1216669666319372030078", "driver_version": "570.00", "vbios_version": "96.00.9F.00.01" } דוגמאות הקוד הבא מוודא שמודל החומרה הראשון של ה-GPU הוא NVIDIA H100 שפועל ב- Google Cloud: assertion.submods.nvidia_gpu.gpus[0].hwmodel == "GCP_NVIDIA_H100" הקוד הבא מאמת שהצהרת האימות כוללת הצהרות שקשורות ל-GPU: has(assertion.submods.nvidia_gpu.gpus)