ניתוב תעבורת נתונים יוצאת (egress) של סביבת העבודה דרך Secure Web Proxy

בדף הזה מוסבר איך להגדיר ניתוב של תעבורת נתונים יוצאת (egress) לעומסי עבודה שפועלים ברשת סביבתית (ambient) של Google Kubernetes Engine ‏(GKE) לשער Secure Web Proxy ‏(SWP).

הפניית תעבורת נתונים יוצאת דרך שער Secure Web Proxy מאפשרת לאכוף מדיניות אבטחה מרכזית של יציאה – כמו סינון כתובות URL, רשימות היתרים של דומיינים ובדיקת TLS – בלי לשנות את קוד האפליקציה. פרוקסי הצומת בשכבה 4 מיירט תעבורה יוצאת מחוץ ל-Pod של האפליקציה, ומספק בידוד אבטחה מחוץ ל-Pod גם אם קונטיינר של עומס עבודה נפרץ.

אדריכלות וזרימת תנועה

במודל הפריסה הזה, אתם שומרים על הבעלות על התשתית, כולל אשכול GKE, מופע Secure Web Proxy ונקודות קצה (endpoints) של Private Service Connect ‏(PSC).

כך פועלת תעבורת הנתונים היוצאת:

1. תעבורת נתונים יוצאת מופעלת על ידי פוד של עומס עבודה או סוכן AI לנקודת קצה חיצונית או ליעד באינטרנט.
2. פרוקסי מקומי של צומת סביבתי בשכבה 4 מיירט את הבקשה היוצאת בצומת.
3. ה-Proxy של הצומת יוצר מנהרת HTTP CONNECT לשער היציאה.
4. אם Secure Web Proxy נמצא ברשת VPC אחרת, התנועה עוברת דרך PSC Service Attachment.
5. ה-Secure Web Proxy מסיים את המנהרה, אוכף את מדיניות האבטחה שהוגדרה ליציאה ומעביר בקשות מאושרות ליעד.

מגבלות

לפני שמגדירים ניתוב יציאה של Secure Web Proxy, חשוב לעיין במגבלות הבאות בגרסת הבטא:

• כללי מדיניות ברמת מרחב השמות: כללי מדיניות לניתוב תעבורה יוצאת חלים רק ברמת מרחב השמות. אין תמיכה בבחירה מדויקת של פודים באמצעות בוררי תוויות.
• סינון לפי שם מארח מחייב בדיקת TLS: מדיניות של Secure Web Proxy יכולה לסנן תנועת יציאה רק לפי כתובת IP, אלא אם מופעלת בדיקת TLS.
• Workload Identity: רישות ברקע ב-GKE תומך ב-Workload Identity רגיל. אין תמיכה במאגרי זהויות של סוכנים מנוהלים בגרסת הטרום-השקה הזו.
• אימות: החיבור בין שרת ה-proxy של הצומת הסביבתי לבין Secure Web Proxy מדלג על אימות אישור השרת. בקשת ה-CONNECT כוללת טוקן לא מוגבל לצד אישור הלקוח.
• יצירה מחדש של משאבים בעדכוני הגדרות: שינויים שבוצעו במופע קיים של Secure Web Proxy או בהגדרת PSC לא מועברים באופן אוטומטי. אם מעדכנים את ההגדרה של Secure Web Proxy או של PSC, צריך למחוק את משאב GCPEgressPolicy ואת המופע של Secure Web Proxy וליצור אותם מחדש כדי שהשינויים יחולו.
• נקודת אמון לבדיקת TLS:‏ GKE לא מחדיר באופן אוטומטי את אישור ה-CA הפרטי של Secure Web Proxy למאגרי עומסי העבודה. אם אתם משתמשים בבדיקת TLS, אתם צריכים להתקין ידנית את אישור המהימנות בקובצי האימג' של הקונטיינר.

דרישות מוקדמות

לפני שמגדירים ניתוב של תעבורת נתונים יוצאת (egress), צריך לוודא שיש לכם את הדברים הבאים:

• אשכול GKE עם רשת סביבתית מופעלת. הוראות זמינות במאמר הכנת רשתות סביבתיות ב-GKE.
• מופע של Secure Web Proxy שנפרס עם serverTlsPolicy שהוגדר עם clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT בCloud de Confiance by S3NS פרויקט או ב-VPC משותף.
• אם Secure Web Proxy נמצא ברשת VPC שונה מזו של אשכול GKE:
  • ‫PSC Service Attachment שנוצר עבור Secure Web Proxy.
  • נקודת קצה של צרכן PSC שהוגדרה ברשת ה-VPC של אשכול GKE.

כדי לבצע את השלבים האלה, אתם צריכים להיות בעלי התפקידים הבאים:

• שער לסוכן / שירותי רשת: networkservices.agentGateways.* (או roles/networkservices.admin) כדי להגדיר משאבי שער לסוכן.
• ניהול PSC: compute.networkAttachments.list (או roles/compute.networkAdmin) כדי לנהל חיבורים של Private Service Connect.
• ניהול GKE: roles/container.clusterAdmin לפריסת משאבים בהתאמה אישית (GCPBackend, GCPEgressPolicy).

הגדרת מהימנות לבדיקת TLS

אם במדיניות של Secure Web Proxy נעשה שימוש בבדיקת TLS כדי לבדוק תעבורה יוצאת מוצפנת, ה-proxy יוצר אישורים שחתומים על ידי רשות האישורים (CA) הפרטית שלו כדי להתחזות ליעדים חיצוניים.

אפליקציית עומס העבודה צריכה לתת אמון באישור ה-CA הפרטי שמוצג על ידי Secure Web Proxy. מכיוון ש-GKE לא מחדיר את התעודה הזו באופן אוטומטי, צריך להתקין את אישור ה-CA של SWP (ישות עוגן אמינה) במאגר האישורים של הקונטיינר.

כדי להוסיף את אישור ה-CA לקובץ האימג' בקונטיינר, צריך לכלול את השורות הבאות בקובץ ה-Dockerfile:

COPY swp-ca-cert.pem /usr/local/share/ca-certificates/swp-ca-cert.crt
RUN update-ca-certificates

הגדרת נקודת הקצה של השער

השלב הראשון בהגדרת ניתוב יציאה סביבתי הוא יצירת נקודת קצה של שער, שמגדירה את נקודת הקצה של Secure Web Proxy באשכול GKE ומעדכנת את הרשת הסביבתית לגבי המיקום של ה-proxy.

כדי לציין את ה-URI של Secure Web Proxy או של קובץ מצורף לשירות Private Service Connect ‏(PSC), יוצרים GCPBackend משאב בהתאמה אישית באשכול GKE:

1. שומרים את קובץ המניפסט הבא בשם swp-backend.yaml:

   אותו VPC

   apiVersion: networking.gke.io/v1
   kind: GCPBackend
   metadata:
     name: swp-backend
     namespace: ambient-test
   spec:
     serviceUris:
     - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SWP_NAME
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ambient-test: מרחב השמות שרשום ל-Ambient Networking.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance by S3NS .
   • ‫REGION: האזור שבו נפרס Secure Web Proxy או PSC Service Attachment.

   • ‫SWP_NAME: השם של Secure Web Proxy.

   Cross-VPC

   apiVersion: networking.gke.io/v1
   kind: GCPBackend
   metadata:
     name: swp-backend
     namespace: ambient-test
   spec:
     serviceUris:
     - //compute.googleapis.com/projects/PROJECT_ID/regions/REGION/serviceAttachments/ATTACHMENT_NAME
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ambient-test: מרחב השמות שרשום ל-Ambient Networking.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance by S3NS .
   • ‫REGION: האזור שבו נפרס Secure Web Proxy או PSC Service Attachment.
   • ‫ATTACHMENT_NAME: השם של PSC Service Attachment, אם Secure Web Proxy נמצא ברשת VPC אחרת.

2. החלת המשאב GCPBackend:

   kubectl apply -f swp-backend.yaml
   

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

יוצרים משאב מותאם אישית GCPEgressPolicy כדי להפנות תנועה יוצאת ממרחב השמות אל שער Secure Web Proxy. הפעולה הזו מספקת את האיתות שנדרש לשרת ה-proxy של הצומת הסביבתי כדי ליצור מנהרת HTTP CONNECT ל-Secure Web Proxy, שנדרשת לניתוב יציאה.

1. שומרים את קובץ המניפסט הבא בשם swp-egress-policy.yaml:

   apiVersion: networking.gke.io/v1
   kind: GCPEgressPolicy
   metadata:
     name: swp-egress-policy
     namespace: ambient-test
   spec:
     to:
       excludeCIDRRanges:
       - "CLUSTER_CONTROL_PLANE_CIDR"
     proxyRef:
       group: networking.gke.io
       kind: GCPBackend
       name: swp-backend
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ambient-test: מרחב השמות שרשום לשימוש ב-Ambient Networking.
   • ‫CLUSTER_CONTROL_PLANE_CIDR: טווח ה-CIDR לתקשורת פנימית שצריכה לעקוף את Secure Web Proxy (למשל, טווח הכתובות של מישור הבקרה של GKE או רשתות משנה פנימיות של VPC).

2. החלת המשאב GCPEgressPolicy:

   kubectl apply -f swp-egress-policy.yaml
   

   אחרי שהמדיניות מוחלת, תעבורה יוצאת מעומסי עבודה במרחב השמות מופנית מחדש ל-Secure Web Proxy.

פתרון בעיות

ההנחיות הבאות יעזרו לכם לאבחן ולפתור בעיות בניתוב יציאה סביבתי:

• התנועה לא מגיעה ל-Secure Web Proxy:
  • מוודאים שהמשאב GCPBackend מפנה לערך ה-URI הנכון של PSC Service Attachment.
  • מוודאים שנקודת הקצה של PSC נוצרה והתקבלה ב-VPC של היצרן.
  • בודקים שexcludeCIDRRanges ב-GCPEgressPolicy לא תואם בטעות לתנועה ליעד.
• כשלים בחיבור mTLS:
  • מוודאים ש-Secure Web Proxy מוגדר לקבל חיבורים משרת ה-proxy של הצומת.
• שגיאות באישור של בדיקת TLS:
  • אם בקשות של לקוחות נכשלות בגלל שגיאות באימות האישור (למשל x509: certificate signed by unknown authority), צריך לוודא שאישור ה-CA של Secure Web Proxy מותקן בצורה תקינה במאגר אישורי המערכת של קונטיינר העומס.