אימות התקינות של מכונת וירטואלית במישור הבקרה של 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 יומנים של יצירת מכונות וירטואליות במישור הבקרה. היומנים האלה מכילים מטא-נתונים שמזהים את המכונה וכוללים פרטים על תמונת מכונת ה-VM ועל רצף האתחול. ‏Google Cloud מפרסמת אימות סיכום (VSA) לכל תמונת מכונת VM של מישור הבקרה של GKE במאגר gke-vsa ב-GitHub. ב-VSA נעשה שימוש ב-framework של in-toto לאישורים. אתם יכולים לאמת את יומני ה-VM של מישור הבקרה של האשכולות שלכם מול ה-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 אי אפשר להריץ את הפקודות שבמסמך הזה.

  • מפעילים את Cloud Logging API, אם הוא עדיין לא מופעל.

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

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

  • מוודאים שכבר יש לכם אשכול במצב אוטומטי או במצב רגיל ב-GKE, בגרסה 1.29 ואילך.

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

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

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

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

בדיקה אם יש שלבים שנכשלו ברצף ההפעלה

ניטור התקינות מוסיף יומן ל-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: שם האשכול.

איתור ובדיקה של יומני ה-VM של מישור הבקרה

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

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

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

  • מזהה תמונת ה-VM
  • מספר הפרויקט בבעלות Google Cloudשמארח את המכונות הווירטואליות
  • שם קובץ אימג' של מערכת ההפעלה ששימש לאתחול ה-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: מזהה קובץ האימג' של המכונה הווירטואלית, כמו 9046093115864736653.

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

    Verifying VSA: PASSED
PASSED: SLSA verification passed

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