הפעלת יומני ביקורת של Linux ב-GKE nodes

בדף הזה מוסבר איך להפעיל יומני ביקורת מפורטים של מערכת ההפעלה בצמתים של Google Kubernetes Engine שמופעלת בהם מערכת הפעלה שמותאמת לקונטיינרים. בדף הזה מוסבר גם איך להגדיר סוכן Logging של fluent-bit כדי לשלוח יומנים ל-Cloud Logging. הפעלת יומנים מפורטים יכולה לספק מידע חשוב על מצב האשכול ועומסי העבודה, כמו הודעות שגיאה, ניסיונות התחברות והפעלות של קבצים בינאריים. אתם יכולים להשתמש במידע הזה כדי לנפות באגים בבעיות או לבדוק אירועי אבטחה.

הפעלת רישום ביומן של auditd ב-Linux לא נתמכת באשכולות GKE Autopilot, כי Google מנהלת את הצמתים ואת המכונות הווירטואליות (VM) הבסיסיות.

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

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את יומני הביקורת של מערכת ההפעלה Linux.

רישום ביומן של ביקורת במערכת ההפעלה שונה מיומני הביקורת של Cloud ומיומני הביקורת של Kubernetes.

סקירה כללית

כדי לאסוף יומנים מכל צומת באשכול, משתמשים ב-DaemonSet שמריץ בדיוק Pod אחד בכל צומת באשכול שבו ה-DaemonSet עומד בדרישות לתזמון. ה-Pod הזה מגדיר את דמון הרישום ביומן auditd במארח, ומגדיר את סוכן Logging לשליחת היומנים אל Logging או אל כל שירות אחר להזנת יומנים.

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

מגבלות

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

איך פועל ה-DaemonSet של הרישום ביומן

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

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

ה-DaemonSet פורס Pod לכל צומת באשכול. ה-Pod מכיל שני קונטיינרים. הראשון הוא init container שמתחיל את שירות cloud-audit-setup systemd שזמין בצמתים של מערכת הפעלה שמותאמת לקונטיינרים. הקונטיינר השני, cos-auditd-fluent-bit, מכיל מופע של fluent-bit שמוגדר לאיסוף יומני הביקורת של Linux מיומן הצמתים ולייצוא שלהם ל-Cloud Logging.

הדוגמה של DaemonSet לרישום ביומן מתעדת את האירועים הבאים:

  • auditd שינויים בהגדרות המערכת
  • בדיקות הרשאות של AppArmor
  • ‫execve(), socket(), setsockopt() ו-mmap() הפעלות
  • חיבורים לרשת
  • התחברויות של משתמשים
  • סשן SSH וכל שאר ה-TTY (כולל סשנים של kubectl exec -t)

הגדרת DaemonSet של רישום ביומן

מגדירים את DaemonSet של רישום ביומן באמצעות ConfigMap, cos-auditd-fluent-bit-config. בדוגמה שמופיעה כאן, יומני הביקורת נשלחים ל-Logging, אבל אפשר להגדיר אותה כך שהיומנים יישלחו ליעדים אחרים.

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

פריסת ה-DaemonSet של הרישום ביומן

  1. אפשר להשתמש באשכול קיים או ליצור אשכול חדש.

  2. מורידים את המניפסטים לדוגמה:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml

  3. עורכים את קובצי המניפסט לדוגמה בהתאם לצרכים שלכם. בקטע הקודם מוסבר איך DaemonSet פועל. שימו לב שהתמונה fluent-bit שמשמשת במניפסט לדוגמה הזה היא למטרות הדגמה בלבד. מומלץ להחליף את התמונה בתמונה ממקור מבוקר עם תקציר SHA-256.

  4. מאתחלים משתנים נפוצים:

    export CLUSTER_NAME=CLUSTER_NAME
export CLUSTER_LOCATION=COMPUTE_REGION

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

    • ‫CLUSTER_NAME: השם של האשכול.
    • ‫COMPUTE_REGION: האזור ב-Compute Engine שבו נמצא האשכול. במקום זאת, משתמשים באזור עבור אשכולות אזוריים.

  5. פורסים את מרחב השמות, DaemonSet ו-ConfigMap של הרישום ביומן:

    envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \
| kubectl apply -f -

  6. מוודאים שה-Pods של הרישום ביומן התחילו. אם הגדרתם מרחב שמות שונה במניפסטים, צריך להחליף את cos-auditd בשם של מרחב השמות שבו אתם משתמשים.

    kubectl get pods --namespace=cos-auditd

    אם ה-Pods פועלים, הפלט נראה כך:

    NAME                                             READY   STATUS    RESTARTS   AGE
cos-auditd-logging-g5sbq                         1/1     Running   0          27s
cos-auditd-logging-l5p8m                         1/1     Running   0          27s
cos-auditd-logging-tgwz6                         1/1     Running   0          27s

    ‫Pod אחד נפרס בכל צומת באשכול, ובמקרה הזה יש באשכול שלושה צמתים.

  7. עכשיו אפשר לגשת ליומני הביקורת ב-Logging. ב-Logs Explorer, מסננים את התוצאות באמצעות השאילתה הבאה:

    LOG_ID("linux-auditd")
resource.labels.cluster_name = "CLUSTER_NAME"
resource.labels.location = "COMPUTE_REGION"

    לחלופין, אפשר להשתמש ב-CLI של gcloud (משתמשים ב---limit כי קבוצת התוצאות יכולה להיות גדולה מאוד):

    gcloud logging read --limit=100 "LOG_ID("linux-auditd") AND resource.labels.cluster_name = "${CLUSTER_NAME}" AND resource.labels.location = "${CLUSTER_LOCATION}""

ייצוא היומנים

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

השבתת היומנים

כדי להשבית את הרישום של auditd ביומן בצמתים, מוחקים את DaemonSet של רישום ביומן ואז פורסים את cos-auditd-logging-disable DaemonSet כדי להחזיר את השינויים בשירות systemd בכל צומת. אחרי שפורסים את DaemonSet הזה, אי אפשר להפעיל את auditd רישום ביומן, אלא אם יוצרים מחדש את הצמתים.

  1. מוחקים את ה-DaemonSet המקורי של רישום ביומן ואת המשאבים שקשורים אליו:

    kubectl delete daemonset cos-auditd-logging -n cos-auditd
kubectl delete configmap fluent-bit-config -n cos-auditd
# The namespace will be deleted by the cleanup daemonset's namespace definition

  2. מחילים את ה-DaemonSet של cos-auditd-logging-disable לניקוי:

    kubectl apply -f 'https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging-disable.yaml'

  3. מוודאים שה-Pods של cleanup-auditd פועלים בכל הצמתים:

    kubectl get pods -n cos-auditd -l name=cleanup-auditd -w

    מחכים עד שכל ה-Pods יציגו Running.

  4. אחרי שרכיבי ה-Pod של הניקוי פועלים, מריצים את השאילתות מהקטע פריסת ה-DaemonSet של הרישום ביומן כדי לוודא שלא נוצרים יומנים חדשים של linux-auditd. לדוגמה, אפשר להשתמש בפקודה הבאה ב-CLI של gcloud:

    gcloud logging read --limit=10 --freshness="5m" \
  "LOG_ID(\"linux-auditd\") AND \
  resource.labels.cluster_name = \"${CLUSTER_NAME}\" AND \
  resource.labels.location = \"${CLUSTER_LOCATION}\""

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

    באופן דומה, כשמשתמשים ב-Cloud Explorer עם אותו מסנן, לא אמורות להופיע רשומות חדשות ביומן אחרי זמן הניקוי.

  5. מוחקים את ה-DaemonSet והמרחב השמות של הניקוי:

    kubectl delete -f cleanup-auditd-daemonset.yaml

    הפקודה הזו תמחק גם את ה-DaemonSet וגם את מרחב השמות cos-auditd.

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