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

<0x0 Google Cloud מידע נוסף זמין במאמר סקירה כללית על Cloud Service Mesh.

גרסת טרום-השקה — Audit policy

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, שמפורטים בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

ההדרכה הזו תומכת רק בהטמעה של מישור הבקרה בתוך האשכול.

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

מכיוון שיומני הביקורת מוצגים ב-Logs Explorer של Cloud Logging במסוף Google Cloud , מדיניות הביקורת נתמכת רק בפלטפורמות הבאות:

• ‫GKE ב- Google Cloud
• ‫Google Distributed Cloud (תוכנה בלבד) ל-VMware
• ‫Google Distributed Cloud (תוכנה בלבד) לשרת פיזי

מדיניות ביקורת מרחיבה את AuthorizationPolicy על ידי הוספת הפעולה AUDIT. היא תקפה רק בהיקף המדיניות של היעד (שיכול להיות עומס עבודה, מרחב שמות או כל הרשת). המדיניות ORed ביחד, כלומר, בקשה נרשמת ביומן אם יש מדיניות שאומרת לעשות זאת. אם אף מדיניות ביקורת לא חלה על עומס עבודה מסוים, לא נוצר יומן ביקורת עבור עומס העבודה הזה.

לפניכם דוגמה למדיניות ביקורת לביקורת של כל גישת WRITE לנתיב /user/profile/* ב-myapi:

  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    namespace: ns1
    name: anyname
  spec:
    selector:
      matchLabels:
        app: myapi
    action: AUDIT
    rules:
    - to:
      - operation:
          methods: ["POST", "UPDATE", "DELETE"]
          paths: ["/user/profile/*"]

מגבלות

• אין יומן ביקורת ב-ingress-gateway.
• אי אפשר להגדיר את תוכן הביקורת.
• נכון לעכשיו, יומני הביקורת של Cloud Service Mesh הם בעלי אותה מהימנות כמו יומני גישה רגילים. לדוגמה, אם מפעילים מחדש Pod של עומס עבודה, יכול להיות שחלק מיומני הביקורת של עומס העבודה יאבדו אם הם לא נשמרו.

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

פועלים לפי השלבים במאמר התקנת כלים תלויי-הקשר ואימות האשכול כדי:

• התקנת הכלים הנדרשים
• הורדה asmcli
• הענקת הרשאות אדמין לאשכול
• אימות הפרויקט והאשכול

הכנת הגדרות השער

בעזרת Cloud Service Mesh, יש לכם אפשרות לפרוס ולנהל שערים כחלק מ-Service mesh. שער מתאר מאזן עומסים שפועל בקצה של רשת ה-mesh ומקבל חיבורי HTTP/TCP נכנסים או יוצאים. שערי מעבר הם שרתי proxy של Envoy שמאפשרים לכם שליטה פרטנית בתנועה שנכנסת לרשת ובזו שיוצאת ממנה.

asmcli לא מתקין את istio-ingressgateway. מומלץ לפרוס ולנהל את רמת הבקרה ואת השערים בנפרד. מידע נוסף זמין במאמר התקנה ושדרוג של שערים.

התאמה אישית של ההתקנה של Cloud Service Mesh

כדי להשתמש במדיניות ביקורת, צריך להתאים אישית את ההתקנה של Cloud Service Mesh:

התקנות

1. פועלים לפי השלבים במאמר בנושא התקנה של Cloud Service Mesh. כשמריצים את הפקודה asmcli install, צריך לכלול את האפשרות הבאה:

   --option audit-authorizationpolicy
   

   לדוגמה:

   ./asmcli install \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --ca mesh_ca \
     --output_dir DIR_PATH  \
     --enable_all \
     --option audit-authorizationpolicy
   

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

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

שדרוגים

1. פועלים לפי השלבים במאמר שדרוג Cloud Service Mesh. כשמריצים את הפקודה asmcli install, צריך לכלול את האפשרות הבאה:

   --option audit-authorizationpolicy
   

   לדוגמה:

   ./asmcli install \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --ca mesh_ca \
     --output_dir DIR_PATH  \
     --enable_all \
     --option audit-authorizationpolicy
   

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

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

שימוש ברישום ביומן ביקורת

בקטע הזה נעשה שימוש בדוגמה Bookinfo כדי להדגים איך משתמשים ביומן ביקורת.

1. פורסים את אפליקציית הדוגמה Bookinfo במרחב השמות שמוגדר כברירת מחדל.

2. מקבלים את כתובת ה-IP החיצונית של שער הכניסה, ושולחים בקשות לאפליקציה לדוגמה כדי ליצור עומס תנועה קל.

3. במסוף Google Cloud , פותחים את תפריט הניווט ובוחרים באפשרות Logging > Logs Explorer:
   

   כניסה לדף Logs Explorer

4. בוחרים פרויקט Google Cloud .

5. עדיין לא הטמעתם מדיניות ביקורת, ולכן לא יהיו יומני ביקורת. חשוב לזכור שיומן הביקורת שונה מיומן הגישה. כדי לראות את יומני הגישה של stackdriver, מזינים את השאילתה הבאה בשדה Query builder ולוחצים על Run query:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
   

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

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

בקטע הזה מפורטות כמה אפשרויות לביקורת על אפליקציית Bookinfo. אחרי שמפעילים את מדיניות הביקורת, אפשר לשלוח כמה בקשות ואז לבדוק את יומן הביקורת ב-Logs Explorer.

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

   ‫

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --zone=CLUSTER_LOCATION
   

   הערה: כדי להחליף אשכול אזורי, מחליפים את --region ב---zone.

2. מחילים את מדיניות הביקורת הבאה כדי לבדוק בקשות של GET לנתיב /productpage:

   kubectl apply -f - << EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "AuthorizationPolicy"
   metadata:
     name: "audit-productpage"
     namespace: default
   spec:
     action: AUDIT
     rules:
     - to:
       - operation:
           methods: ["GET"]
           paths: ["/productpage"]
   EOF
   

3. שולחים כמה בקשות ל-Bookinfo.

4. ב-Logs Explorer, מזינים את השאילתה הבאה בשדה Query builder ולוחצים על Run query:

   logName="projects/PROJECT_ID/logs/server-istio-audit-log"
   

   השאילתה מחזירה יומנים שדומים ליומנים הבאים:

   

5. מחילים את המדיניות הבאה כדי לבדוק בקשות לשירות bookinfo-ratings. כללי המדיניות של הביקורת מצטברים. אחרי שמחילים את המדיניות הבאה, רואים יומני ביקורת לבקשות גם ל-ProductPage וגם ל-Ratings.

   kubectl apply -f - << EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "AuthorizationPolicy"
   metadata:
     name: "audit-ratings"
     namespace: default
   spec:
     action: AUDIT
     rules:
     - from:
       - source:
           principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
       to:
       - operation:
           methods: ["GET"]
   EOF
   

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

6. שולחים 10 בקשות או יותר אל Bookinfo כדי לוודא שהגעתם לשירות הדירוגים, ואז בודקים את יומן הביקורת ב-Logs Explorer. יומן הביקורת נראה בערך כך:

   

7. החלת המדיניות הבאה על ביקורת בכל השירותים במרחב השמות שמוגדר כברירת מחדל.

   kubectl apply -f - << EOF
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     namespace: default
     name: "audit-all"
   spec:
     action: AUDIT
     rules:
       - {}
   EOF
   

8. שולחים עוד כמה בקשות ל-Bookinfo, ואז בודקים את יומן הביקורת ב-Logs Explorer. יומן הביקורת מתעד עכשיו את כל הבקשות:

   

9. אם רוצים להגביל את מדיניות הביקורת בחזרה ל-ProductPage ול-Ratings, אפשר למחוק את מדיניות audit-all:

   kubectl delete authorizationpolicy audit-all -n default
   

פתרון בעיות

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

1. מוודאים שיש תנועה לתקופת הזמן שצוינה בכלי Logs Explorer. אם אתם בודקים באמצעות Bookinfo, אתם יכולים לשלוח בקשות על ידי הפעלת הפקודה הבאה כמה פעמים:

   curl -s http://EXTERNAL_IP/productpage | grep Bookstore
   

2. בודקים אם יש AuthorizationPolicy בשער הכניסה שחוסם בקשות לשירות שנבדק.

3. כדי לוודא שהבקשות הגיעו לאפליקציה, בודקים את יומני הגישה של stackdriver באמצעות המסנן הבא בכלי Logs Explorer:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
   

   

4. כדי לוודא ש-Stackdriver מוגדר ויומן הביקורת מופעל, צריך להציג את ההגדרה של מצב istiod הנוכחי. בתיבת החיפוש config_dump מחפשים את enable_audit_log ואת השם של מדיניות הביקורת.

   istioctl dashboard envoy POD_NAME.NAMESPACE
   

   

5. כדי לוודא שהבקשות שלכם תואמות לכללים של מדיניות הביקורת, אתם יכולים לבדוק את יומני הניפוי באגים של בקרת גישה מבוססת-תפקידים (RBAC). מפעילים רישום ביומן לניפוי באגים של RBAC באמצעות הפקודה הבאה:

   kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
   

6. שולחים כמה בקשות, ואז בודקים את היומנים של ה-Pod באמצעות הפקודה kubectl logs:

   kubectl logs POD_NAME -n NAMESPACE -c istio-proxy
   

המאמרים הבאים

• מידע על אבטחה ב-Cloud Service Mesh