אבטחת שער

בדף הזה מתוארות שיטות שונות לאבטחת שערים ב-Google Kubernetes Engine ‏(GKE). איך מאבטחים שער

איך פועלת האבטחה של Gateway

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

  • סיום TLS: השער מסיים את חיבורי ה-TLS של הלקוח בקצה הקדמי של השער באמצעות אישורי SSL מנוהלים או בניהול עצמי. אפשר להשתמש ב-BackendTLSPolicy כדי להצפין מחדש את תעבורת הנתונים בין השער לבין Pods בקצה העורפי.
  • מעבר TLS: תנועת TLS מוצפנת עוברת ישירות דרך השער לפודים לקצה העורפי, בלי שמאזן העומסים יסיים או יפענח את התנועה. אתם משתמשים במשאבי TLSRoute כדי לנתב תנועה על סמך שם המארח של Server Name Indication ‏(SNI).

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

סיום TLS בהשוואה למעבר TLS

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

סיום TLS

בסיום TLS, השער מסיים את חיבורי ה-TLS מלקוחות בחזית של מאזן העומסים.

כשמגדירים מאזין של Gateway עם השדה tls.mode שמוגדר ל-Terminate והשדה protocol שמוגדר ל-HTTPS, מצרפים אישורי TLS ישירות ל-Gateway באמצעות סודות של Kubernetes, אישורי SSL או Certificate Manager.

המאפיינים העיקריים של סיום TLS כוללים:

  • בדיקה בשכבה 7: מכיוון שהשער מפענח את התנועה של הלקוח, הוא יכול להעריך את מאפייני בקשת ה-HTTP (כמו כותרות, נתיבים ושיטות) ולנתב את התנועה באמצעות משאבי HTTPRoute.
  • אבטחת קצה: מאפשרת שילוב עם כללי מדיניות האבטחה של Google Cloud Armor, כללי חומת אש ליישומי אינטרנט (WAF) ושמירה במטמון קצה של Cloud CDN.
  • הצפנת קצה עורפי באמצעות BackendTLSPolicy: אם עומסי העבודה שלכם דורשים הצפנה מקצה לקצה במעבר, אתם יכולים להגדיר משאב BackendTLSPolicy כדי להצפין מחדש את התנועה בין השער לבין Pods של הקצה העורפי.

בתרשים הבא מוצג איך GKE Gateway מצפין את שני נתיבי התנועה כשמשתמשים בסיום TLS עם הצפנת קצה עורפי. לקוח חיצוני שולח בקשת HTTPS מוצפנת (https://example.com) לשער ברשת של ענן וירטואלי פרטי (VPC), שבה מאזן העומסים מסיים את חיבור ה-TLS. לאחר מכן, מאזן העומסים יוצר חיבור נפרד ומוצפן מחדש כדי להעביר את התנועה לפודים של Store בקצה העורפי באשכול GKE:

הצפנה מלקוח לשער ומשער לקצה העורפי עם סיום TLS

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

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

העברת TLS ללא שינוי

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

כשמגדירים מאזין של Gateway כשהשדה tls.mode מוגדר ל-Passthrough והשדה protocol מוגדר ל-TLS, ה-Gateway לא מסיים את ה-TLS או מחזיק אישורי SSL. במקום זאת, מאזן העומסים בודק רק את שם המארח הלא מוצפן של Server Name Indication ‏(SNI) בלחיצת היד של TLS ClientHello, ומנתב את הסטרימינג הגולמי המוצפן של TCP לפודים של קצה עורפי באמצעות משאבי TLSRoute.

המאפיינים העיקריים של מעבר TLS כוללים:

  • הצפנה מקצה לקצה: התנועה נשארת מוצפנת לאורך כל המעבר מהלקוח ל-Pods בקצה העורפי. אפליקציית הקצה העורפי מנהלת את האישורים, מסיימת את ה-TLS ומפענחת את המטען הייעודי (payload).
  • אין צורך בניהול אישורים ב-Gateway: אתם לא מצרפים אישורים או סודות של Kubernetes למאזין של Gateway.
  • שרת proxy בשכבה 4: מאזן העומסים מעביר זרמי TCP מוצפנים ומנתב את התנועה על סמך מטא-נתונים לא מוצפנים של לחיצת יד בפרוטוקול TLS (כמו שם המארח של SNI) באמצעות משאבי TLSRoute.
  • פשרות אבטחה חלופית: מעבר TLS מתאים לדרישות תאימות שבהן אי אפשר לשתף מפתחות פרטיים עם תשתית הענן, או לפרוטוקולים מבוססי-TLS שאינם HTTP. עם זאת, הוא מונע בדיקה של מאזן העומסים בשכבה 7 ושירותי אבטחה בקצה הרשת, כמו כללי WAF של Google Cloud Armor.

בתרשים הבא מוצג איך Gateway מצפין ומנתב תנועה מהלקוח אל Pods לקצה העורפי כשמשתמשים ב-TLS passthrough. הלקוח שולח בקשת TLS מוצפנת עם שם המארח store.example.com SNI אל השער, שמעביר את הסטרימינג המוצפן בלי פענוח ישירות אל Pods של Store:

מעבר TLS מוצפן מקצה לקצה מהלקוח לפודים של הקצה העורפי

מידע נוסף על פריסת שער מעבר של TLS עם TLSRoute זמין במאמר פריסת שער מעבר של TLS.

יתרונות

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

מי הבעלים של הדומיין ושל הגדרת ה-TLS?

במודל Gateway API יש שני תפקידים שמשתמשים בשערים או פורסים אותם:

  • אדמין של פלטפורמה: מפעיל האשכול הוא האדמין של אשכולות שלמים. הם מנהלים את כללי המדיניות, הגישה לרשת וההרשאות של האפליקציות.
  • מפתח האפליקציה: מפתח האפליקציה מגדיר את האפליקציה ואת הגדרת השירות.

בתרשים הבא מוצגים השדות במשאבים Gateway ו-HTTPRoute שמשפיעים על הבעלות על הדומיין ועל TLS בשתי אפליקציות, store-v1 ו-store-v2.

בתרשים, מפעיל האשכול שולט על:

  • אילו דומיינים מפתחי אפליקציות יכולים להשתמש בהם לאפליקציות שלהם בכל מרחב שמות.
  • האישורים הספציפיים שמסיימים דומיינים שונים.
  • אישורים שסופקו על ידי הבעלים של השער.
  • אם הבעלים של HTTPRoute יכולים לציין שמות מארחים משלהם ליצירת אישורים.

מפתחי האפליקציות שולטים בשם המארח שיוצר אישור, אם ההגדרה של Gateway מאפשרת זאת.

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

ניהול אישורים של שערים

אפשר לאבטח את השערים באחת מהשיטות הבאות:

אם אתם משתמשים בסודות של Kubernetes או במשאבי SslCertificate מ-Compute Engine API, אתם יכולים לצרף עד 15 אישורים לשער אחד.

אם תבקשו להגדיל את המכסה,תוכלו לצרף עד 10,000, 000 אישורים לכל מאזן עומסים באמצעות Certificate Manager.

מידע נוסף על אישורי SSL זמין במאמר סקירה כללית על אישורי SSL. Google Cloud

סודות של Kubernetes

מפרט Gateway API תומך בסודות של Kubernetes לאחסון אישורים וצירוף שלהם לשערים. אפשר לשייך סוד אחד או יותר של Kubernetes לשער באמצעות השדה Gateway.spec.tls.certificateRef.

אלה הדרישות לגבי משאבי Gateway שמאובטחים באמצעות סודות של Kubernetes:

  • צריך להגדיר את מאזין השער port ו-protocol ל-443 ו-HTTPS.
  • צריך להגדיר את השדה listener.tls.mode לערך Terminate.
  • צריך להפנות לפרטי הכניסה של TLS בבלוק listeners.tls.

למשאבי Gateway שמאובטחים באמצעות Kubernetes Secrets יש את המגבלות הבאות:

  • רק מאזינים מסוג HTTPS מסיימים את התנועה באמצעות הסודות שצוינו, אבל אפשר לציין כמה מאזינים עם שילוב של HTTP ו-HTTPS.
  • אם יש לכם כמה מאזינים שמשתמשים ב-HTTPS באותו שער, לכל מאזין צריך להיות שם מארח ייחודי.
  • אפשר להשמיט רק שם מארח אחד או להקצות את הערך * לכל זוג של יציאה ופרוטוקול.
  • אפשר להקצות רק אישור ברירת מחדל אחד לכל שער.

במאמר אבטחת שער באמצעות סוד של Kubernetes מוסבר איך לאבטח שער באמצעות סוד של Kubernetes.

אישורי SSL

אישורי SSL מאחסנים אישורים ומעבירים אותם למאזני עומסים. אישור SSL יכול להיות בניהול עצמי או בניהול Google.

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

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

ההיקף והמיקום של אישור ה-SSL חייבים להתאים להיקף ולמיקום של השער שמשתמש בו. לדוגמה, אי אפשר להשתמש באישור SSL גלובלי בשער אזורי.

בטבלה הבאה מפורטות דרישות ההיקף ודרישות לגבי מיקומים של אישורי SSL לכל GatewayClass:

GatewayClass היקף אישור ה-SSL מיקום אישור ה-SSL
gke-l7-global-external-managed אישור SSL גלובלי עולמי
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc
gke-l7-regional-external-managed אישור SSL אזורי חייב להיות באותו אזור כמו השער
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb
gke-l7-rilb-mc

אישורי SSL בניהול Google לא תואמים לשערים אזוריים. כדי לאבטח שערים אזוריים, השתמשו ב-Certificate Manager במקום זאת.

במאמר אבטחת שער באמצעות אישור SSL מוסבר איך לאבטח שער באמצעות אישור SSL.

Certificate Manager

Certificate Manager הוא מיקום מרכזי לניהול אישורי TLS.

כשמאבטחים שער באמצעות Certificate Manager, אפשר:

  • הפניה ל-CertificateMap ישירות משער שיצרתם ב-Certificate Manager.
  • לנהל את האישורים שלכם.
  • לשפר את זמני ההפצה של האישורים.
  • להשתמש ב-Cloud Monitoring כדי לבדוק אם יש אישורים שפג תוקפם ולהפיץ אישורים.

Certificate Manager תומך באישורי SSL בניהול עצמי ובניהול Google. כדי ללמוד איך לאבטח שער באמצעות Certificate Manager, ראו אבטחת שער באמצעות Certificate Manager.

תמיכה ב-TLS ב-GatewayClass

בטבלה הבאה מתוארות השיטות לסיום TLS שנתמכות ב-GKE לכל GatewayClass:

GatewayClass gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc 		gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc 		gke-l7-cross-regional-internal-managed-mc
‫TLS (אבטחת שכבת התעבורה) מלקוח לשער ‫יש תמיכה ‫יש תמיכה
‫TLS מהשער לבק-אנד ‫יש תמיכה ‫יש תמיכה
משאב אישורGoogle Cloud אישור SSL גלובלי
CertificateMap		 אישור SSL אזורי
מעבר TLS ‏(TLSRoute) ‫אין תמיכה ‫יש תמיכה ‫יש תמיכה
אישורים בניהול עצמי עם סודות של Kubernetes ‫יש תמיכה ‫יש תמיכה ‫אין תמיכה
אישורי SSL בניהול עצמי ב-Compute Engine ‫יש תמיכה ‫יש תמיכה ‫אין תמיכה
אישורי SSL בניהול Google ל-Compute Engine ‫יש תמיכה ‫אין תמיכה ‫אין תמיכה
אישורי SSL בניהול עצמי באמצעות Certificate Manager ‫יש תמיכה ‫יש תמיכה ‫יש תמיכה
אישורי SSL שמנוהלים על ידי Google באמצעות Certificate Manager ‫יש תמיכה ‫יש תמיכה ‫יש תמיכה

הרשאה ובקרת גישה

שערי GKE תומכים בבקרת גישה מבוססת-זהות באמצעות המשאב המותאם אישית GCPAuthzPolicy. המשאב הזה מאפשר למנהלי פלטפורמות להגדיר כללי ALLOW או DENY מפורשים לתנועה מצפון לדרום.

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

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