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

אבטחת רשתות וכללי מדיניות הרשאה

טייס אוטומטי רגילה

בדף הזה מוסבר איך ליצור מדיניות הרשאות ב-Ambient Networking.

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

כדי לבצע את השלבים שבמסמך הזה, אתם צריכים לעמוד בתנאים הבאים:

אשכול GKE פעיל עם רשתות סביבתיות של Cloud Service Mesh.
מרחב שמות שרשום ל-Ambient Networking (לדוגמה, ambient-test) עם עומסי עבודה לדוגמה של לקוח ושרת שנפרסו.
הפעלת TLS הדדי (mTLS) בין עומסי העבודה של הלקוח והשרת באמצעות GCPServerTLSPolicy (עם mtlsMode: Strict) ו-GCPClientTLSPolicy. כללים שמבוססים על זהות GCPAuthzPolicy שמתאימים ל-CLIENT_CERT_URI_SAN דורשים mTLS פעיל כדי לחלץ את זהות ה-SPIFFE של הלקוח.

הוראות מפורטות להגדרת הסביבה זמינות במאמר הכנת Ambient Networking ב-GKE.

מדיניות דחייה כברירת מחדל

כברירת מחדל, ה-API של מדיניות ההרשאות הסביבתית של GKE מאפשר את כל התנועה, אלא אם היא מוגבלת על ידי מדיניות, בהתאם להתנהגות הרגילה של Kubernetes NetworkPolicy.

הפעולה DENY_BY_DEFAULT מאפשרת לשנות את התנהגות ברירת המחדל הזו. כשמחילים את המדיניות הזו על מרחב שמות, היא חוסמת את כל התנועה לעומסי העבודה באותו מרחב שמות, אלא אם היא מותרת במפורש על ידי מדיניות ALLOW.

בדף הזה מוסבר איך להגדיר את DENY_BY_DEFAULT ב-Cloud Service Mesh ולהשתמש בו כדי להגדיר את עומסי העבודה שלכם כך שיהיו מאובטחים כברירת מחדל.

מגבלות

לפני שמחילים מדיניות DENY_BY_DEFAULT, חשוב לשים לב למגבלות הבאות:

אפשר ליצור רק מדיניות DENY_BY_DEFAULT אחת לכל מרחב שמות.
במדיניות עם הפעולה DENY_BY_DEFAULT לא יכולים להיות כללים מוגדרים.
כדי להגדיר את matchLabels: {} כקו בסיס לכל ה-Pods במרחב השמות, משתמשים בפעולה הזו. אי אפשר להשתמש ב-DENY_BY_DEFAULT להגבלות בכל Pod.

הגדרת מדיניות הרשאה שדוחה כברירת מחדל

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

יוצרים ומחילים GCPAuthzPolicy עם הפעולה שמוגדרת ל-DENY_BY_DEFAULT במרחב השמות.
```
cat <<EOF > deny-by-default-policy.yaml && kubectl apply -f deny-by-default-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: deny-by-default-authz
  namespace: ambient-test
spec:
  action: DENY_BY_DEFAULT
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels: {}
EOF
```
הפלט אמור להיראות כך:
```
 gcpauthzpolicy.networking.gke.io/deny-by-default-authz created
```
כברירת מחדל, המדיניות הזו חוסמת את כל התנועה הנכנסת (מזרח-מערב וכניסה) לעומסי עבודה במרחב השמות ambient-test. היא לא מגבילה את תעבורת הנתונים היוצאת שמקורה בעומסי עבודה במרחב השמות.
כדי לאפשר תנועה באופן סלקטיבי, יוצרים ומחילים מדיניות ALLOW:

חשוב: כדי שכללים של GCPAuthzPolicy יתאימו ל-CLIENT_CERT_URI_SAN, צריך להגדיר מראש mTLS (GCPServerTLSPolicy עם מצב Strict ו-GCPClientTLSPolicy). אם mTLS לא פעיל, ה-proxy לא יכול לחלץ את זהות ה-SPIFFE של הלקוח, ולכן כללים מבוססי-SPIFFE‏ ALLOW אף פעם לא יתאימו וכל התנועה תיחסם על ידי DENY_BY_DEFAULT.
```
cat <<EOF > allow-policy.yaml && kubectl apply -f allow-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-client-to-server
  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.svc.id.goog/ns/ambient-test/sa/client
EOF
```
מחליפים את PROJECT_ID במזהה הפרויקט.

הפצת המדיניות יכולה להימשך עד שלוש דקות אחרי שהבקר מקבל אותה. מחכים שלוש דקות לפני שממשיכים.
בודקים את הקישוריות מהלקוח לשרת. היא אמורה להצליח כי היא תואמת למדיניות ALLOW.
```
kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
בדיקת הקישוריות מהשרת לעצמו (או לכל עומס עבודה אחר ללא מדיניות הרשאה מפורשת). הפעולה אמורה להיכשל בגלל המדיניות DENY_BY_DEFAULT.
```
kubectl exec -it deploy/server -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
הפלט אמור להיראות כך:
```
curl: (52) Empty reply from server.
```

רישום ביומן

כשבקשה נדחית על ידי מדיניות הרשאה, פרוקסי הצומת כותב רשומה ביומן הגישה אל Cloud Logging בשם היומן gke-ambient-node-proxy-accesslog. הרשומה מכילה את השדה הבא ב-payload של ה-JSON:

jsonPayload.error_details: - rbac_access_denied_matched_policy[none]

אתם יכולים להשתמש ב-Logs Explorer ב Google Cloud מסוף כדי לראות את הרשומות ביומן הגישה של חיבורים שנדחו:

resource.type="k8s_container"
logName="projects/PROJECT_ID/logs/gke-ambient-node-proxy-accesslog"
jsonPayload.error_details=~"rbac_access_denied"

מידע נוסף זמין במאמר אימות של תנועת נתונים ומתן הרשאה לתנועה.

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

כדי לבדוק ולשלוט בתנועה יוצאת מעומסי עבודה של Ambient Networking לנקודות קצה חיצוניות או לאינטרנט, אתם יכולים לנתב את התנועה היוצאת דרך Secure Web Proxy‏ (SWP).

הוראות להגדרת משאבי GCPBackend ו-GCPEgressPolicy מופיעות במאמר ניתוב תעבורת נתונים יוצאת (egress) של סביבה היקפית דרך Secure Web Proxy.