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

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

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

במאמר תכונות נתמכות מפורטים השדות של PeerAuthentication CR שנתמכים בפלטפורמה.

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

כדי להפעיל 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 הדדי לכל עומס עבודה

כדי להגדיר מדיניות של 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/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "DEST_RULE_NAME"
spec:
  host: "WORKLOAD.NAMESPACE.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

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

    destinationrule.networking.istio.io/WORKLOAD 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

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

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

kubectl get peerauthentication --all-namespaces

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

kubectl delete peerauthentication -n NAMESPACE AUTH_POLICY_NAME

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