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

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

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

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

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

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

סקירה כללית

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

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

מגבלות

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

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

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

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

ה-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. מוודאים שרכיבי ה-Pod של הרישום ביומן התחילו לפעול. אם הגדרתם מרחב שמות אחר במניפסטים, צריך להחליף את 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. מוודאים שרכיבי ה-cleanup-auditd Pod פועלים בכל הצמתים:

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

    ממתינים עד שכל ה-Pods יציגו את הסמל Running.

  4. אחרי שרכיבי ה-Pods של הניקוי פועלים, מריצים את השאילתות מהקטע פריסת ה-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}\""

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

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

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

    kubectl delete -f cleanup-auditd-daemonset.yaml

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

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