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

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

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

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

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

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

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

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

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

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

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

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

תמחור

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

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

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

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

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

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

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

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

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

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

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

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

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

    כניסה לדף 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: המזהה המספרי שלGoogle Cloud הארגון.
    • CLUSTER_ID: הערך של השדה protoPayload.metadata.parentResource.parentResourceId מהשלב הקודם.

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

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

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

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

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

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

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

    כניסה לדף 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 של תמונת ה-VM של המקור. התחביר של הערך בשדה הזה הוא https://www.googleapis.com/compute/v1/projects/PROJECT_NUMBER/global/images/IMAGE_NAME, כאשר PROJECT_NUMBER הוא מספר הפרויקט בבעלותGoogle Cloudשמארח את מכונות ה-VM של מישור הבקרה, ו-IMAGE_NAME הוא שם התמונה ששימשה לאתחול מכונת ה-VM.
    • isBootDisk: מזהה בוליאני שקובע אם הדיסק הזה שימש כדיסק האתחול של המכונה הווירטואלית.

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

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

  • המזהה של תמונת ה-VM
  • מספר הפרויקט בבעלות Google Cloudשמארח את מכונות ה-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
    

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