אבטחה של מישור הבקרה

במאמר הזה מוסבר איך Google Kubernetes Engine ‏ (GKE) עוזר לאבטח את רכיבי מישור הבקרה של האשכול. במסמך הזה אנחנו מניחים שאתם מכירים את הנושאים הבאים:

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

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

במסגרת מודל האחריות המשותפת,‏ Google מנהלת בשבילכם את רכיבי מישור הבקרה של GKE. מישור הבקרה כולל את שרת ה-API של Kubernetes, את מאגר האובייקטים של Kubernetes API ובקרים אחרים. ‫Google אחראית לאבטחת מישור הבקרה, אבל יכול להיות שתוכלו להגדיר אפשרויות מסוימות בהתאם לדרישות שלכם. אתם אחראים לאבטחת הצמתים, הקונטיינרים וה-Pods.

מערכת הפעלה מוקשחת

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

ארכיטקטורה ובידוד

באשכול GKE, הרכיבים של מישור הבקרה פועלים במכונות של Compute Engine שבבעלות Google, בפרויקט שמנוהל על ידי Google. כל מופע מריץ את הרכיבים האלה רק עבור אשכול אחד.

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

גישה למישור הבקרה של הפרויקט

‫GKE משתמש בסוכן שירות בשם Kubernetes Engine Service Agent כדי להפעיל משאבי אשכול בשמכם, כמו צמתים, דיסקים ומאזני עומסים. חשבון השירות מקבל באופן אוטומטי את התפקיד "סוכן שירות של Kubernetes Engine" (roles/container.serviceAgent) בפרויקט.

כתובת האימייל של Kubernetes Engine Service Agent היא:

service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com

בכתובת האימייל הזו, PROJECT_NUMBER הוא מספר הפרויקט.

הרשאת אדמין לאשכול

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

אבטחה של מסד נתונים של מצב האשכול

ב- Cloud de Confiance by S3NS, תוכן של לקוחות מוצפן כברירת מחדל בשכבת מערכת הקבצים. ההצפנה הזו כוללת את התשתית שמארחת את מסד הנתונים שמבוסס על etcd או על Spanner, שבו מאוחסן המצב של אובייקטים של Kubernetes API באשכול. מידע נוסף על מסד הנתונים של מצב האשכול זמין במאמר ארכיטקטורת אשכול GKE.

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

  • לקוחות API של etcd: ‏GKE מציג את etcd API בכל מכונה וירטואלית של מישור הבקרה. לקוחות API של etcd במישור הבקרה, כמו שרת Kubernetes API, משתמשים באחת מהיציאות הבאות:

    • יציאה 2379: היציאה הזו משמשת כש-GKE מאחסן את מצב האשכול במופעים של מסד הנתונים etcd שפועלים בכל מכונה וירטואלית של מישור הבקרה.
    • ‫Port 3379: הפורט הזה משמש כש-GKE מאחסן את מצב האשכול במסד נתונים של Spanner שמופרד ממישור הבקרה.

    היציאה שבה משתמשים לקוחות ה-API של etcd מקושרת לממשק הרשת של הלולאה החוזרת (loopback) המקומית, ואפשר לגשת אליה רק מהמכונה הווירטואלית של מישור הבקרה שמריצה את שרת ה-API של Kubernetes.

  • מכונות של מסד נתונים etcd: אם המכונות הווירטואליות של מישור הבקרה מריצות מכונות של מסד נתונים etcd, שרתי ה-API של etcd בכל מכונה וירטואלית משתמשים ביציאה 2380 כדי לתקשר זה עם זה. התעבורה ביציאה 2380 בין מופעי מסד הנתונים של etcd במכונות וירטואליות מרובות של מישור הבקרה (למשל באשכולות אזוריים) מוצפנת באמצעות TLS הדדי. ב-TLS הדדי, כל שרת חייב להוכיח את הזהות שלו לשרת השני.

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

רשות אישורים ומהימנות של אשכול

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

ניהול נקודות חולשה ותיקונים

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

הרכיבים של מישור הבקרה של GKE מנוהלים על ידי צוות של מהנדסי אמינות אתרים (SRE) של Google, והם מתעדכנים בתיקוני האבטחה האחרונים. העדכונים כוללים תיקונים למערכת ההפעלה המארחת, לרכיבי Kubernetes ולקונטיינרים שפועלים במכונות הווירטואליות של מישור הבקרה.

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

מהנדסי Google משתתפים במאמצים למצוא ולתקן באגים באבטחה של Kubernetes, ולדווח עליהם. בנוסף, Google משלמת לחוקרי אבטחה חיצוניים במסגרת תוכנית התגמולים על זיהוי נקודות חולשה באבטחה (VRP) של Google, כדי שיחפשו באגים באבטחה. במקרים מסוימים, כמו נקודת החולשה של dnsmasq באוקטובר 2017, הצלחנו לתקן את כל האשכולות הפועלים ב-GKE לפני שנקודת החולשה נחשפה לציבור.

מה אפשר לראות

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

  • יומני ביקורת: רישום ביומן הביקורת מופעל כברירת מחדל. הרישום הזה מספק רשומה מפורטת, שזמינה ב-Google Cloud Observability, של קריאות שבוצעו לשרת API של Kubernetes. אפשר לראות את הרשומות ביומן בLogs Explorer במסוףCloud de Confiance . אתם יכולים גם להשתמש ב-BigQuery כדי להציג ולנתח את היומנים האלה.

  • תקינות קובץ האימג' של המכונה הווירטואלית במישור הבקרה: GKE מוסיף ל-Cloud Logging יומנים מפורטים של אירועי יצירה והפעלה של מכונות וירטואליות של צמתים. בנוסף, אנחנו מפרסמים ב-GitHub את ה-VSA של SLSA שמתאימים לתמונות של מכונות במישור הבקרה ובצומת העובד. אתם יכולים לוודא שהמכונות הווירטואליות משתמשות בקובצי אימג' של מערכת ההפעלה שיש להן VSA תואם, ולוודא את תקינות האתחול של כל מכונה וירטואלית של מישור הבקרה.

    כדי לבצע אימות של תקינות מכונות וירטואליות, אפשר לעיין במאמר בנושא אימות של תקינות מכונות וירטואליות במישור הבקרה של GKE.

מה אפשר להגדיר

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

  • גישה למישור הבקרה: למישור הבקרה יש שני סוגים של נקודות קצה (endpoints) לגישה לאשכול:

    • נקודת קצה מבוססת-DNS
    • נקודות קצה מבוססות-IP

    כברירת מחדל, שרת ה-API של Kubernetes משתמש בכתובת IP חיצונית. כדי להגן על שרת ה-API של Kubernetes, אפשר להפעיל נקודת קצה מבוססת-DNS לגישה למישור הבקרה. אתם יכולים לקבוע למי תהיה גישה לנקודת הקצה של ה-DNS באמצעות VPC Service Controls, שמאפשר לכם להגדיר פרמטר אבטחה אחד לכל ממשקי ה-API של Google בפרויקט. אם משתמשים בנקודות קצה מבוססות-IP לגישה לרמת הבקרה, מומלץ להשתמש ברשתות מורשות ולהשבית את הגישה לנקודת הקצה החיצונית של רמת הבקרה. מידע נוסף על בידוד רשת זמין במאמר מידע על התאמה אישית של בידוד רשת.

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

  • רוטציית פרטי כניסה: מבצעים רוטציית פרטי כניסה כדי להחליף באופן קבוע את רשות האישורים (CA) של האשכול ואת אישורי ה-TLS. במהלך התהליך הזה, GKE גם מחליף את כתובת ה-IP של שרת ה-API של Kubernetes. מידע נוסף זמין במאמר בנושא רוטציית פרטי כניסה.

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

  • להפעיל רשויות אישורים ומפתחות משלכם להנפקת זהויות באמצעות Cloud KMS ו-CA Service.
  • הצפנה של etcd ושל דיסקי אתחול של מישור הבקרה באמצעות מפתחות משלכם ב-Cloud KMS.

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

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