אימות התקינות של מכונת וירטואלית במישור הבקרה של GKE

אתם יכולים לאמת את התקינות של תמונת המכונה הווירטואלית (VM) ב-Compute Engine שמשמשת את Google Kubernetes Engine‏ (GKE) למכונות וירטואליות של מישור הבקרה. בדף הזה מופיעות הוראות לצוות אבטחה שעוקב אחרי יומני רמת הבקרה כדי לאמת את הדברים הבאים:

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

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

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

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

מידע על אימות התקינות של מכונות וירטואליות

כברירת מחדל, כל המופעים של רמת הבקרה של GKE הם מכונות וירטואליות מוגנות, שהן מכונות וירטואליות מוקשחות שמשתמשות ביכולות אבטחה כמו הפעלה מאובטחת ומדודה, מודול פלטפורמה וירטואלית מהימנה (vTPM) וקושחת UEFI. בנוסף, בכל צומתי ה-GKE מופעל ניטור של התקינות, שמאמת את רצף האתחול של כל מכונה וירטואלית מוגנת בהשוואה לרצף אתחול בסיסי 'טוב'. האימות הזה מחזיר תוצאות של הצלחה או כישלון לכל שלב ברצף האתחול, ומוסיף את התוצאות האלה ל-Cloud Logging. התכונה 'מעקב אחר תקינות' מופעלת כברירת מחדל בכל אשכולות GKE ומאמתת את השלבים הבאים:

  • רצף אתחול מוקדם: מהרגע שקושחת ה-UEFI מתחילה לפעול עד שמנהל האתחול מקבל שליטה. התווסף ליומני ה-VM בשם earlyBootReportEvent.
  • רצף אתחול מאוחר: מהרגע שתוכנת האתחול מקבלת שליטה ועד שהקרנל של מערכת ההפעלה מקבל שליטה. נוסף ליומני ה-VM בתור lateBootReportEvent.

‫GKE גם מוסיף יומנים של יצירת מכונות וירטואליות במישור הבקרה ל-Logging. היומנים האלה מכילים מטא-נתונים שמזהים את המכונה וכוללים פרטים על תמונת ה-VM ורצף האתחול. ‏Cloud de Confiance מפרסמת אימות סיכום (VSA) לכל תמונת VM של מישור הבקרה של GKE במאגר gke-vsa ב-GitHub. ב-VSA נעשה שימוש בframework של in-toto לאימותים. אתם יכולים לאמת את היומנים של מכונות וירטואליות במישור הבקרה של האשכולות שלכם מול ה-VSA המתאים כדי לוודא שהצמתים במישור הבקרה הופעלו כמצופה.

ביצוע האימותים האלה יכול לעזור לכם להשיג את המטרות הבאות:

  • צריך לוודא שהתוכנה במישור הבקרה מוגנת על ידי אתחול מאובטח ומעקב אחר השלמות, שהיא תואמת לקוד המקור המיועד ושמדובר באותה תמונה שבה משתמשים לקוחות אחרים של Cloud de Confiance .
  • להגביר את האמון באבטחת מישור הבקרה של GKE.

תמחור

התכונה הזו מוצעת ב-GKE ללא עלות נוספת.

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

  • מפעילים את Cloud Logging API.

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

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של שימוש בשירות' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

    להפעלת ה-API

  • מוודאים שכבר יש לכם אשכול במצב GKE Autopilot או במצב Standard שפועלת בו גרסה 1.29 ואילך.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לאימות שלמות המכונה הווירטואלית של מישור הבקרה, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

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

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

בדיקה של שלבים ברצף האתחול שנכשלו

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

  1. נכנסים לדף Logs Explorer במסוף Cloud de Confiance :

    כניסה לדף Logs Explorer

  2. בשדה Query, מציינים את השאילתה הבאה:

    jsonPayload.@type="type.googleapis.com/cloud_integrity.IntegrityEvent"
jsonPayload.earlyBootReportEvent.policyEvaluationPassed="false" OR jsonPayload.lateBootReportEvent.policyEvaluationPassed="false"
jsonPayload.metadata.isKubernetesControlPlaneVM="true"

    אפשר גם לבדוק אם יש אירועי אתחול מוצלחים על ידי החלפת false ב-true בשאילתה הזו.

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

  4. במאגר היומנים של שלמות האתחול שנכשל, מעתיקים את הערך בשדה resource.labels.instance_id.

  5. בשדה Query, מציינים את השאילתה הבאה:

    protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.metadata.isKubernetesControlPlaneVM="true"
resource.labels.instance_id="INSTANCE_ID"
protoPayload.methodName="v1.compute.instances.insert"

    מחליפים את INSTANCE_ID בערך של השדה instance_id מהשלב הקודם.

  6. לוחצים על Run query. הערך בשדה protoPayload.metadata.parentResource.parentResourceId הוא מזהה אשכול GKE.

  7. מאתרים את השם של אשכול GKE:

    gcloud asset query \
    --organization=ORGANIZATION_ID \
    --statement="SELECT name FROM container_googleapis_com_Cluster WHERE resource.data.id='CLUSTER_ID';"

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

    • ‫ORGANIZATION_ID: המזהה המספרי שלCloud de Confiance הארגון.
    • ‫CLUSTER_ID: הערך של השדה protoPayload.metadata.parentResource.parentResourceId מהשלב הקודם.

    הפלט אמור להיראות כך:

    # lines omitted for clarity
//container.googleapis.com/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

    הפלט הזה כולל את השדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance .
    • ‫LOCATION: המיקום של האשכול.
    • ‫CLUSTER_NAME: שם האשכול.

חיפוש ובדיקה של יומני ה-VM של מישור הבקרה

יומני יצירת מכונות וירטואליות ב-Compute Engine שתואמים לאשכולות GKE מאוחסנים במאגר היומנים _Default. כדי למצוא את יומני היצירה של מכונות וירטואליות במישור הבקרה של האשכול ולאחזר את המטא-נתונים האלה, מבצעים את הפעולות הבאות:

  1. נכנסים לדף Logs Explorer במסוף Cloud de Confiance :

    כניסה לדף Logs Explorer

  2. בשדה Query, מציינים את השאילתה הבאה:

    resource.type="gce_instance"
protoPayload.methodName="v1.compute.instances.insert"
protoPayload.metadata.isKubernetesControlPlaneVM="true"

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

  4. בודקים את השדה metadata בתוצאות השאילתה. הפלט אמור להיראות כך:

    # fields omitted for clarity
"metadata": {
  "usedResources": {
    "attachedDisks": [
      {
        "sourceImageId": "9046093115864736653",
        "sourceImage": "https://www.googleapis.com/compute/v1/projects/1234567890/global/images/gke-1302-gke1627000-cos-113-18244-85-49-c-pre",
        "isBootDisk": true
      }
# fields omitted for clarity

    השדה metadata כולל את הפרטים הבאים:

    • ‫usedResources: רשימת המשאבים ששימשו ליצירת המכונה הווירטואלית.
    • ‫attachedDisks: דיסק האתחול של המכונה הווירטואלית.
    • ‫sourceImageId: המזהה הייחודי של תמונת ה-VM.
    • ‫sourceImage: כתובת ה-URL של תמונת המכונה הווירטואלית של המקור. התחביר של הערך בשדה הזה הוא https://www.googleapis.com/compute/v1/projects/PROJECT_NUMBER/global/images/IMAGE_NAME, כאשר PROJECT_NUMBER הוא מספר הפרויקט בבעלותCloud de Confianceשמארח את מכונות ה-VM של מישור הבקרה, ו-IMAGE_NAME הוא שם התמונה ששימשה לאתחול מכונת ה-VM.
    • ‫isBootDisk: מזהה בוליאני שמציין אם הדיסק הזה שימש כדיסק האתחול של המכונה הווירטואלית.

חיפוש ואימות של VSA לתמונות של מכונות וירטואליות במישור הבקרה

בקטע הזה תוכלו למצוא את ה-VSA שמתאים לתמונת מכונת ה-VM של מישור הבקרה במאגר gke-vsa ב-GitHub. אחר כך משתמשים בכלי שנקרא slsa-verifier שמופיע במסגרת Supply chain Levels for Software Artifacts‏ (SLSA) כדי לאמת את ה-VSA. תצטרכו את הנתונים הבאים מיומן היצירה של המכונה הווירטואלית של מישור הבקרה:

  • מזהה תמונת ה-VM
  • מספר הפרויקט בבעלות Cloud de Confianceשמארח את מכונות ה-VM
  • שם תמונת מערכת ההפעלה ששימשה לאתחול מכונת ה-VM

הפורמט של שם הקובץ שמתאים למכונת ה-VM של מישור הבקרה הוא:

IMAGE_NAME:IMAGE_ID.intoto.jsonl

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

  • ‫IMAGE_NAME: שם תמונת ה-VM, שהוא המחרוזת אחרי /images/ בשדה attachedDisks.sourceImage ביומן הביקורת של ה-VM מהקטע הקודם. לדוגמה, gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
  • ‫IMAGE_ID: מזהה תמונת ה-VM, שהוא הערך של השדה attachedDisks.sourceImageId ביומן הביקורת של ה-VM מהקטע הקודם. לדוגמה: 9046093115864736653.

כדי למצוא ולאמת את ה-VSA כשאתם יודעים את שם הקובץ של קובץ ה-VSA, מבצעים את השלבים הבאים:

  1. פותחים את מאגר הנתונים של GitHub‏ gke-vsa.
  2. בספרייה gke-master-images, מחפשים את הקובץ שמתאים לתמונת מכונת ה-VM. לדוגמה, https://github.com/GoogleCloudPlatform/gke-vsa/blob/main/gke-master-images:78064567238/IMAGE_NAME:IMAGE_ID.intoto.jsonl
  3. מורידים את קובץ ה-VSA.
  4. התקנת הכלי slsa-verifier

  5. שומרים את המפתח הציבורי לאימות ה-VSA בקובץ בשם vsa_signing_public_key:

    -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeGa6ZCZn0q6WpaUwJrSk+PPYEsca
3Xkk3UrxvbQtoZzTmq0zIYq+4QQl0YBedSyy+XcwAMaUWTouTrB05WhYtg==
-----END PUBLIC KEY-----

  6. מאמתים את ה-VSA:

    slsa-verifier verify-vsa \
    --attestation-path=PATH_TO_VSA_FILE \
    --resource-uri=gce_image://gke-master-images:IMAGE_NAME \
    --subject-digest=gce_image_id:IMAGE_ID\
    --verifier-id=https://bcid.corp.google.com/verifier/bcid_package_enforcer/v0.1 \
    --verified-level=BCID_L1 \
    --verified-level=SLSA_BUILD_LEVEL_2 \
    --public-key-path=PATH_TO_PUBLIC_KEY_FILE \
    --public-key-id=keystore://76574:prod:vsa_signing_public_key

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

    • ‫PATH_TO_VSA_FILE: הנתיב לקובץ ה-VSA שהורדתם.
    • ‫IMAGE_NAME: השם של תמונת ה-VM, כמו gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
    • ‫IMAGE_ID: מזהה תמונת ה-VM, כמו 9046093115864736653.

    אם ה-VSA עובר את בדיקות האימות, הפלט הוא:

    Verifying VSA: PASSED
PASSED: SLSA verification passed

המאמרים הבאים