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

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

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

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

  • קובץ אימג' של קונטיינר כדי לארוז את האפליקציה באמצעות Docker.

  • מאגר ב-Artifact Registry לאחסון קובץ האימג' של Docker.

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

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

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

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

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

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

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

  • מהם מזהי הארגונים המעורבים?

  • מהם מספרי הפרויקטים הרלוונטיים?

  • מהם המשאבים ב- Google Cloud שאני צריך לגשת אליהם, ומהם המזהים והשמות שלהם?

  • האם יש משאבים שצריך לגשת אליהם שלא מנוהלים על ידי IAM של Google Cloud?

  • באיזה שירות אימות אתם רוצים להשתמש, Google Cloud Attestation או Intel Trust Authority?

  • איך האפליקציה צריכה להשוות ולעבד את הנתונים הפרטיים?

  • באיזה פורמט הפלט צריך להיות?

  • איפה לשמור את הפלט, והאם להצפין אותו?

  • האם כל שותפי הנתונים רואים את אותה תוצאה, או שהתוצאות ייחודיות לכל אחד?

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

פיתוח פתרון Confidential Space

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

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

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

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

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

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

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

חשוב להיזהר עם הפלט

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

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

יצירת קובץ אימג' של קונטיינר באמצעות Docker

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

כשיוצרים קובץ אימג' של Docker, חשוב להביא בחשבון את הדברים הבאים:

יכולות נוספות של Linux

עומס העבודה של Confidential Space פועל בקונטיינר של Linux באמצעות containerd. הקונטיינר הזה פועל באמצעות יכולות ברירת המחדל של Linux.

כדי להוסיף יכולות, אפשר להשתמש ב-tee-added-capabilities.

מגבלות הדיסק והזיכרון

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

כחלק מההגנות על מערכת הקבצים של Confidential Space, תגי התקינות של הדיסק נשמרים בזיכרון. הפעולה הזו צורכת כ-1% מתקורה של הזיכרון לכל בייט בדיסק. לדוגמה, דיסק בנפח 100GB דורש זיכרון בנפח 1GB, ודיסק בנפח 10TB דורש זיכרון בנפח 100GB.

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

כיבויים מבוקרים

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

נקודות טעינה זמניות בזיכרון

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

אפשר להשתמש ב-tee-dev-shm-size כדי להגדיל את הנפח של נקודת הטעינה של הזיכרון המשותף /dev/shm לעומס העבודה. הגודל של /dev/shm מצוין ב-KB.

אפשר להשתמש ב-tee-mount כדי לציין נקודות טעינה של tmpfs בקונטיינר שפועל, באמצעות הגדרות שמופרדות בנקודה ופסיק. הערכים של type ו-source הם תמיד tmpfs. destination היא נקודת הטעינה, שמקיימת אינטראקציה עם מדיניות ההפעלה של tee.launch_policy.allow_mount_destinations. אפשר גם לציין את הגודל של tmpfs בבייטים. גודל ברירת המחדל הוא 50% מזיכרון ה-VM.

יציאות נכנסות

כברירת מחדל, המכונות הווירטואליות של Confidential Space פועלות עם כלל חומת אש שחוסם את כל היציאות הנכנסות. כשמשתמשים בגרסת אימג' של Confidential Space מ-230600 ואילך, אפשר לציין יציאות נכנסות שיישארו פתוחות ב-Dockerfile כשיוצרים את אימג' עומס העבודה.

כדי לפתוח יציאות, מוסיפים את מילת המפתח EXPOSE ל-Dockerfile, יחד עם מספר היציאה שרוצים להשאיר פתוחה ופרוטוקול אופציונלי של tcp או udp. אם לא מציינים את הפרוטוקול של היציאה, גם TCP וגם UDP מותרים. הנה דוגמה Dockerfile שחושפת יציאות נכנסות:

FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []

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

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

יציאות חשופות מתועדות ביומן במסוף ומופנות ל-Cloud Logging כשמשתמשים במשתנה המטא-נתונים tee-container-log-redirect.

מדיניות ההשקה

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

לדוגמה, בDockerfile:

LABEL "tee.launch_policy.allow_cmd_override"="true"

בקובץ BUILD של Bazel:

container_image(
    ...
    labels={"tee.launch_policy.allow_cmd_override":"true"}
    ...
)

מדיניות ההשקה הזמינה מפורטת בטבלה הבאה:

מדיניות סוג תיאור

tee.launch_policy.allow_capabilities

אינטראקציה עם:

 ערך בוליאני (ברירת המחדל היא false) ההגדרה קובעת אם מפעיל עומס העבודה יכול להוסיף יכולות Linux נוספות לקונטיינר של עומס העבודה.

tee.launch_policy.allow_cgroups

אינטראקציה עם:

  • מפעיל של עומס עבודה: משתנה המטא-נתונים tee-cgroup-ns.
 ערך בוליאני (ברירת המחדל היא false) ההגדרה קובעת אם קונטיינר של עומס עבודה יכול לכלול טעינה של cgroup עם מרחב שמות ב-/sys/fs/cgroup.

tee.launch_policy.allow_cmd_override

אינטראקציה עם:

  • מפעיל של עומס עבודה: משתנה המטא-נתונים tee-cmd.
  • שותפי עריכה של נתונים: הטענה container.cmd_override.
 ערך בוליאני (ברירת המחדל היא false) ההגדרה קובעת אם מפעיל עומס העבודה יכול לשנות את הערך של CMD שצוין ב-Dockerfile של מאגר עומס העבודה, באמצעות ערך המטא-נתונים tee-cmd.

tee.launch_policy.allow_env_override

אינטראקציה עם:

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

tee.launch_policy.allow_mount_destinations

אינטראקציה עם:

  • מפעיל של עומס עבודה: משתנה המטא-נתונים tee-mount.
 מחרוזת מופרדת בנקודתיים

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

לדוגמה: /run/tmp:/var/tmp:/tmp

tee.launch_policy.log_redirect

אינטראקציה עם:

 מחרוזת מוגדרת

המדיניות קובעת איך הרישום ביומן פועל אם tee-container-log-redirect מוגדרת לערך true על ידי מפעיל עומס העבודה.

הערכים התקינים הם:

  • ‫debugonly (ברירת המחדל): מותר לבצע הפניות אוטומטיות רק אל stdout ואל stderr כשמשתמשים בתמונת ניפוי באגים.
  • ‫always: תמיד לאפשר הפניות אוטומטיות של stdout ו-stderr.
  • ‫never: אף פעם לא לאפשר הפניות אוטומטיות של stdout ו-stderr.

tee.launch_policy.monitoring_memory_allow

אינטראקציה עם:

 מחרוזת מוגדרת

המדיניות קובעת איך פועל המעקב אחרי השימוש בזיכרון של עומס העבודה אם המדיניות tee-monitoring-memory-enable מוגדרת לערך true על ידי מפעיל של עומס עבודה.

הערכים התקינים הם:

  • ‫debugonly (ברירת מחדל): אפשר לעקוב אחרי השימוש בזיכרון רק כשמשתמשים בתמונת ניפוי באגים.
  • ‫always: תמיד לאפשר מעקב אחרי השימוש בזיכרון.
  • ‫never: אף פעם לא לאפשר מעקב אחרי השימוש בזיכרון.

tee.launch_policy.nonroot_container

אינטראקציה עם:

 מחרוזת מוגדרת

קובעת אם להגביל את הרשאות ההפעלה של הקונטיינר.

הערכים התקינים הם:

  • unrestricted (ברירת המחדל): המחבר של עומס העבודה מאפשר לקונטיינר לפעול כמשתמש root או כמשתמש שאינו root. מפעיל עומס העבודה בוחר באמצעות tee-nonroot-container.
  • ‫nonrootonly: מחבר עומס העבודה דורש שהקונטיינר יפעל כמשתמש Root. מפעיל עומס העבודה צריך להגדיר את tee-nonroot-container לערך true, אחרת המכונה הווירטואלית לא תצליח להפעיל את עומס העבודה.

הרצה של כמה עומסי עבודה

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

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

קבוצות בקרה (cgroups) עם מרחבי שמות

כברירת מחדל, עומס העבודה של Confidential Space פועל בלי טעינה של cgroup.

כדי לנהל קבוצות בקרה בתוך מאגר עומס העבודה, אפשר להשתמש ב-tee-cgroup-ns. מפתח המטא-נתונים הזה מורה למכונה הווירטואלית ליצור נקודת טעינה ב-/sys/fs/cgroup במערכת הקבצים של הקונטיינר.

הרצת קונטיינר ללא הרשאות ברמת הבסיס (root)

כדי לצמצם את ההשפעה של בריחה מקונטיינר, אפשר להריץ קונטיינר כמשתמש שאינו Root. כשמפעילים הרצה של קונטיינר ללא הרשאות ברמת הבסיס, Confidential Space מגדיר מרחב שמות של משתמש ומרחב שמות של רשת ב-Linux בשביל עומס העבודה. מזהי UID ו-GID של קונטיינר 0-65535 ממופים למזהים ללא הרשאות שמתחילים ב-100000 ב-Confidential VM. תהליך שפועל כ-root בתוך הקונטיינר, או יוצא ממנו, מקבל רק גישה ללא הרשאות למכונה הווירטואלית. אין צורך להוסיף הוראת USER לקובץ Dockerfile.

כדי להריץ ללא הרשאות ברמת הבסיס, צריך להשתמש בתמונה של Confidential Space בגרסה confidential-space-261001 ואילך. אפשר להגדיר אותו כאופציונלי או כחובה:

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

  • מפעיל של עומס עבודה: מעבירים את משתנה המטא-נתונים tee-nonroot-container=true כשיוצרים את המכונה הווירטואלית. אם יוצר עומס העבודה מגדיר את nonrootonly, משתנה המטא-נתונים הזה נדרש, אחרת המכונה הווירטואלית לא תצליח להפעיל את עומס העבודה.

קובצי אימג' של קונטיינרים שניתנים לשחזור

בניית קובץ אימג' של קונטיינר באופן שניתן לשחזור יכולה לעזור להגביר את האמון בין הצדדים. אתם יכולים ליצור קובצי אימג' שניתנים לשחזור באמצעות Bazel.

משאבים שלא מנוהלים על ידי Google Cloud IAM

כדי לגשת למשאבים שלא מנוהלים על ידי Google Cloud IAM, צריך לציין קהל בהתאמה אישית בעומס העבודה.

למידע נוסף, קראו את המאמר גישה למשאבים שלא מנוהלים על ידי Google Cloud IAM.

קובצי אימג' חתומים של קונטיינרים

אתם יכולים לחתום על קובץ אימג' של קונטיינר באמצעות מפתח ציבורי, ששותף הנתונים יכול להשתמש בו לאימות במקום לציין תקציר (digest) של קובץ אימג' במדיניות ה-WIP שלו.

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

אפשר להשתמש ב-Sigstore Cosign כדי לחתום על קובץ האימג' של הקונטיינר. כדי ש-Confidential Space יוכל לאחזר את החתימות, מפעילי עומס העבודה צריכים להוסיף את פרטי החתימה למשתנה המטא-נתונים tee-signed-image-repos לפני פריסת עומס העבודה.

בזמן הריצה, החתימות נשלחות לשירות אימות לצורך אימות. שירות האימות מחזיר אסימון של טענות נכונות (claims) לאימות, שמכיל את טענות הנכונות של החתימה המאומתת. דוגמה לחתימה על תלונה:

"image_signatures": [
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key1",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256"
  },
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key2",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256",
  },
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key3",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256",
  }
]

כדי להגדיר חתימה על קובץ אימג' של קונטיינר, קראו את שיעור ה-Codelab בנושא קובץ אימג' חתום של קונטיינר.