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

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

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

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

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

הוראות מפורטות להגדרת הסביבה זמינות במאמר הכנת רשתות סביבתיות ב-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.

הגדרה של מדיניות הרשאות מסוג deny-by-default

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

1. יוצרים ומחילים 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. היא לא מגבילה תעבורה יוצאת שמקורה בעומסי עבודה במרחב השמות.

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

   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.s3ns.svc.id.goog/ns/ambient-test/sa/client
   EOF
   

   מחליפים את PROJECT_ID במזהה הפרויקט.

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

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

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

4. בדיקת הקישוריות מהשרת לעצמו (או לכל עומס עבודה אחר ללא מדיניות הרשאה מפורשת). הפעולה אמורה להיכשל בגלל המדיניות 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.
   

רישום ביומן

כשבקשה נדחית על ידי מדיניות הרשאות, יומני הגישה של GKE Ambient Proxy מכילים את השדות הבאים ב-payload של ה-JSON:

• ‫jsonPayload.error_details: מוגדר לערך - rbac_access_denied_matched_policy[none]

אתם יכולים להשתמש ב-Logs Explorer ב Cloud de Confiance Console כדי לראות את הרשומות ביומן הגישה של חיבורים שנדחו. אימות התנועה וההרשאה

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

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

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