אבטחת שער

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

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

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

  • מהלקוח אל השער: תנועת נתונים שמקורה בלקוח ומסתיימת בשער.
  • שער לקבוצת Pod: תעבורת נתונים שמקורה בשער ומסתיימת בקבוצות ה-Pod של השרת העורפי.

בתרשים הבא מוצגים שני הנתיבים לאימות ולהצפנה של שערים:

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

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

יתרונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סודות ב-Kubernetes

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

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

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

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

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

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

אישורי SSL

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

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

מידע נוסף על ההבדלים בין שני סוגי האישורים האלה זמין בסקירה הכללית על אישורי 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 בבק-אנד ‫יש תמיכה ‫יש תמיכה
Cloud de Confiance משאב אישור אישור SSL גלובלי
CertificateMap		 אישור SSL אזורי
אישורים בניהול עצמי עם סודות ב-Kubernetes ‫יש תמיכה ‫יש תמיכה ‫אין תמיכה
אישורי SSL בניהול עצמי ב-Compute Engine ‫יש תמיכה ‫יש תמיכה ‫אין תמיכה
אישורי SSL ב-Compute Engine שמנוהלים על ידי Google ‫יש תמיכה ‫אין תמיכה ‫אין תמיכה
אישורי SSL בניהול עצמי באמצעות Certificate Manager ‫יש תמיכה ‫יש תמיכה ‫יש תמיכה
אישורי SSL שמנוהלים על ידי Google באמצעות Certificate Manager ‫יש תמיכה ‫יש תמיכה ‫יש תמיכה

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

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

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

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