במסמך הזה מוסבר על אמצעי האבטחה המובנים ב-Connect.
פלטפורמה יעילה של ענן היברידי וענן מרובה מספקת ניהול מרכזי, ניראות וגישה לשירותים בסביבות שונות. GKE Enterprise מספק חוויה אחידה ומקיפה בכל היכולות האלה, לא משנה באיזה ספק Kubernetes אתם משתמשים. Connect הוא סוכן קל משקל שמספק את היתרונות הבאים בקנה מידה רחב, ובקרב ספקים שונים:
- ניהול של כמה אשכולות וחשיפה של האשכולות
- פריסה של שירותי אפליקציות וניהול מחזור החיים
במסמך הזה נדון בנושאים הבאים:
- איך העיצוב של Connect מתעדף את האבטחה
- שיטות מומלצות לפריסת Connect Agent
- איך משפרים את מצב האבטחה של פריסת Kubernetes
הארכיטקטורה של Connect
התכונה Connect מאפשרת למשתמשי קצה ולשירותים לגשת לשרתי API של Kubernetes שלא נמצאים באינטרנט הציבורי. Google Cloudהסוכן Connect פועל באשכול Kubernetes (סוכן אחד לכל אשכול) ומתחבר לפרוקסי Connect.שירותים שצריכים אינטראקציה עם אשכול Kubernetes מתחברים לפרוקסי, שמעביר בקשות לסוכן. Google Cloud הסוכן, בתורו, מעביר אותן לשרת Kubernetes API, כפי שמתואר בתרשים הבא.
כשהסוכן נפרס, הוא יוצר חיבור קבוע מסוג TLS 1.2 ומעלה אל שירותיGoogle Cloud כדי להמתין לבקשות.כשמנהלי מערכת מפעילים את שירותי Google Cloud , הם יכולים ליצור בקשות עבור אשכולות Kubernetes. הבקשות האלה יכולות להגיע גם מאינטראקציה ישירה של המשתמש עם Google Cloud המסוף, Connect Gateway או שירותים אחרים של Google.
השירות Google Cloud שולח את הבקשה ל-proxy. הפרוקסי מעביר את הבקשה לסוכן שנפרס ואחראי על אשכול, ולבסוף הסוכן מעביר את הבקשה לשרת Kubernetes API. שרת ה-API של Kubernetes מחיל את מדיניות האימות, ההרשאה והרישום ביומן של Kubernetes, ומחזיר תגובה. התשובה מועברת חזרה דרך הסוכן וה-Proxy אל שירות Google Cloud . בכל שלב בתהליך, הרכיבים מבצעים אימות והרשאה לכל חיבור ולכל בקשה.
שרת ה-API של Kubernetes מחיל את אותן מדיניות אימות, הרשאה ורישום ביומן ביקורת על כל הבקשות, כולל בקשות דרך Connect. התהליך הזה מבטיח שתמיד תהיה לכם שליטה בגישה לאשכול.
חיבור והגנה לעומק
הגנה לעומק היא חלק בלתי נפרד מכל מה ש- Google Cloud עושה בתשתית שלה ובשיטות האבטחה שלה. אנחנו נוקטים גישה רב-שכבתית בכל היבט של אבטחת הארגון והלקוחות שלנו, כדי להגן על נתונים, מידע ומשתמשים חשובים. זהו אותו עיקרון שעל פיו עיצבנו את Connect.
בנוסף לאסטרטגיה ולעיצוב של Google להגנה מקיפה, כדאי להעריך את התוכן שמופיע כאן בהתאם למצב האבטחה ולסטנדרטים שלכם. בקטע הזה מפורטות אמצעים נוספים שאפשר לנקוט כדי להשלים את השיטות המומלצות לחיזוק האבטחה של Kubernetes.
אבטחה מרכיב לרכיב
כל רכיב של בקשת Connect מאמת את הרכיבים האחרים, ומשתף נתונים רק עם רכיבים שאומתו וקיבלו הרשאה לנתונים האלה, כפי שמוצג בתרשים הבא.
כל רכיב בבקשת Connect משתמש בנתונים הבאים כדי לאמת את הרכיבים האחרים:
- Transport Layer Security (TLS)
- אבטחת שכבת התעבורה של אפליקציה (ALTS)
- OAuth
כל רכיב של בקשת Connect משתמש בנתונים הבאים כדי לאשר את הרכיבים האחרים:
- ניהול זהויות והרשאות גישה (IAM)
- רשימות היתרים
כל חיבור בין אשכול Kubernetes לבין Google Cloud מוצפן, ולפחות עמית אחד בכל חיבור משתמש באימות מבוסס-אישור. התהליך הזה עוזר לוודא שכל פרטי הכניסה של האסימון מוצפנים במעבר, ומתקבלים רק על ידי עמיתים מאומתים ומורשים.
אימות משתמשים ב- Google Cloud
כשמשתמשים במסוף, המשתמשים עוברים את תהליך הכניסה הרגיל של Google.Google Cloud מספק אישור TLS שהדפדפן של המשתמש מאמת, והמשתמש נכנס לחשבון Google Cloud או לחשבון Google Workspace כדי לבצע אימות ל- Google Cloud. Google Cloud
הגישה לפרויקט דרך מסוף Google Cloud או ממשקי API אחרים נשלטת על ידי הרשאות IAM.
Google Cloud אימות בין שירותים
Google Cloud משתמש ב-ALTS לאימות פנימי בין שירותים. ALTS מאפשר לשירותים, כמו שרת ה-Proxy, ליצור חיבור מאומת שמוגן מפני שינויים. Google Cloud
Google Cloud השירותים צריכים לקבל הרשאה פנימית להשתמש בשרת ה-proxy כדי להתחבר למופע Connect מרוחק, כי שרת ה-proxy משתמש ברשימת היתרים של זהויות שירות כדי להגביל את הגישה.
אימות Google Cloud
הסוכן משתמש ב-TLS כדי לאמת ולהצפין כל חיבור. הסוכן מאמת אישורי TLS באמצעות קבוצה של אישורי בסיס שמוטמעים בבינארי, כדי למנוע מצב שבו אישורים שנוספו למאגר של הסוכן נחשבים בטעות כמהימנים. Google Cloud הנציג מבצע קריאות ל-API רק בנקודות קצה מאומתות בצורה נכונה. התהליך הזה עוזר לוודא שהאישורים של חשבון השירות והבקשות ל-Kubernetes API נשלחים על ידיGoogle Cloud, ושהתשובות נשלחות רק אל Google Cloud.
רשימת הדומיינים שהסוכן מתקשר איתם במהלך פעולה רגילה מופיעה במאמר איך מוודאים שיש קישוריות לרשת.
אפשר להגדיר את הסוכן כך שיתחבר Google Cloud דרך שרת proxy מסוג HTTP. בהגדרה הזו, הסוכן משתמש ב-HTTP/1.1
CONNECT מול שרת ה-proxy של HTTP ומקים חיבור TLS ל-Google Cloud. שרת ה-proxy של HTTP רואה רק את התנועה המוצפנת בין הסוכן לבין Google Cloud. השלמות והאבטחה של החיבור מקצה לקצה בין הסוכן לבין Google Cloud לא מושפעות.
אימות הנציג
הסוכן מאומת ב- Google Cloud באמצעות איחוד זהויות של עומסי עבודה של Fleet. איחוד שירותי אימות הזהות של עומסי עבודה ב-Fleet מאפשר לכם לבצע אימות מעומסי עבודה ב-Fleet ל-APIs של Google Cloud באמצעות מנגנוני אימות מובנים של Google Cloud ו-Kubernetes. כשהסוכן רוצה לבצע אימות ל- Google Cloud, הוא מחליף את האסימון של חשבון השירות ב-Kubernetes באסימון גישה שמייצג את זהות עומס העבודה שלו.
שרת Kubernetes API
הסוכן משתמש בספריית הלקוח של Kubernetes כדי ליצור חיבור TLS לשרת ה-API של Kubernetes. סביבת זמן הריצה של Kubernetes מספקת לקונטיינר של הסוכן אישור של רשות אישורים (CA) מסוג TLS, שמשמש את הסוכן לאימות שרת ה-API.
שרת ה-API מאמת כל בקשה בנפרד, כפי שמתואר בקטע הבא.
בקשת אבטחה
כל בקשה שנשלחת מ Google Cloud דרך Connect כוללת פרטי כניסה שמזהים את השולח של הבקשה: גם את שירותGoogle Cloud שיצר את הבקשה, וגם (במקרים הרלוונטיים) את משתמש הקצה שעבורו נשלחת הבקשה. האישורים האלה מאפשרים לשרת Kubernetes API לספק אמצעי בקרה של הרשאה וביקורת לכל בקשה.
אימות בין שירותים לסוכנים
כל בקשה שנשלחת ל-Agent כוללת טוקן לטווח קצר שמזהה אתGoogle Cloud השירות ששלח את הבקשה, כפי שמוצג בדיאגרמה הבאה.
הטוקן חתום על ידי חשבון שירות Google Cloud שמשויך באופן בלעדי לשירות Google Cloud . הסוכן מאחזר את המפתחות הציבוריים של חשבון השירות כדי לאמת את האסימון. הטוקן הזה לא מועבר לשרת ה-API.
הסוכן מאמת Google Cloud אישורים באמצעות שורשי CA שמוטמעים בקובץ הבינארי. התהליך הזה עוזר לוודא שהמערכת מקבלת בקשות אותנטיות שלא עברו שינוי מ- Google Cloud.
אימות משתמשי קצה
Google Cloud שירותים שגולשים באשכולות בשם משתמש מסוים צריכים את פרטי הכניסה של המשתמש כדי לבצע אימות לשרת ה-API, כפי שמוצג בתרשים הבא.
המדיניות הזו עוזרת לוודא שאותה קבוצת הרשאות חלה על המשתמש כשהוא ניגש דרך Connect. חלק מהשירותיםGoogle Cloud מבצעים אימות לשרת ה-API בשם משתמש. לדוגמה, משתמש יכול לגשת למסוף Google Cloud כדי לראות עומסי עבודה באשכולות שרשומים ב-Fleet. כשמשתמש ניגש לשירותים האלה, הוא מספק פרטי כניסה ששרת Kubernetes API מזהה: כל אחד מהאסימונים ששרת Kubernetes API תומך בהם.
Google Cloud המסוף שומר את פרטי הכניסה האלה כחלק מהפרופיל של המשתמש. האישורים האלה מוצפנים כשהם לא בשימוש, אפשר לגשת אליהם רק באמצעות פרטי הכניסה של המשתמש ל-Google Cloud או ל-Google Workspace, והם משמשים רק לחיבורים דרך Connect. אי אפשר להוריד שוב את פרטי הכניסה האלה. האישורים נמחקים כשהמשתמש מתנתק מהאשכול, כשהרישום של האשכול נמחק ב- Google Cloud, כשהפרויקט נמחק או כשחשבון המשתמש נמחק. מידע נוסף זמין במאמר מחיקת נתונים ב- Google Cloud.
כשמשתמש מקיים אינטראקציה עם Google Cloud המסוף, נוצרות בקשות לשרת ה-API של Kubernetes. השירות שולח את פרטי הכניסה של המשתמש יחד עם הבקשה דרך Connect. לאחר מכן, הסוכן מציג את הבקשה ואת פרטי הכניסה לשרת ה-API של Kubernetes.
שרת ה-API של Kubernetes מאמת את פרטי הכניסה של המשתמש, מבצע הרשאה לגבי זהות המשתמש, יוצר אירוע שמצריך בדיקה עבור הפעולה (אם הוגדר) ומחזיר את התוצאה. מכיוון שפרטי הכניסה שהמשתמש מספק משמשים לאימות הבקשה, שרת ה-API של Kubernetes מחיל את אותה מדיניות הרשאה וביקורת על בקשות Connect כמו על בקשות אחרות.
אימות משירות ל-Kubernetes
Google Cloud שירותים שניגשים לשרת Kubernetes API מחוץ להקשר של משתמש מסוים משתמשים בהתחזות ל-Kubernetes כדי לבצע אימות לשרת Kubernetes API. השיטה הזו מאפשרת לשרת Kubernetes API לספק בדיקות הרשאה ורישום ביומן ביקורת לכל שירות, כפי שמוצג בדיאגרמה הבאה.
שירותים ב- Google Cloud יכולים להשתמש ב-Connect מחוץ להקשר של המשתמש. לדוגמה, שירות כניסה (ingress) מרובה-אשכולות יכול לסנכרן באופן אוטומטי משאבי כניסה בין אשכולות. לשירותים האלה אין פרטי כניסה ששרת ה-API של Kubernetes יכול לאמת: רוב שרתי ה-API לא מוגדרים לאמת פרטי כניסה של שירותים. Google Cloud עם זאת, שרת API יכול להקצות הרשאות אימות מוגבלות לשירות אחר באמצעות התחזות, והסוכן יכול לאמת שירותים ששולחים בקשות דרך Connect. Google Cloud הם מאפשרים לבקשות לעבור דרך הסוכן כדי לבצע אימות בתור חשבונות שירות. Google Cloud
כששירות Google Cloud שולח בקשה בשמו (ולא בהקשר של משתמש), הסוכן מוסיף לבקשה את פרטי הכניסה שלו ל-Kubernetes וכותרות התחזות ל-Kubernetes שמזהות את השירות Google Cloud . הכותרות של ההתחזות מציינות שם משתמש של חשבון השירות Google Cloud שאומת על ידי הסוכן.
שרת ה-API של Kubernetes מאמת את פרטי הכניסה של הסוכן, וגם בודק אם הסוכן יכול להתחזות לחשבון השירות Google Cloud . היכולת להתחזות נשלטת בדרך כלל על ידי כללי בקרת גישה מבוססת-תפקידים (RBAC), ויכולה להיות מוגבלת לזהויות ספציפיות, כמו Google Cloud חשבונות שירות.
אם לסוכן יש הרשאה להתחזות לזהות המבוקשת, שרת ה-API מבצע בדיקות הרשאה עבור חשבון השירות Google Cloud ומטפל בבקשה. יומן הביקורת של הבקשה כולל גם את הזהות של הסוכן וגם את חשבון השירות Google Cloud שאליו הוא מתחזה.
אבטחה בתוך האשכול
בסופו של דבר, הסוכן שולח בקשות API ל-Kubernetes API לשרת Kubernetes API, כפי שמוצג בדיאגרמה הבאה.
שרת ה-API של Kubernetes מאמת את הבקשות האלה, מעניק להן הרשאה ומתעד אותן ביומן הביקורת, בדיוק כמו שהוא עושה לכל הבקשות האחרות שהוא משרת.
כפרוקסי לבקשות האלה, לסוכן יש גישה למידע אישי רגיש, כמו אישורים, בקשות ותגובות. Kubernetes והסביבה העסקית של Kubernetes מספקים קבוצה של כלים למניעת גישה של גורמים אחרים, ולעזרה בהבטחה שהסוכן יקבל גישה רק למה שהוא אמור לקבל.
אימות ב-Kubernetes
שרת ה-API של Kubernetes מאמת את השולח של כל בקשה נכנסת כדי לקבוע אילו הרשאות להחיל בשלב ההרשאה. כמו שצוין קודם, הבקשה כוללת את פרטי הכניסה של המשתמש או את פרטי הכניסה של הסוכן ל-Kubernetes וכותרות התחזות.
אדמינים של אשכולות שומרים על השליטה במנגנוני האימות שמזוהים על ידי שרת Kubernetes API. אדמינים יכולים לבטל את האישורים של משתמש, והם יכולים לבטל או לצמצם את ההרשאה של האישורים של הסוכן.
הרשאה ב-Kubernetes
שרת ה-API של Kubernetes בודק אם הזהות המאומתת מורשית לבצע את הפעולה המבוקשת במשאב המבוקש.
האדמין של האשכול יכול להשתמש בכל אחד ממנגנוני ההרשאות של Kubernetes כדי להגדיר כללי הרשאה. Connect לא מבצע בדיקות הרשאה בשם האשכול.
אבטחת הנציגים
לסוכן יש גישה לפרטי הכניסה שלו (Kubernetes ו- Google Cloud), וגם לפרטי הכניסה, לבקשות ולתשובות שעוברות דרכו. לכן, הסוכן תופס מיקום מהימן באשכול מחובר.
הסוכן מתוכנן עם עקרונות האבטחה הבסיסיים הבאים:
- הסוכן כתוב ב-Go, שכולל ניהול זיכרון עם איסוף אשפה ומונע הרבה פעולות זיכרון לא בטוחות.
- הסוכן נפרס בקובץ אימג' של קונטיינר ללא הפצה. התמונה של הסוכן לא כוללת מעטפת, libc או קוד אחר שלא קשור לנתיב הביצוע של הסוכן.
- התמונה של הנציג נוצרת על ידי תשתית בנייה משותפת של Google מקוד שנבדק. רק מערכת ה-build הזו יכולה לפרוס תמונות של סוכנים ב-Container Registry. מפתחים ב-Google Cloud לא יכולים לפרוס תמונות חדשות בעצמם. התהליך הזה עוזר לוודא שאפשר לעקוב אחרי כל העריכות במקור של הסוכן ולזהות את המחבר והבודק, כדי למנוע הכחשה.
הסוכן פועל כפריסה רגילה באשכול Kubernetes שנפרס בזמן שרשמתם את האשכול.
כתוצאה מכך, כל האפשרויות והשיטות המומלצות שזמינות למעקב אחרי פריסות, ReplicaSets ו-pods ולאבטחתם זמינות לסוכן.
המנגנונים האלה נועדו להקשות על פריצה למאגר הסוכנים. עם זאת, גישה עם הרשאות לצומת של הסוכן עדיין יכולה לסכן את סביבת הסוכן. לכן חשוב שאדמינים יפעלו בהתאם להנחיות האבטחה הרגילות של Kubernetes כדי להגן על תשתית האשכול.
אבטחת מידע באמצעות VPC Service Controls
VPC Service Controls מספק שכבת הגנה נוספת לשירותיGoogle Cloud , שהיא בלתי תלויה בניהול זהויות והרשאות גישה (IAM). בעוד ש-IAM מאפשר בקרת גישה מפורטת שמבוססת על זהויות, VPC Service Controls מאפשר אבטחת היקף רחבה יותר שמבוססת על הקשר, כולל שליטה בתעבורת נתונים יוצאת (egress) בהיקף – לדוגמה, אתם יכולים לציין שרק פרויקטים מסוימים יכולים לגשת לנתוני BigQuery שלכם. מידע נוסף על האופן שבו VPC Service Controls פועל כדי להגן על הנתונים זמין בסקירה הכללית על VPC Service Controls.
אפשר להשתמש ב-VPC Service Controls עם Connect כדי להוסיף אבטחת נתונים, אחרי שמוודאים שאפשר לגשת לשירותים הנדרשים לשימוש ב-Connect מתוך גבולות הגזרה שצוינו.
אם רוצים להשתמש ב-VPC Service Controls, צריך להפעיל את ממשקי ה-API הבאים:
cloudresourcemanager.googleapis.comgkeconnect.googleapis.comgkehub.googleapis.com
צריך גם להגדיר קישוריות פרטית כדי לקבל גישה לממשקי ה-API הרלוונטיים. הוראות מפורטות מופיעות במאמר הגדרת קישוריות פרטית.