במסמך הזה מוסבר על מודל האמון באשכולות Google Kubernetes Engine (GKE), כולל תקשורת בתוך אשכולות ואימות בקשות לרכיבים כמו מישורי בקרה. במסמך הזה אנחנו מניחים שאתם יודעים את הפרטים הבאים:
המסמך הזה מיועד למומחי אבטחה שרוצים להבין את מודל האמון של אשכול GKE. מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן בתוכן זמין במאמר תפקידים נפוצים של משתמשים ב-GKE ומשימות. Google Cloud
תקשורת בתוך האשכול
מערכת GKE מחילה מנגנוני אבטחה שונים על התנועה בין רכיבי האשכול, באופן הבא:
תעבורה בין מישור הבקרה לצמתים: מישור הבקרה מתקשר עם צומת כדי לנהל קונטיינרים. כשמישור הבקרה שולח בקשה (לדוגמה,
kubectl logs) לצמתים, הבקשה נשלחת דרך מנהרת פרוקסי של Konnectivity. הבקשות שמישור הבקרה שולח מאומתות ומוגנות באמצעות TLS. כשצומת שולח בקשה למישור הבקרה, למשל מ-kubelet לשרת ה-API, הבקשה הזו מאומתת ומוצפנת באמצעות TLS הדדי (mTLS).כל האשכולות החדשים שנוצרים והאשכולות הקיימים שעודכנו משתמשים ב-TLS 1.3 לתקשורת בין מישור הבקרה לצומת. TLS 1.2 היא הגרסה המינימלית הנתמכת לתקשורת בין מישור הבקרה לבין הצומת.
תעבורה בין צמתים: הצמתים הם מכונות וירטואליות ב-Compute Engine. החיבורים בין צמתים בתוך רשת הייצור Google Cloud עוברים אימות והצפנה. פרטים נוספים זמינים בקטע 'הצפנה במעבר בין מכונות וירטואליות' במאמר בנושא הצפנה במעבר.
תנועה בין Pods: כש-Pod שולח בקשה ל-Pod אחר, התנועה הזו לא מאומתת כברירת מחדל. ב-GKE התנועה מוצפנת בין רכיבי Pod בצמתים שונים בשכבת הרשת. התנועה בין Pods באותו צומת לא מוצפנת כברירת מחדל. פרטים על הצפנה בשכבת הרשת זמינים במאמר Google Cloud הצפנה ואימות של רשת וירטואלית.
אפשר להגביל את התעבורה בין פודים באמצעות NetworkPolicy, ולהצפין את כל התעבורה בין פודים, כולל התעבורה באותו הצומת, באמצעות רשת שירותים כמו Cloud Service Mesh או שיטה אחרת להצפנה בשכבת האפליקציה.
תעבורה בין רכיבי מישור הבקרה: התעבורה בין רכיבים שונים שפועלים במישור הבקרה מאומתת ומוצפנת באמצעות TLS. תעבורת הנתונים אף פעם לא יוצאת מרשת בבעלות Google שמוגנת על ידי חומות אש.
Root of trust
ההגדרה של GKE היא כזו:
- רשות אישורי הבסיס (CA) של האשכול משמשת לאימות של שרת ה-API ושל אישורי הלקוח של kubelet. כלומר, למישורי הבקרה ולצמתים יש אותו שורש מהימן. כל kubelet במאגר הצמתים של האשכול יכול לבקש אישור מרשות האישורים הזו באמצעות API
certificates.k8s.io, על ידי שליחת בקשה לחתימת אישור. לרשות האישורים (CA) העליונה יש משך חיים מוגבל, כמו שמתואר בקטע משך החיים של רשות האישורים (CA) העליונה של האשכול. - באשכולות שמריצים מופעי מסד נתונים של etcd במכונות וירטואליות של מישור הבקרה, נעשה שימוש ב-CA נפרד של עמיתים ב-etcd לכל אשכול כדי ליצור אמון בין מופעי etcd.
- בכל אשכולות GKE, נעשה שימוש ב-CA נפרד של etcd API כדי ליצור אמון בין שרת ה-API של Kubernetes לבין etcd API.
שרת API ו-kubelets
שרת ה-API ו-kubelets מסתמכים על רשות האישורים (CA) הבסיסית של האשכול לצורך מהימנות. ב-GKE, אישור ה-API של מישור הבקרה נחתם על ידי רשות האישורים (CA) הבסיסית של האשכול. כל אשכול מריץ CA משלו, כך שאם CA של אשכול אחד נמצא בסיכון, לא תהיה לכך השפעה על CA של אשכול אחר.
שירות פנימי מנהל את מפתחות הבסיס של רשות האישורים הזו, ולא ניתן לייצא אותם. השירות הזה מקבל בקשות לחתימה על אישורים, כולל בקשות מ-kubelet בכל אשכול GKE. גם אם שרת ה-API באשכול ייפרץ, רשות האישורים (CA) לא תיפרץ, ולכן אשכולות אחרים לא יושפעו.
בכל צומת באשכול מוזרק סוד משותף בזמן היצירה, והצומת יכול להשתמש בו כדי לשלוח בקשות לחתימת אישורים לרשות האישורים הבסיסית של האשכול ולקבל אישורי לקוח של kubelet. לאחר מכן, ה-kubelet משתמש באישורים האלה כדי לאמת את הבקשות שלו לשרת ה-API. אפשר להגיע לסוד לשימוש עם טוקן צרכן הזה באמצעות Pods בצומת, אלא אם מפעילים צומתי GKE מוגנים או איחוד זהויות של עומסי עבודה ל-GKE.
משך החיים של רשות אישורים (CA) עליונה באשכול
ל-CA הבסיסי של האשכול יש משך חיים מוגבל, ולאחר מכן כל האישורים שנחתמו על ידי ה-CA שפג תוקפו לא תקפים. כדי לבדוק את תאריך התפוגה המשוער של רשות האישורים (CA) של האשכול, פועלים לפי ההוראות במאמר בדיקת משך החיים של פרטי הכניסה.
מומלץ לבצע רוטציה ידנית של פרטי הכניסה לפני שתוקף ה-CA הבסיסי הקיים יפוג. אם תוקף ה-CA יפוג ולא תבצעו רוטציה של פרטי הכניסה, יכול להיות שהאשכול ייכנס למצב שלא ניתן לשחזר. ל-GKE יש את המנגנונים הבאים שמנסים למנוע אשכולות שלא ניתן לשחזר:
- האשכול עובר למצב
DEGRADEDשבעה ימים לפני שתוקף האישור יפוג מערכת GKE מנסה לבצע רוטציה אוטומטית של אישורים 30 יום לפני שתוקף אישור ה-CA יפוג. הרוטציה האוטומטית הזו מתעלמת מחלונות תחזוקה, ויכולה לגרום לשיבושים כי GKE יוצר מחדש צמתים כדי להשתמש בהרשאות חדשות. לקוחות חיצוניים, כמו kubectl בסביבות מקומיות, לא יפעלו עד שתעדכנו אותם לשימוש בהרשאות החדשות.
במאמר החלפת פרטי הכניסה של האשכול מוסבר איך לבצע רוטציה.
אחסון מצב האשכול
אשכולות GKE מאחסנים את המצב של אובייקטים של Kubernetes API כזוגות של מפתח/ערך במסד נתונים. שרת ה-API של Kubernetes במישור הבקרה שלכם מתקשר עם מסד הנתונים הזה באמצעות etcd API. GKE משתמש באחת מהטכנולוגיות הבאות כדי להריץ את מסד הנתונים של מצב האשכול:
- etcd: האשכול משתמש במופעי etcd שפועלים במכונות וירטואליות של מישור הבקרה.
- Spanner: האשכול משתמש במסד נתונים של Spanner שפועל מחוץ למכונות הווירטואליות של מישור הבקרה.
לא משנה באיזו טכנולוגיית מסד נתונים משתמשים באשכול, כל אשכול GKE משרת את etcd API במישור הבקרה. כדי להצפין תנועה שכוללת את מסד הנתונים של מצב האשכול, GKE משתמש באחד או בשניה מאישורי ה-CA הבאים לכל אשכול:
- etcd API CA: משמש לחתימה על אישורים לתנועה אל נקודות הקצה של etcd API ומנקודות הקצה האלה. רשות אישורים (CA) של etcd API פועלת בכל אשכול GKE.
- etcd peer CA: משמש לחתימה על אישורים לתעבורה בין מופעי מסד נתונים של etcd במישור הבקרה. רשות אישורים (CA) של עמיתי etcd פועלת בכל אשכול שמשתמש במסדי נתונים של etcd. במקרים שבהם נעשה שימוש במסדי נתונים של Spanner, לא נעשה שימוש ב-CA של עמיתים ב-etcd.
מפתחות הבסיס של ה-CA של etcd API מופצים למטא-נתונים של כל מכונת Compute Engine שמישור הבקרה פועל בה. ה-CA של etcd API לא משותף בין אשכולות.
תוקף אישור ה-CA של etcd תלוי בתאריך יצירת האשכול, באופן הבא:
- במקרים של אשכולות שנוצרו לפני אוקטובר 2021, האישור תקף למשך 5 שנים.
- במקרה של אשכולות שנוצרו אחרי אוקטובר 2021, התעודה תקפה ל-30 שנה. ללא קשר לתאריך היצירה של האשכול, אישור ה-CA החדש של etcd שנוצר במהלך רוטציה של אישורים תקף ל-30 שנה. האישור יוחלף אוטומטית 6 חודשים לפני שהוא יפוג.
רוטציה של אישורים
כדי לבצע רוטציה של כל האישורים של שרת ה-API ו-kubelet באשכול, מבצעים רוטציה של פרטי הכניסה. אין דרך להפעיל סבב של אישורי etcd. המערכת מנהלת את זה בשבילכם ב-GKE.