הגדרת אבטחת תעבורה

כדי לאבטח את תעבורת הנתונים בין שירותים ב-Cloud Service Mesh באמצעות ממשקי ה-API של Istio, אתם יכולים לאכוף Mutual TLS‏ (mTLS) מחמיר. בעומסי עבודה של Kubernetes, ‏mTLS אוטומטי מופעל כברירת מחדל: שרתי proxy של קובצי עזר חיצוניים בצד הלקוח שולחים באופן אוטומטי תעבורת נתונים של mTLS לקובצי עזר חיצוניים, אבל שירותי היעד עדיין מקבלים גם טקסט פשוט וגם בקשות מוצפנות.

כללי המדיניות של PeerAuthentication מאפשרים להגביל את השירותים כך שיקבלו רק mTLS. אפשר להחיל מדיניות על כל רשת השירות, על מרחב שמות ספציפי או על עומס עבודה מסוים. למידע על השדות שנתמכים בפלטפורמות השונות, קראו את המאמרים התכונות הנתמכות (מישור בקרה מנוהל), תמיכה ב-API ב-Cloud Service Mesh מנוהל והתכונות הנתמכות (מישור בקרה באשכול).

הפעלת Mutual TLS לכל מרחב שמות

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

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "NAMESPACE"
spec:
  mtls:
    mode: STRICT
EOF

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

peerauthentication.security.istio.io/AUTH_POLICY_NAME created

הפעלת פרוטוקול TLS הדדי (mTLS) לכל עומס עבודה

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

  1. מחילים מדיניות אימות על עומס עבודה ספציפי במרחב השמות:

    cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "NAMESPACE"
spec:
  selector:
    matchLabels:
      app: WORKLOAD
  mtls:
    mode: STRICT
EOF

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

    peerauthentication.security.istio.io/AUTH_POLICY_NAME created

  2. מגדירים כלל תואם ליעד:

    cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: "networking.istio.io/v1beta1"
kind: "DestinationRule"
metadata:
  name: "DEST_RULE_NAME"
spec:
  host: "WORKLOAD.NAMESPACE.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

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

    destinationrule.networking.istio.io/DEST_RULE_NAME created

אכיפת mTLS בכל הרשת

כדי למנוע מכל השירותים ברשת לקבל תנועה בטקסט פשוט, מגדירים מדיניות PeerAuthentication ברמת הרשת, עם מצב mTLS שמוגדר ל-STRICT (ברירת המחדל היא PERMISSIVE). למדיניות PeerAuthentication ברמת הרשת לא צריך להיות בורר, וצריך להחיל אותה במרחב השמות הבסיסי, istio-system. כשפורסים את המדיניות, מישור הבקרה מקצה באופן אוטומטי אישורי TLS כדי שעומסי העבודה יוכלו לאמת זה את זה.

כדי לאכוף mTLS בכל הרשת:

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

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

peerauthentication.security.istio.io/AUTH_POLICY_NAME created

השבתת mTLS

ב-Managed Cloud Service Mesh עם מישור הבקרה TRAFFIC_DIRECTOR אין תמיכה במצב DISABLE במשאבי PeerAuthentication (mtls.mode: DISABLE או portLevelMtls.mode: DISABLE).

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

  1. בצד השרת (PeerAuthentication): ודאו שעומס העבודה ביעד מקבל תנועה בטקסט פשוט באמצעות מצב PERMISSIVE. אם ברשת או במרחב השמות שלכם מוגדרת מדיניות ברירת המחדל של PERMISSIVE, אתם לא צריכים ליצור משאב PeerAuthentication. אם אכפתם mTLS של STRICT ברמת הרשת או מרחב השמות, צריך להחיל מדיניות של PeerAuthentication שספציפית לעומס העבודה או ליציאה, ולהגדיר אותה ל-PERMISSIVE.
  2. בצד הלקוח (DestinationRule): מגדירים משאב DestinationRule עם tls.mode: DISABLE כדי שקובצי עזר חיצוניים בצד הלקוח ישלחו תנועה בטקסט פשוט כשמתבצעת קריאה לשירות או ליציאה הזו.

הערה: בגלל ששרת ה-proxy בצד השרת משתמש במצב PERMISSIVE במקום במצב DISABLE, עומס העבודה ביעד עדיין מקבל תנועת mTLS מכל לקוח שלא נכלל ב-DestinationRule. כדי לוודא שכל לקוחות הרשת שולחים טקסט פשוט, יוצרים את DestinationRule במרחב השמות של שירות היעד (או istio-system) בלי להגביל את exportTo.

דוגמה: השבתת mTLS בשירות

  1. אם רשת ה-mesh או מרחב השמות שלכם אוכפים mTLS של STRICT, צריך לאפשר לעומס העבודה של היעד (או ליציאה ספציפית) לקבל תנועה בטקסט פשוט על ידי הגדרת המצב של PeerAuthentication ל-PERMISSIVE:

    cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "NAMESPACE"
spec:
  selector:
    matchLabels:
      app: WORKLOAD
  mtls:
    mode: PERMISSIVE
EOF

    כדי לאפשר טקסט פשוט רק ביציאה ספציפית של עומס עבודה (לדוגמה, כשמעבירים מ-portLevelMtls), מגדירים במקום זאת את portLevelMtls:

    spec:
  selector:
    matchLabels:
      app: WORKLOAD
  mtls:
    mode: STRICT
  portLevelMtls:
    WORKLOAD_PORT:
      mode: PERMISSIVE

  2. מגדירים DestinationRule כדי להורות לשרתי proxy של לקוחות לשלוח תנועת טקסט פשוט לשירות היעד:

    cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: "networking.istio.io/v1beta1"
kind: "DestinationRule"
metadata:
  name: "DEST_RULE_NAME"
  namespace: "NAMESPACE"
spec:
  host: "SERVICE_NAME.NAMESPACE.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: DISABLE
EOF

    כדי להשבית את mTLS רק ליציאת שירות ספציפית, משתמשים ב-portLevelSettings ב-DestinationRule:

    spec:
  host: "SERVICE_NAME.NAMESPACE.svc.cluster.local"
  trafficPolicy:
    portLevelSettings:
    - port:
        number: SERVICE_PORT
      tls:
        mode: DISABLE

חיפוש ומחיקה של כללי מדיניות של PeerAuthentication

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

kubectl get peerauthentication --all-namespaces

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

kubectl delete peerauthentication -n NAMESPACE AUTH_POLICY_NAME

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