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

אשכול Kubernetes סטנדרטי הוא רשת שטוחה שבה כל pod יכול להגיע לכל pod אחר, מה שהופך שירותים פנימיים לפגיעים להתקפות. אנו מגדירים Network Policies לבידוד רשת, מיישמים אסטרטגיית deny כברירת מחדל ומאפשרים רק תעבורה הכרחית. הצוות שלנו מטפל בכל המחזור, מבדיקה ועד יישום ותמיכה, ומבטיח הגנה אמינה על התשתית שלך.

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

תארו לעצמכם: Redis ללא סיסמה, Postgres ללא TLS, וכל פוד באשכול יכול להגיע אליהם. לאחר פריצה ליישום אינטרנט, תוקף סורק את הרשת הפנימית ומוצא פורט 6379 פתוח. ללא Kubernetes Network Policies, זה הסוף. אשכול סטנדרטי הוא רשת שטוחה: כל פוד יכול לראות כל פוד אחר לפי כתובת IP. אבל אנו מגדירים מדיניות בידוד כך שתעבורת הרשת זורמת רק במסלולים מאושרים. הניסיון של הצוות שלנו: 5+ שנים ב-DevOps ו-40+ פרויקטים של הטמעת K8s בסביבת production. אנו מחזיקים בהסמכות CKA ו-CKAD, מה שמבטיח הטמעה ברמת מומחה. אנו מפחיתים את שטח התקיפה בממוצע ב-80%. חיסכון ממוצע לאחר ההטמעה: $2.7k–3.9k בשנה. לקוחות בדרך כלל מחזירים את ההשקעה תוך 3 חודשים.

למה default deny הוא הגישה הבטוחה היחידה?

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

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

לאחר היישום, האשכול הופך ל"חירש" — אין חיבורים נכנסים או יוצאים מלבד DNS. יש לאפשר DNS בנפרד (מדיניות עם Egress על פורטים 53 UDP/TCP ב-namespace של kube-system), אחרת פודים לא יוכלו לפתור שמות שירותים. ב-95% מהפרויקטים, מדיניות זו היא הבסיס לאבטחה. הטמעת Kubernetes Network Policies עם default deny מבטיחה בידוד רשת ומפחיתה את שטח התקיפה ב-80%.

אישור תעבורה בין פודים: דוגמת api-service

תרחיש טיפוסי: שירות apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: production spec: podSelector: {} policyTypes: - Ingress - Egress מקבל תעבורה רק מ-Ingress Controller ומדבר עם api ו-postgres. אנו יוצרים שתי מדיניות — נכנסת ויוצאת.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-service-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-service
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
          podSelector:
            matchLabels:
              app.kubernetes.io/name: ingress-nginx
      ports:
        - port: 8080
          protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-service-egress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-service
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
        ports:
          - port: 5432
    - to:
        - podSelector:
            matchLabels:
              app: redis
        ports:
          - port: 6379
דוגמה מלאה למדיניות עבור מיקרוסרוויס

עבור אשכול production עם 5 מיקרוסרוויסים, יש צורך בכ-10 מדיניויות. כל אחת כוללת חוקי Ingress ו-Egress. להלן תבנית עבור שירות טיפוסי עם מסד נתונים וקאש:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: service-a
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: service-a
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - port: 3000
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - port: 5432
    - to:
        - podSelector:
            matchLabels:
              app: redis
      ports:
        - port: 6379
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - port: 53
          protocol: UDP
        - port: 53
          protocol: TCP

חשוב: בגרסאות מודרניות של Kubernetes, redis ו-apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-service-ingress namespace: production spec: podSelector: matchLabels: app: api-service policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress-nginx podSelector: matchLabels: app.kubernetes.io/name: ingress-nginx ports: - port: 8080 protocol: TCP באותו בלוק apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-service-egress namespace: production spec: podSelector: matchLabels: app: api-service policyTypes: - Egress egress: - to: - podSelector: matchLabels: app: postgres ports: - port: 5432 - to: - podSelector: matchLabels: app: redis ports: - port: 6379 מטופלים כ-AND. בגרסאות ישנות יותר — כ-OR. בדקו את גרסת האשכול שלכם, למשל apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: service-a namespace: production spec: podSelector: matchLabels: app: service-a policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress-nginx ports: - port: 3000 egress: - to: - podSelector: matchLabels: app: postgres ports: - port: 5432 - to: - podSelector: matchLabels: app: redis ports: - port: 6379 - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - port: 53 protocol: UDP - port: 53 protocol: TCP .

תקשורת בין namespaces: allow-prometheus-scrape

לדוגמה, namespace של ניטור צריך לגרד מטריקות מפודים ב-namespaceSelector. אנו יוצרים מדיניות allow ב-namespace של podSelector:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus-scrape
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
          podSelector:
            matchLabels:
              app.kubernetes.io/name: prometheus
      ports:
        - port: 9090
          protocol: TCP

בעיית ה-healthcheck והפתרון שלה

kubelet מבצע בדיקות בריאות מכתובת ה-IP של הצומת (node IP) אל הפוד. אם מדיניויות חוסמות תעבורה נכנסת מכל מקור, kubelet לא יכול לבצע בדיקות. פתרון: אפשרו תעבורה מ-CIDR של צמתי האשכול:

 ingress: - from: - ipBlock: cidr: 10.0.0.0/16 # CIDR нод кластера ports: - port: 8080 

זה מונע 95% מבעיות ה-healthcheck לאחר הטמעת המדיניות.

איך לנפות באגים ב-Network Policies?

הקושי טמון בהיעדר לוגים של חסימה ב-Kubernetes עצמו. השתמשו בכלים ייעודיים:

  • Calico: from מציג חוקים מפוענחים; kubectl version --short אוסף נתוני מצב dataplane.
  • Cilium: production מציג חבילות שנפלו; production מספק סטטיסטיקות דרך Hubble UI. Cilium הוא אחד מתוספי ה-CNI בעלי הביצועים הגבוהים ביותר עם eBPF.

ללא כלים: הריצו פוד עם התמונה apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-prometheus-scrape namespace: production spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: monitoring podSelector: matchLabels: app.kubernetes.io/name: prometheus ports: - port: 9090 protocol: TCP ובדקו באמצעות ingress: - from: - ipBlock: cidr: 10.0.0.0/16 # CIDR нод кластера ports: - port: 8080 .

השוואת תוספי CNI עבור Network Policies

תוסף תמיכה ביצועים יכולת ניטור
Flannel לא (ללא תוסף נוסף) גבוהים נמוכה
Calico מלאה בינוני-גבוה בינונית (Felix)
Cilium מלאה גבוהים (eBPF) גבוהה (Hubble)
Weave Net מלאה בינוניים בינונית

Cilium מהיר פי 2-3 מ-Calico בסינון L7 בזכות eBPF. עבור רוב תרחישי ה-production, Calico מספיק, אבל אם יש צורך בניטור עמוק וביצועים גבוהים, בחרו ב-Cilium. Flannel ללא תוספים לא תומך במדיניויות, לכן אל תשקלו אותו לבידוד.

הגדרת Network Policy שלב אחר שלב

  1. ביקורת על הטופולוגיה הנוכחית של הרשת ומודל האבטחה — זיהוי namespaces ושירותים.
  2. תכנון מדיניויות על בסיס זרימות: Ingress מ-Ingress controller, Egress למסדי נתונים.
  3. פיתוח קבצי manifest המכסים את כל הזרימות הקריטיות (אל תשכחו DNS!).
  4. בדיקה בסביבת staging — בדקו healthchecks, DNS ופונקציונליות היישום.
  5. תיעוד כל מדיניות ותוכנית הבידוד עבור צוות התפעול.

בעיות וטעויות נפוצות עם Network Policies

בעיה סיבה פתרון
Healthcheck נכשל חסימת תעבורה מצמתים הוספת ipBlock עבור CIDR של צמתים
DNS לא נפתר אין חוק Egress עבור DNS אישור פורטים 53 UDP/TCP ל-kube-system
תעבורת פוד-לפוד נכשלת podSelector שגוי בדיקת תוויות פודים וחוקים
שכפול StatefulSet נשבר חסימת תעבורה בין עותקים אישור Egress מפודים עם אותו selector

לרוב (ב-95% מהמקרים), healthcheck חסום — תמיד הוסיפו ipBlock עבור צמתים. כמו כן, אל תשכחו Egress ל-DNS ושכפול בין עותקי StatefulSet. השתמשו ב-calicoctl get policy -n production כדי לבדוק.

מה כלול בעבודה

  • ביקורת על הטופולוגיה הנוכחית של הרשת ומודל האיומים.
  • תכנון מדיניויות בידוד עבור המחסנית שלכם (Calico/Cilium).
  • כתיבה ויישום של קבצי manifest (default deny + חוקי allow).
  • בדיקת כל הזרימות הקריטיות (healthcheck, DNS, ניטור).
  • תיעוד תוכנית הבידוד ו-runbook עבור צוות התפעול.
  • הכשרת מהנדסים בניהול מדיניויות (סדנה של שעתיים).
  • תמיכה לאחר ההטמעה למשך שבועיים.
  • גישה למאגר פרטי עם תבניות מדיניות.

התוצרים כוללים: קבצי NetworkPolicy סופיים, תיעוד מקיף, מפגש הכשרה ותמיכה לאחר ההטמעה. אנו מבטיחים השקה חלקה ללא זמן השבתה ומספקים אחריות של 100% שביעות רצון.

עלות פרויקט סטנדרטית להגדרת Network Policies — מ-$700–1.5k בהתאם למורכבות ולמספר השירותים.

לוחות זמנים

  • אשכול פשוט (3-5 שירותים ב-namespace אחד) — 1-2 ימים.
  • טופולוגיה מורכבת עם תקשורת בין namespaces — עד 3 ימים.
  • ביקורת מלאה והטמעה ב-production (כולל תיעוד) — מ-4 ימים.

צרו קשר עם המהנדסים שלנו לביקורת על האשכול שלכם — נחשב לוחות זמנים והיקף עבודה עבור הפרויקט שלכם. הזמינו הטמעת Network Policy במפתח פתוח: הבטיחו אבטחה ללא זמן השבתה.

מקור: תיעוד Kubernetes