אבטחת שער

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

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

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

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

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

בדף הזה מוסבר איך לאבטח את הנתיב מהלקוח אל השער באמצעות אישורים שהועלו ונוהלו ברמת השער. כדי ללמוד איך לאבטח את התנועה משער הכניסה אל ה-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.

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

סודות של Kubernetes

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

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

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

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

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

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