מדיניות ביקורת

במאמר הזה מתוארת מדיניות רישום יומני הביקורת ב-Google Kubernetes Engine ‏ (GKE). כדי להבין את המסמך הזה, אתם צריכים להכיר את הנושאים הבאים:

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

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

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

סקירה כללית של כללי מדיניות הביקורת

באשכול GKE, שרת ה-API של Kubernetes כותב רשומות של יומן ביקורת לקצה עורפי שמנוהל על ידי GKE. כש-GKE מקבל רשומות ביומן משרת ה-API של Kubernetes, הוא כותב אותן ביומן Admin Activity וביומן Data Access של הפרויקט.

יש שני כללי מדיניות שמשפיעים על מה שמופיע ביומני הביקורת של הפרויקט:

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

  • מדיניות הביקורת של GKE קובעת אילו רשומות נכתבות ביומן Admin Activity ואילו נכתבות ביומן Data Access.

יומני הביקורת שנכתבים ביומן Data Access תלויים בהגדרות של יומן הביקורת. יומני הגישה לנתונים מתומחרים לפי התמחור של Google Cloud Observability. יומני פעילות של אדמין מוצעים ללא תשלום. ב-GKE יש תמיכה בסוגים הבאים של יומני Data Access.

  • ‫ADMIN_READ: פעולות שקוראות מטא-נתונים על משאבים ב-Kubernetes, כמו הצגת רשימה של Pods.
  • ‫DATA_READ: פעולות שקוראות נתונים במשאב ב-Kubernetes, כמו קריאת היומנים של Pod.
  • ‫DATA_WRITE: פעולות שכותבות נתונים למשאבים ב-Kubernetes, כמו עדכון הסטטוס של Pod.

מידע נוסף זמין במאמר הגדרת יומני ביקורת של גישה לנתונים.

מדיניות הביקורת של Kubernetes

שרת ה-API של Kubernetes פועל לפי מדיניות שצוינה בדגל --audit-policy-file של הפקודה kube-apiserver.

כש-GKE מפעיל את שרת ה-API של Kubernetes, הוא מספק קובץ מדיניות ביקורת על ידי הגדרת הערך של הדגל --audit-policy-file. במאגר של Kubernetes בקוד פתוח, אפשר לראות את הסקריפט configure-helper.sh שיוצר את קובץ מדיניות הביקורת. אפשר לראות את רוב קובץ מדיניות הביקורת ישירות בסקריפט.

אירועים ושלבים

כשמשתמש או רכיב שולחים בקשה לשרת ה-API של Kubernetes, הבקשה עוברת שלב אחד או יותר:

שלב תיאור
RequestReceived הבקשה התקבלה אצל הגורם המטפל בביקורת.
ResponseStarted כותרות התגובה נשלחו, אבל גוף התגובה לא נשלח.
ResponseComplete גוף התגובה הושלם, ולא יישלחו עוד בייטים.
פאניקה הייתה שגיאת שרת פנימית, והבקשה לא הושלמה.

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

רמות הביקורת

קובץ מדיניות הביקורת של Kubernetes מכיל רשימה של כללים. בקובץ המדיניות, הכלל הראשון שתואם לאירוע מגדיר את רמת הביקורת של האירוע.

בכלל אפשר לציין אחת מרמות הביקורת הבאות:

רמה תיאור
ללא לא ליצור רשומת יומן לאירוע.
מטא-נתונים יוצרים רשומה ביומן. לכלול מטא-נתונים, אבל לא לכלול את גוף הבקשה או את גוף התגובה.
בקשה יוצרים רשומה ביומן. כולל מטא-נתונים וגוף הבקשה, אבל לא כולל את גוף התגובה.
RequestResponse יוצרים רשומה ביומן. כולל מטא-נתונים, גוף הבקשה וגוף התגובה.

הנה דוגמה לכלל. אם אירוע תואם לכלל, שרת ה-API של Kubernetes יוצר רשומה ביומן ברמה Request.

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

אירוע תואם לכלל אם כל התנאים הבאים מתקיימים:

  • האירוע לא תואם לאף כלל קודם בקובץ המדיניות.
  • הזהות שמבצעת את הקריאה נמצאת בקבוצת המשתמשים system:nodes.
  • הקריאה היא בקשת update או בקשת patch.
  • הבקשה היא למשאב nodes/status או למשאב pods/status.
  • האירוע לא מיועד לשלב RequestReceived של השיחה.

מדיניות הביקורת של GKE

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

ברוב המקרים, GKE מחיל את הכללים הבאים על רשומות ביומן שמגיעות משרת ה-API של Kubernetes:

  • רשומות שמייצגות בקשות מסוג create,‏ delete ו-update נשלחות ליומן הפעילות של האדמין.

  • רשומות שמייצגות בקשות מסוג get,‏ list ו-updateStatus נשלחות ליומן Data Access.

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

קובץ מדיניות הביקורת של Kubernetes לאשכולות GKE

באשכולות GKE, קובץ מדיניות הביקורת של Kubernetes מתחיל בכללים שמציינים שאירועים מסוימים לא צריכים להירשם ביומן בכלל. לדוגמה, הכלל הזה קובע שאין לתעד ביומן בקשות get של kubelet במשאב nodes או במשאב nodes/status. חשוב לזכור שרמה של None פירושה שאין לתעד ביומן אירועים תואמים:

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

אחרי רשימת הכללים של level: None, קובץ המדיניות כולל רשימה של כללים שהם מקרים מיוחדים. לדוגמה, הכלל הבא למקרה מיוחד קובע שצריך לתעד בקשות מסוימות ברמת Metadata:

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

אירוע תואם לכלל אם כל התנאים הבאים מתקיימים:

  • האירוע לא תואם לאף כלל קודם בקובץ המדיניות.
  • הבקשה היא למשאב מסוג secrets,‏ configmaps או tokenreviews.
  • האירוע לא מיועד לשלב RequestReceived של השיחה.

אחרי רשימת הכללים למקרים מיוחדים, קובץ המדיניות מכיל כמה כללים כלליים. כדי לראות את הכללים הכלליים בסקריפט, צריך להחליף את הערך של known_apis ב-${known_apis}. אחרי ההחלפה, מתקבל כלל כזה:

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

הכלל חל על אירועים שלא תואמים לאף כלל קודם בקובץ המדיניות, ולא נמצאים בשלב RequestReceived. לפי הכלל, בקשות מסוג get,‏ list ו-watch לכל משאב ששייך לאחת מהקבוצות שברשימה צריכות להירשם ביומן ברמה Request.

הכלל הבא בקובץ המדיניות נראה כך:

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

הכלל חל על אירועים שלא תואמים לאף כלל קודם בקובץ המדיניות, ולא נמצאים בשלב RequestReceived. באופן ספציפי, הכלל לא חל על בקשות הקריאה: get,‏ list ו-watch. במקום זאת, הכלל חל על בקשות כתיבה כמו create,‏ update ו-delete. לפי הכלל, בקשות כתיבה צריכות להירשם ביומן ברמה RequestResponse.

סיכום של מדיניות הביקורת של Kubernetes באשכולות GKE

הרשימה הבאה מסכמת את מדיניות הביקורת של Kubernetes באשכולות GKE:

  • באופן כללי, בקשות כתיבה כמו create,‏ update ו-delete מתועדות ביומן ברמת RequestResponse.

  • באופן כללי, אירועים מסוג get,‏ list ו-watch נרשמים ביומן ברמת Metadata.

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

    • בקשות עדכון ותיקון של kubelet,‏ system:node-problem-detector או system:serviceaccount:kube-system:node-problem-detector במשאב nodes/status או במשאב pods/status מתועדות ביומן ברמת הבקשה.

    • בקשות עדכון ותיקון של כל זהות בקבוצה system:nodes במשאב nodes/status או במשאב pods/status מתועדות ביומן ברמת הבקשה.

    • בקשות deletecollection של system:serviceaccount:kube-system:namespace-controller מתועדות ביומן ברמת הבקשה.

    • בקשות במשאב secrets, במשאב configmaps או במשאב tokenreviews מתועדות ביומן ברמת המטא-נתונים.

  • בקשות מסוימות לא נרשמות ביומן בכלל. לרשימה המלאה של הבקשות שלא מתועדות ביומן, עיינו בכללים של level: None בסקריפט המדיניות. הבקשות הבאות לא מתועדות ביומן:

    • בקשות של system:kube-proxy לצפות במשאב endpoints, במשאב services או במשאב services/status.

    • בקשות GET של system:unsecured במשאב configmaps במרחב השמות kube-system.

    • בקשות GET של kubelet במשאב nodes או במשאב nodes/status.

    • בקשות Get של כל זהות בקבוצה system:nodes במשאב nodes או במשאב nodes/status.

    • קבלת בקשות ועדכון שלהן על ידי system:kube-controller-manager, system:kube-scheduler או system:serviceaccount:endpoint-controller במשאב endpoints במרחב השמות kube-system.

    • בקשות GET של system:apiserver במשאב namespaces, במשאב namespaces/status או במשאב namespaces/finalize.

    • בקשות get ו-list של system:kube-controller-manager בכל משאב בקבוצה metrics.k8s.io.

    • בקשות לכתובות URL שתואמות ל-/healthz*, ל-/version או ל-/swagger*.

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