הכנה של רשתות סביבתיות ב-GKE

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

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

דרישות מוקדמות ומגבלות

לפני שמגדירים את התכונה 'רשתות סביבתיות', חשוב לעיין במגבלות התכונה הבאות, בדרישות הגרסה ובמגבלות ההיקף:

  • גרסת GKE: נדרשת גרסת GKE‏ 1.35.2-gke.1842000 ואילך.
  • תמיכה אזורית: צריך ליצור את האשכולות באזור שנתמך על ידי Regional Cloud Service Mesh.
  • יכולת פעולה הדדית של עומסי עבודה: עומסי עבודה שרשומים לשימוש ב-Ambient Networking לא יכולים לפעול באופן הדדי עם עומסי עבודה שמוזרקים ל-sidecar או עם gRPC בלי שרת Proxy בתצוגה מקדימה פרטית.
  • תכונות שלא נתמכות:
    • שדה Kubernetes Service trafficDistribution.
    • שירותים שמנותקים מהקצה הקדמי.
    • GKE Sandbox‏ (gVisor).
  • הודעת אבטחה: אם הרכיב gke-ambient-nriplugin לא זמין בצומת, יכול להיות שניתן יהיה לעקוף את האכיפה של אימות והרשאה של תנועה נכנסת.

לפני שמתחילים

מבצעים את שלבי ההגדרה המקדימים הבאים ב- Cloud de Confiance by S3NS:

  1. יוצרים או בוחרים פרויקט.

  2. מפעילים את ממשקי ה-API הנדרשים:

    gcloud services enable \
    privateca.googleapis.com \
    gkehub.googleapis.com \
    compute.googleapis.com \
    container.googleapis.com \
    trafficdirector.googleapis.com \
    networkservices.googleapis.com \
    networksecurity.googleapis.com \
    telemetry.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com

  3. הגדרת אימות מנוהל של Workload Identity ל-GKE

הפעלת רשתות סביבתיות באשכול חדש

מריצים את הפקודה הבאה כדי ליצור אשכול GKE חדש עם הפעלת רשתות סביבתיות:

  1. יצירת אשכול GKE עם רשתות סביבתיות מופעלות

    gcloud beta container clusters create CLUSTER_NAME \
    --machine-type=e2-standard-4 \
    --enable-ambient-networking \
    --enable-dataplane-v2 \
    --enable-fleet \
    --gateway-api=standard \
    --location=CLUSTER_LOCATION \
    --release-channel=rapid \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog

    שני DaemonSets פועלים עכשיו במרחב השמות gke-managed-ambient.

הפעלת רשתות סביבתיות באשכול קיים

כדי להפעיל רשת Mesh סביבתית באשכול GKE קיים:

  1. מוודאים שהאשכול עומד בדרישות הבאות:

    • גרסה 1.35.2-gke.1842000 ומעלה.
    • GKE Dataplane V2 מופעל.
    • סוג המכונה צריך להיות e2-standard-4 או גדול יותר.
    • צריך להוסיף את האשכול ל-Fleet.
    • בקטע הזה מוסבר איך להפעיל את Gateway API ואת Workload Identity באשכול.

  2. הפעלת רשתות סביבתיות באשכול קיים:

    gcloud beta container clusters update CLUSTER_NAME \
    --enable-ambient-networking \
    --location=CLUSTER_LOCATION \
    --enable-fleet

    שני DaemonSets פועלים עכשיו במרחב השמות gke-managed-ambient.

  3. כדי לאמת, מפנים את ה-CLI אל האשכול:

    gcloud beta container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION

  4. מקבלים את ה-daemonsets במרחב השמות gke-managed-ambient:

    kubectl get daemonset -n gke-managed-ambient

    הפלט אמור להיראות כך:

    NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
gke-ambient-nriplugin   9         9         9       9            9           4d1h
gke-ambient-proxy       9         9         9       9            9           4d1h

הרשמה למרחב שמות לרשתות סביבתיות

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

  1. פריסת אפליקציה לדוגמה:

    kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: ambient-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: client
  namespace: ambient-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: server
  namespace: ambient-test
---
apiVersion: v1
kind: Service
metadata:
  name: server
  namespace: ambient-test
  labels:
    app: server
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: client
  namespace: ambient-test
  labels:
    app: client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: client
  template:
    metadata:
      labels:
        app: client
    spec:
      serviceAccountName: client
      containers:
      - name: nginx
        image: nginx:1.29.6
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  namespace: ambient-test
  labels:
    app: server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
    spec:
      serviceAccountName: server
      containers:
      - name: nginx
        image: nginx:1.29.6
        readinessProbe:
          httpGet:
            path: /
            port: 80
EOF

  2. מוסיפים תווית למרחב השמות ambient-test כדי להפעיל הפניה אוטומטית של תנועה דרך שרת ה-proxy של GKE:

    kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambient

  3. מוודאים שרכיבי Pods בודדים במרחב השמות הוגדרו להפניית תנועה:

    kubectl get pods -n ambient-test -o yaml | grep redirection

    הפלט אמור להיראות כך:

    ambient.networking.gke.io/redirection: enabled
ambient.networking.gke.io/redirection: enabled

  4. בודקים את התעבורה מהלקוח לשרת:

    kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

  5. כדי לוודא שתעבורת טקסט פשוט עוברת דרך gke-ambient-proxy, בודקים את יומני הגישה ב-Logs Explorer ומחפשים את gke-ambient-node-proxy-accesslog:

    כניסה לדף Logs Explorer

  6. אפשר גם להפעיל יצירה של מדדים בשכבה 4 לעומסי עבודה במרחב השמות:

    kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabled

    אחרי ההפעלה, מדדי עומסי העבודה זמינים ב-Cloud Monitoring דרך Network Services Monitoring.

הפעלת mTLS לשירות

אחרי שמפעילים הפניה מחדש של תנועה לעומסי עבודה במרחב שמות, צריך להחיל מדיניות כדי לאכוף הצפנה, אימות והרשאה.

  1. הגדרת מדיניות mTLS מתירה בעומסי עבודה בצד השרת:

    kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPServerTLSPolicy
metadata:
  name: server
  namespace: ambient-test
spec:
  mtlsMode: Permissive
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
EOF

    המדיניות הזו מאפשרת ל-Pods לקבל תעבורת נתונים גם באמצעות mTLS וגם באמצעות טקסט לא מוצפן. שימו לב: ב-mTLS מתירני נעשה שימוש בהאזנה לתעבורה כדי לזהות אם התעבורה היא mTLS או טקסט רגיל. הפעולה הזו תשבש את תעבורת הנתונים של האפליקציה שמשתמשת ב-TLS משלה או בפרוטוקול מסוג 'השרת מדבר ראשון' כמו MySQL.

  2. מוודאים שהבקר קיבל את המדיניות:

    kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

    הפלט אמור להיראות כך:

    [...]

    Conditions:
    Last Transition Time:  2026-03-25T17:47:30Z
    Message:
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Controller Name:         networking.gke.io/dpv2-1n
Events:
Type    Reason  Age                   From                   Message
----    ------  ----                  ----                   -------
Normal  Sync    108s (x2 over 2m20s)  sc-dpv2-1n-controller  Sync on Mesh dpv2-1n-fqtx-mesh succeeded

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

  3. מגדירים מדיניות mTLS בצד הלקוח שמכוונת לשירות:

    kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPClientTLSPolicy
metadata:
  name: server-mtls
  namespace: ambient-test
spec:
  targetRefs:
  - group: ""
    kind: Service
    name: server
  subjectAltNames:
  - uri: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/server
EOF

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

  4. מוודאים שהבקר קיבל את המדיניות:

    kubectl describe gcpclienttlspolicies -n ambient-test server-mtls | grep -A50 Status

    הפלט אמור להיראות כך:

    [...]
Status:
Conditions:
    Last Transition Time:  2024-10-13T01:15:03Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted

  5. בודקים את התעבורה מהלקוח לשרת:

    kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

    תעבורת הנתונים מ-Pods שרשומים ב-ambient networking לשירות השרת במרחב השמות ambient-test צריכה להשתמש עכשיו ב-mTLS.

  6. כדי לוודא שהחיבורים משתמשים ב-mTLS, בודקים את יומני הגישה ב-Logs Explorer ומחפשים את השם של היומן המותאם אישית:

    כניסה לדף Logs Explorer

  7. מעדכנים את GCPServerTLSPolicy הקיים כדי לשנות את mode מ-Permissive ל-Strict בשירות השרת, כך שפודים של עומס העבודה לא יקבלו יותר תעבורת נתונים בטקסט לא מוצפן:

    kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPServerTLSPolicy
metadata:
  name: server
  namespace: ambient-test
spec:
  mtlsMode: Strict
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
EOF

  8. מוודאים שהמדיניות אושרה:

    kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

    הפלט אמור להיראות כך:

    Name:         server

<...>

UID:                 e4f2a7a3-69aa-4528-8ea6-6f1bf2142011
Spec:
Mtls Mode:  Strict
Target Refs:
Group:
Kind:   Pod
Selector:
  Match Labels:
    App:  server
Status:
Ancestors:
    Ancestor Ref:
    Group:
    Kind:   Pod
    Name:   app=server
    Conditions:
    Last Transition Time:  2026-03-25T22:33:54Z
    Message:
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Controller Name:         networking.gke.io/dpv2-1n
Events:
Type    Reason  Age                  From                   Message
----    ------  ----                 ----                   -------
Normal  Sync    43s (x5 over 4m57s)  sc-dpv2-1n-controller  Sync on Mesh dpv2-1n-2cdi-mesh succeeded

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

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

    kubectl create namespace noambient-test && \
kubectl run -it -n noambient-test --rm curl --image=nginx -- \
    /bin/curl -fsLSv http://server.ambient-test.svc.cluster.local

    החיבור ייכשל ותופיע הודעה דומה לזו:

    * Request completely sent off
* Empty reply from server
* shutting down connection #0
curl: (52) Empty reply from server

הגדרת מדיניות הרשאות ברמה 4

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

  1. מחילים את המדיניות הבאה כדי לאכוף את ההרשאה רק ללקוח לתקשר עם השרת:

    kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-client
  namespace: ambient-test
spec:
  action: ALLOW
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
  rules:
  - from:
      sources:
      - principals:
        - principalSelector: CLIENT_CERT_URI_SAN
          principal:
            type: Exact
            value: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client
EOF

    המדיניות הזו נאכפת על תנועת נתונים אל Pods של שרתים במרחב השמות ambient-test. היא מוודאת שהתנועה מותרת רק ממקורות עם זהות SPIFFE‏ spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client.

  2. כדי לוודא שאכיפת המדיניות מותרת, שולחים בקשת לדוגמה מחשבון השירות של הלקוח.

    kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

  3. כדי לוודא שאין אפשרות לאכוף את המדיניות, שולחים בקשה לדוגמה מחשבון השירות של השרת.

    kubectl exec -it deploy/server -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

    הפלט אמור להיראות כך:

    curl: (52) Empty reply from server
command terminated with exit code 52

  4. אפשר להשתמש ב-Logs Explorer כדי לראות את הרישום ביומן של אכיפת ההרשאה. במסוף Cloud de Confiance , נכנסים לדף Logs Explorer.

    כניסה לדף Logs Explorer