אבטחת שער

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

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

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

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

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

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

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

יתרונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סודות ב-Kubernetes

מפרט Gateway API תומך בסודות של Kubernetes לאחסון אישורים ולצירוף שלהם ל-Gateways. אפשר לשייך סוד 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 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 של ה-Backend ‫יש תמיכה ‫יש תמיכה
משאב אישורGoogle Cloud אישור 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 לאימות זהויות) כדי להעריך בקשות בזמן אמת.

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