יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

Autopilot Standard

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

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

ארכיטקטורה וזרימת תנועה

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

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

Pod של עומס עבודה יוזם תעבורת נתונים יוצאת לנקודת קצה (endpoint) חיצונית או ליעד באינטרנט.
שרת ה-proxy המקומי של צומת הסביבה בשכבה 4 מיירט את הבקשה היוצאת בצומת.
שרת ה-proxy של הצומת יוצר מנהרת HTTP CONNECT לשער תעבורת הנתונים היוצאת.
אם Secure Web Proxy נמצא באותה רשת VPC, התנועה מתחברת ישירות לשער. אם ה-Secure Web Proxy נמצא ברשת VPC אחרת, התנועה עוברת דרך צירוף שירות PSC.
‫Secure Web Proxy מסיים את המנהרה, אוכף את כללי האבטחה שהוגדרו לתעבורת נתונים יוצאת ומעביר את הבקשות המורשות ליעד.

מגבלות

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

כללי מדיניות ברמת מרחב השמות: כללי מדיניות ניתוב תעבורת נתונים יוצאת חלים רק ברמת מרחב השמות. אין תמיכה בבחירת Pod פרטנית באמצעות בוררי תוויות.
סינון לפי שם מארח מחייב בדיקת TLS: כללי המדיניות של Secure Web Proxy יכולים לסנן תנועה יוצאת רק לפי כתובת IP, אלא אם בדיקת TLS מופעלת.
‫Workload Identity: Ambient Networking ב-GKE תומכות ב-Workload Identity רגיל. בגרסת טרום-השקה (Preview) הזו אין תמיכה במאגרים מנוהלים של Agent 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, אתם צריכים להתקין באופן ידני את אישור האמון בקובצי האימג' של הקונטיינר.

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

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

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

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

‫Secure Web Proxy / Network Services: ‏networkservices.gateways.* (או roles/networkservices.admin) כדי להגדיר משאבים של שער Secure Web Proxy.
ניהול PSC (פריסות חוצות-VPC בלבד): compute.networkAttachments.list (או roles/compute.networkAdmin) לניהול חיבורי Private Service Connect.
‫GKE Management: roles/container.clusterAdmin לפריסת משאבים בהתאמה אישית (GCPBackend, GCPEgressPolicy).

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

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

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

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

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

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

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

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

אותו VPC

שומרים את המניפסט הבא בתור swp-backend.yaml:
```
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.
- ‫SWP_NAME: השם של Secure Web Proxy.
מחילים את המשאב GCPBackend:
```
kubectl apply -f swp-backend.yaml
```

בין רשתות VPC שונות

שומרים את המניפסט הבא בתור swp-backend.yaml:
```
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: האזור שבו נפרס צירוף השירות של PSC.
- ‫ATTACHMENT_NAME: השם של צירוף השירות של PSC, אם ה-Secure Web Proxy נמצא ברשת VPC אחרת.
מחילים את המשאב GCPBackend:
```
kubectl apply -f swp-backend.yaml
```

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

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

שומרים את המניפסט הבא בתור 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).
מחילים את המשאב GCPEgressPolicy:
```
kubectl apply -f swp-egress-policy.yaml
```
אחרי שמחילים את המדיניות, תנועה יוצאת מעומסי עבודה במרחב השמות מופנית אל Secure Web Proxy.

פתרון בעיות

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

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