‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

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

מדיניות ההרשאה של Cloud Service Mesh מספקת בקרת גישה ברמת הרשת, מרחב השמות ועומס העבודה לעומסי העבודה ברשת. בדף הזה מוסבר איך להגדיר תכונות מתקדמות של מדיניות הרשאות ב-Cloud Service Mesh, כולל מצב הרצה יבשה ורישום ביומן של פעולות שנדחו. התכונות שמתוארות בדף הזה מבוססות על ההנחה שאתם מכירים את המושגים הבסיסיים של מדיניות ההרשאות שמתוארים במאמר סקירה כללית של מדיניות ההרשאות.

מצב הרצה יבשה

מדיניות ההרשאות של Cloud Service Mesh תומכת במצב הרצה יבשה, שמאפשר לבדוק מדיניות הרשאות עם תנועה אמיתית של נתונים בסביבת ייצור בלי לאכוף אותה. מצב ההרצה היבשה מאפשר לכם להבין טוב יותר את ההשפעה של מדיניות ההרשאות לפני שמפעילים אותה. כך אפשר להפחית את הסיכון לשיבוש תנועת הייצור בגלל מדיניות הרשאות שגויה.

משתמשים בהערה "istio.io/dry-run": "true" במדיניות ההרשאות כדי לשנות אותה למצב הרצת בדיקה.

דוגמה למצב פרימטר לבדיקות

בדוגמה הבאה, deny-path-headers, מוצגת מדיניות עם ההערה dry-run שהערך שלה הוא "true. מדיניות ההרשאות דוחה בקשות לנתיב headers ומאשרת את כל הבקשות האחרות.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

כשמחילים מדיניות הרשאות במצב הרצה יבשה, Cloud Service Mesh רושם ביומן את תוצאת האכיפה ב-Cloud Logging, אבל לא אוכף את המדיניות. הבקשה תמיד מאושרת, ואפשר לבדוק את Logs Explorer כדי להחליט אם מדיניות ההרשאות פועלת כמצופה.

פרטים על רישום ביומן של הרצה יבשה

אחרי שמחילים מדיניות הרשאות במצב הרצה יבשה, אפשר לראות את התוצאות של המדיניות בכלי Logs Explorer.

עוברים אל Logs Explorer. בכתובת האתר הבאה, מחליפים את PROJECT_ID במזהה הפרויקט:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
בשדה Query-builder, מזינים שאילתה כדי למצוא את מדיניות ההרשאות במצב הרצה יבשה. בשאילתה הבאה, מחליפים את NAMESPACE במרחב השמות שלכם:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
```
לוחצים על Run query.
משנים את טווח הזמן לפי הצורך.

בצילום המסך הבא אפשר לראות את התוויות של הרצת הניסיון ביומן התנועה בכלי Logs Explorer אחרי החלת המדיניות לדוגמה deny-path-headers:

תמונה

מצב הרצת הבדיקה תומך במדיניות הרשאות ALLOW ו-DENY, בנוסף לתוצאות של הרצת בדיקה ב-Istio. ‫Cloud Service Mesh מאחסן את תוצאות ההרצה היבשה ב-Cloud Logging בתוויות הבאות:

‫dry_run_result: התוצאה של ההרצה היבשה היא AuthzAllowed או AuthzDenied.
‫dry_run_policy_name: מרחב השמות והשם של מדיניות ההרשאה התואמת שקובעת את ההחלטה לגבי הרצת הבדיקה.
‫dry_run_policy_rule: האינדקס של כלל מדיניות ההרשאות התואם שקובע את ההחלטה לגבי הרצת הבדיקה.

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

מדיניות הרשאות שהוחלה במצב הרצת בדיקה	תוצאת ההתאמה	תוצאה של הרצה יבשה	Cloud Logging
רק מדיניות `DENY`	לא תואם	מותר	dry_run_result: "AuthzAllowed"
רק מדיניות `DENY`	מותאמת	בוצעה דחייה	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
רק מדיניות `ALLOW`	לא תואם	בוצעה דחייה	dry_run_result: "AuthzDenied"
רק מדיניות `ALLOW`	מותאמת	מותר	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
המדיניות של `ALLOW` ושל `DENY`	אף אחת מהן לא תואמת	בוצעה דחייה	dry_run_result: "AuthzDenied"
	רק מדיניות `DENY` תואמת	בוצעה דחייה	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
	רק מדיניות `ALLOW` תואמת	מותר	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
	התאמה לשתי מדיניות	בוצעה דחייה	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:

אם אתם בטוחים בתוצאה של ההרצה היבשה, אתם יכולים להשבית את מצב ההרצה היבשה באחת מהדרכים הבאות:

להסיר לגמרי את הערת ההרצה היבשה, או
משנים את הערך של הערת ההרצה היבשה ל-false.

אחרי שמחילים את המדיניות כשהאפשרות 'הרצה יבשה' מושבתת, Cloud Service Mesh אוכף את המדיניות.

רישום ביומן של בקשות שנדחו

מדיניות ההרשאות דוחה בקשה אם היא לא מאושרת על ידי המדיניות. בפרוטוקולי HTTP (כולל gRPC), הבקשה נדחית עם קוד סטטוס 403. בפרוטוקולים שאינם HTTP, החיבור מסתיים באופן ישיר. יומן התנועה של Cloud Logging כולל מידע נוסף שיכול לעזור להבין למה התנועה נדחית. לדוגמה, ביומן מצוין מספר הבקשות שנדחו על ידי מדיניות ההרשאות, וזה יכול לעזור לכם לקבוע איזה כלל מדיניות גרם לדחייה, לעומת דחיות מהאפליקציה בעורף השרת.

בדוגמה הבאה, הערך של ההערה dry-run מוגדר ל-"false. כשמחילים את מדיניות ההרשאות DENY, היא נאכפת על ידי Cloud Service Mesh.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "false"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

אחרי שמחיליםDENY מדיניות הרשאות, אפשר לראות את התוצאות של המדיניות בכלי Logs Explorer.

עוברים אל Logs Explorer. בכתובת האתר הבאה, מחליפים את PROJECT_ID במזהה הפרויקט:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
בשדה Query-builder (בונה השאילתות), מזינים שאילתה כדי למצוא את מדיניות ההרשאות DENY. בשאילתה הבאה, מחליפים את NAMESPACE במרחב השמות שלכם:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
```
לוחצים על Run query.
משנים את טווח הזמן לפי הצורך.

בצילום המסך הבא מוצגת רשומה ביומן בכלי Logs Explorer אחרי שהמדיניות מהדוגמה deny-path-headers הוחלה כדי לאכוף את המדיניות. אפשר לראות שהמדיניות בנושא הרשאות היא הסיבה לשגיאה 403 לפי התוויות:

תמונה

יומן התנועה בכלי Logs Explorer כולל את התוויות הבאות לסירוב הרשאה:

‫response_details: הערך הוא AuthzDenied אם הדחייה נגרמת בגלל מדיניות הרשאות.
‫policy_name: מכיל את מרחב השמות ואת השם של מדיניות ההרשאה DENY שגרמה לדחייה. הערך הוא בפורמט <Namespace>.<Name>, לדוגמה, foo.deny-path-headers מייצג את מדיניות ההרשאות deny-path-headers במרחב השמות foo.
‫policy_rule: מכיל את האינדקס של הכלל במדיניות ההרשאות שגרם לדחייה. לדוגמה, 0 מציין את הכלל הראשון במדיניות.

מה השלב הבא?

כדי לראות את רשימת כל מדיניות ההרשאות ב-Service mesh:

kubectl get authorizationpolicy --all-namespaces

אם יש מדיניות הרשאה בתוקף, אפשר למחוק אותה באמצעות הפקודה kubectl delete:

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

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