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

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

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

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

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

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

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

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

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

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

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

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

כתובת האימייל של סוכן השירות של Kubernetes Engine היא:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה אפשר לראות

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

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

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

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

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

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

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

    • נקודת קצה מבוססת 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.

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