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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • מה מספרי הפרויקטים שקשורים לאירוע?

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

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

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

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

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

  • איפה צריך לאחסן את הפלט, והאם צריך להצפין אותו?

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

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

בניית פתרון Confidential Space

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

בשלב הראשוני של בניית האתר, מומלץ לפעול לפי השיטות הבאות:

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

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

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

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

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

כדאי להיזהר מהפלט

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

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

יצירת תמונה בקונטיינר באמצעות Docker

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

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

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

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

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

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

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

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

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

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

ב-Confidential Space אפשר להוסיף שטחי אחסון זמניים בזיכרון. הפעולה הזו משתמשת בזיכרון שזמין במכונה הווירטואלית של 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: אף פעם לא לאפשר מעקב אחר השימוש בזיכרון.

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

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

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

קבוצות cgroup עם מרחב שמות

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

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

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

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

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

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

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

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

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

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

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

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

"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 בנושא קובץ אימג' חתום של קונטיינר.