אמון באשכול

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

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

תקשורת בתוך האשכול

ב-GKE מופעלים מנגנוני אבטחה שונים לתנועה בין רכיבי האשכול, באופן הבא:

  • תעבורת נתונים בין מישור הבקרה לצמתים: מישור הבקרה מתקשר עם צומת לניהול קונטיינרים. כשמישור הבקרה שולח בקשה (לדוגמה, kubectl logs) לצמתים, הבקשה נשלחת דרך מנהרת שרת proxy של Konnectivity. הבקשות שמישור הבקרה שולח מאומתות ומוגנות באמצעות TLS. כשצומת שולח בקשה למישור הבקרה, למשל מה-kubelet לשרת ה-API, הבקשה מאומתת ומוצפנת באמצעות Mutual TLS ‏ (mTLS).

    כל האשכולות החדשים והמעודכנים משתמשים ב-TLS 1.3 לתקשורת בין מישור הבקרה לצומת. גרסה TLS 1.2 היא הגרסה המינימלית שנתמכת לתקשורת בין מישור הבקרה לצומת.

  • תעבורת נתונים בין צמתים: הצמתים הם מכונות וירטואליות של Compute Engine. החיבורים בין הצמתים בתוך רשת סביבת הייצור של Google Cloud עוברים אימות והצפנה. לפרטים נוספים, קראו את הקטע VM-to-VM במאמר בנושא הצפנה במעבר.

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

    אתם יכולים להגביל את תעבורת הנתונים בין Pods באמצעות NetworkPolicy, ולהצפין את כל תעבורת הנתונים בין Pods, כולל תעבורת נתונים באותו צומת, באמצעות רשת שירות כמו Cloud Service Mesh או שיטה אחרת של הצפנה בשכבת האפליקציה.

  • תנועה בין רכיבים של מישור הבקרה: התנועה בין רכיבים שונים שפועלים במישור הבקרה מאומתת ומוצפנת באמצעות TLS. תעבורת הנתונים אף פעם לא יוצאת מרשת שבבעלות Google ומוגנת על ידי חומות אש.

שורש האמון (Root of trust)

ההגדרות של GKE:

  • רשות אישורי הבסיס (CA) של האשכול משמשת לאימות אישורי הלקוח של שרת ה-API ושל ה-kubelets. כלומר, למישורי הבקרה ולצמתים יש את אותו Root of Trust. כל kubelet במאגר הצמתים של האשכול יכול לבקש אישור מרשות האישורים הזו באמצעות ה-API של certificates.k8s.io, על ידי שליחת בקשה לחתימה על אישור. לרשות אישורים בסיסית יש משך חיים מוגבל, כמו שמתואר בקטע משך החיים של רשות אישורים בסיסית באשכול.
  • באשכולות שבהם פועלים מכונות של מסד נתונים etcd במכונות הווירטואליות של מישור הבקרה, נעשה שימוש ב-CA נפרד של עמית etcd לכל אשכול כדי ליצור אמון בין מכונות etcd.
  • בכל אשכולות GKE, נעשה שימוש ב-CA נפרד של etcd API כדי ליצור אמון בין שרת ה-API של Kubernetes לבין ה-API של etcd.

שרת API ו-kubelets

שרת ה-API וה-kubelets מסתמכים על רשות האישורים (CA) ברמה הבסיסית של האשכול לצורך אמון. ב-GKE, אישור ה-API של מישור הבקרה נחתם על ידי רשות האישורים (CA) ברמה הבסיסית של האשכול. כל אשכול מפעיל CA משלו, כך שאם ה-CA של אשכול אחד נפגע, ה-CA של אשכולות אחרים לא מושפע.

שירות פנימי מנהל את מפתחות הבסיס של רשות האישורים הזו, ואי אפשר לייצא אותם. השירות הזה מקבל בקשות לחתימה על אישורים, כולל בקשות מה-kubelets בכל אשכול GKE. גם אם שרת ה-API באשכול נפרץ, רשות האישורים לא תיפגע, כך שאשכולות אחרים לא יושפעו.

בכל צומת באשכול מוזרק סוד משותף בזמן היצירה, שבו אפשר להשתמש כדי לשלוח בקשות לחתימה על אישורים לרשות האישורים ברמה הבסיסית (root) של האשכול, ולקבל אישורי לקוח של kubelet. לאחר מכן, האישורים האלה משמשים את ה-kubelet כדי לאמת את הבקשות שלו לשרת ה-API. הסוד המשותף הזה נגיש לפודים בצומת, אלא אם מפעילים את צומתי GKE מוגנים או את איחוד זהויות של עומסי עבודה ל-GKE.

משך החיים של רשות אישורים בסיסית באשכול

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

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

  • האשכול נכנס למצב DEGRADED שבעה ימים לפני שתוקף ה-CA פג

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

במאמר החלפת פרטי הכניסה לאשכול מוסבר איך מבצעים החלפה.

אחסון מצב האשכול

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

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

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

  • ‫etcd API CA: משמש לחתימה על אישורים לתנועה אל נקודות הקצה של etcd API וממנה. בכל אשכול GKE פועל CA של etcd API.
  • רשות אישורים (CA) של עמית etcd: משמשת לחתימה על אישורים לתעבורת נתונים בין מכונות של מסד נתונים של etcd במישור הבקרה. רשות אישורים מקבילה של etcd פועלת בכל אשכול שמשתמש במסדי נתונים של etcd. אשכולות שמשתמשים במסדי נתונים של Spanner לא משתמשים ברשות האישורים של עמיתי etcd.

מפתחות הבסיס של ה-CA של ה-API של etcd מופצים למטא-נתונים של כל מכונה של Compute Engine שמישור הבקרה פועל בה. רשות האישורים של ה-API של etcd לא משותפת בין אשכולות.

התוקף של אישור ה-CA של etcd תלוי בתאריך היצירה של האשכול, באופן הבא:

  • באשכולות שנוצרו לפני אוקטובר 2021, האישור תקף ל-5 שנים.
  • באשכולות שנוצרו אחרי אוקטובר 2021, האישור תקף ל-30 שנה. בלי קשר לתאריך היצירה של האשכול, אישור ה-CA החדש של etcd שנוצר במהלך סבב האישורים תקף ל-30 שנה. האישור יוחלף באופן אוטומטי 6 חודשים לפני שהוא יפוג.

רוטציית אישורים

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

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