מבוא למדיניות הרשת של Kubernetes לאנשי אבטחה

הערה. תרגום: לכותב המאמר, ראובן הריסון, ניסיון של למעלה מ-20 שנה בפיתוח תוכנה, וכיום הוא CTO ומייסד שותף של חברת Tufin, שיוצרת פתרונות לניהול מדיניות אבטחה. למרות שהוא רואה במדיניות הרשת של Kubernetes כלי חזק למדי לפילוח רשת באשכול, הוא גם מאמין שלא כל כך קל ליישם אותן בפועל. חומר זה (די נרחב) נועד לשפר את המודעות של מומחים לנושא זה ולעזור להם ליצור את התצורות הדרושות.

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

עבור אנשי אבטחה שמתלבטים בעבודה עם Kubernetes, ייתכן שהגילוי האמיתי הוא מדיניות ברירת המחדל של הפלטפורמה: אפשר הכל.

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

מדיניות רשת Kubernetes

מנגנון מדיניות הרשת של Kubernetes מאפשר לך לנהל את האינטראקציה של יישומים הפרוסים בפלטפורמה בשכבת הרשת (השלישית במודל OSI). מדיניות רשת חסרה חלק מהתכונות המתקדמות של חומות אש מודרניות, כגון אכיפה של OSI Layer 7 וזיהוי איומים, אך הן מספקות רמה בסיסית של אבטחת רשת המהווה נקודת התחלה טובה.

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

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

הגדרת מדיניות רשת

כמו משאבי Kubernetes אחרים, מדיניות הרשת מצוינת ב-YAML. בדוגמה למטה, האפליקציה balance גישה ל postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(הערה. תרגום: צילום מסך זה, כמו כל הדומים הבאים, נוצר לא באמצעות כלי Kubernetes מקוריים, אלא באמצעות הכלי Tufin Orca, שפותח על ידי החברה של מחבר המאמר המקורי ואשר מוזכר בסוף החומר.)

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

לאחר שתיאר את המדיניות ב-YAML, השתמש קובקטלכדי ליצור אותו באשכול:

kubectl create -f policy.yaml

מפרט מדיניות רשת

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

1. podSelector: מגדיר את התרמילים המושפעים ממדיניות זו (יעדים) - נדרשים;
2. policyTypes: מציין אילו סוגי מדיניות כלולים בזה: כניסה ו/או יציאה - אופציונלי, אך אני ממליץ לציין זאת במפורש בכל המקרים;
3. ingress: מגדיר מותר נכנס תנועה לתרמילים - אופציונלי;
4. egress: מגדיר מותר יוֹצֵא תנועה מתרמילים היא אופציונלית.

הדוגמה נלקחה מאתר Kubernetes (החלפתי role על app), מראה כיצד נעשה שימוש בכל ארבעת האלמנטים:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: db
  policyTypes:    # <<<
  - Ingress
  - Egress
  ingress:        # <<<
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:         # <<<
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

שימו לב שלא חייבים לכלול את כל ארבעת האלמנטים. זה רק חובה podSelector, ניתן להשתמש בפרמטרים אחרים לפי הצורך.

אם תשמיט policyTypes, המדיניות תתפרש כדלקמן:

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

כדי למנוע טעויות אני ממליץ תמיד הפוך את זה למפורש policyTypes.

על פי ההיגיון לעיל, אם הפרמטרים ingress ו / או egress נשמטה, המדיניות תמנע כל תעבורה (ראה "כלל הפשטה" להלן).

מדיניות ברירת המחדל היא אפשר

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

מרחבי שמות

מרחבי שמות הם מנגנון שיתוף הפעולה של Kubernetes. הם נועדו לבודד סביבות לוגיות זו מזו, בעוד שתקשורת בין חללים מותרת כברירת מחדל.

כמו רוב רכיבי Kubernetes, מדיניות הרשת נמצאת במרחב שמות ספציפי. בבלוק metadata אתה יכול לציין לאיזה שטח שייכת המדיניות:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

אם מרחב השמות לא צוין במפורש במטא נתונים, המערכת תשתמש במרחב השמות שצוין ב-kubectl (כברירת מחדל namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

אני ממליץ ציין במפורש מרחב שמות, אלא אם כן אתה כותב מדיניות שמתמקדת במרחבי שמות מרובים בו-זמנית.

עיקרי אלמנט podSelector במדיניות יבחר פודים ממרחב השמות שאליו שייכת המדיניות (נמנעת גישה לפודים ממרחב שמות אחר).

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

כללי מתן שמות למדיניות

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

אני אוהב במיוחד את אחת משיטות השמות. זה מורכב משילוב שם מרחב השמות עם תרמילי היעד. לדוגמה:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

תוויות

ניתן לצרף תוויות מותאמות אישית לאובייקטים של Kubernetes, כגון תרמילים ומרחבי שמות. תוויות (תוויות - תגיות) הן המקבילות לתגיות בענן. מדיניות הרשת של Kubernetes משתמשת בתוויות לבחירה תרמיליםעליהם הם חלים:

podSelector:
  matchLabels:
    role: db

… או מרחבי שמותאליהם הם חלים. דוגמה זו בוחרת את כל הפודים במרחבי השמות עם התוויות המתאימות:

namespaceSelector:
  matchLabels:
    project: myproject

זהירות אחת: בעת השימוש namespaceSelector ודא שמרחבי השמות שבחרת מכילים את התווית הנכונה. שים לב שמרחבי שמות מובנים כגון default и kube-system, כברירת מחדל אינם מכילים תוויות.

אתה יכול להוסיף תווית לרווח כך:

kubectl label namespace default namespace=default

במקביל, מרחב שמות בקטע metadata צריך להתייחס לשם המרחב בפועל, לא לתווית:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

מקור ויעד

מדיניות חומת האש מורכבת מכללים עם מקורות ויעדים. מדיניות הרשת של Kubernetes מוגדרת עבור יעד - קבוצה של תרמילים עליהם הם חלים - ולאחר מכן קובעים כללים לתעבורת כניסה ו/או יציאה. בדוגמה שלנו, היעד של המדיניות יהיה כל הפודים במרחב השמות default עם תווית עם מפתח app ומשמעות db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

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

זה שווה ערך לשני חוקי חומת אש: כניסה ← יעד; יעד ← יציאה.

יציאה ו-DNS (חשוב!)

על ידי הגבלת תנועה יוצאת, שימו לב במיוחד ל-DNS - Kubernetes משתמש בשירות זה כדי למפות שירותים לכתובות IP. לדוגמה, המדיניות הבאה לא תפעל מכיוון שלא אישרת את היישום balance גישה ל-DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

אתה יכול לתקן את זה על ידי פתיחת גישה לשירות ה-DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

אלמנט אחרון to הוא ריק, ולכן הוא בוחר בעקיפין כל הפודים בכל מרחבי השמות, מאפשר balance שלח שאילתות DNS לשירות Kubernetes המתאים (בדרך כלל פועל במרחב kube-system).

גישה זו עובדת, אולם היא מתירנית מדי וחסרת ביטחון, מכיוון שהוא מאפשר להפנות שאילתות DNS מחוץ לאשכול.

אתה יכול לשפר אותו בשלושה שלבים רצופים.

1. אפשר שאילתות DNS בלבד בתוך אשכול על ידי הוספה namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. אפשר שאילתות DNS בתוך מרחב השמות בלבד kube-system.

לשם כך עליך להוסיף תווית למרחב השמות kube-system: kubectl label namespace kube-system namespace=kube-system - ורשום זאת במדיניות באמצעות namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. אנשים פרנואידים יכולים ללכת רחוק יותר ולהגביל שאילתות DNS לשירות DNS ספציפי ב kube-system. הסעיף "סנן לפי מרחבי שמות ותרמילים" יגיד לך איך להשיג זאת.

אפשרות נוספת היא לפתור DNS ברמת מרחב השמות. במקרה זה, לא יהיה צורך לפתוח אותו עבור כל שירות:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

null podSelector בוחר את כל הפודים במרחב השמות.

התאמה ראשונה וסדר כלל

בחומות אש קונבנציונליות, הפעולה (Allow or Deny) על חבילה נקבעת לפי הכלל הראשון שהיא עומדת בה. ב-Kubernetes, סדר המדיניות אינו משנה.

כברירת מחדל, כאשר לא מוגדרת מדיניות, תקשורת בין פודים מותרת והם יכולים להחליף מידע באופן חופשי. ברגע שמתחילים לגבש מדיניות, כל פוד המושפע מאחד מהם לפחות הופך למבודד בהתאם לניתוק (OR לוגי) של כל הפוליסות שבחרו בו. תרמילים שאינם מושפעים ממדיניות כלשהי נשארים פתוחים.

אתה יכול לשנות התנהגות זו באמצעות כלל הפשטה.

כלל הפשטה ("הכחשה")

מדיניות חומת אש מונעת בדרך כלל כל תעבורה שאינה מותרת במפורש.

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

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

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

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

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

שים לב כל מדיניות נוספת המאפשרת תעבורה ל-pods במרחב השמות תקבל עדיפות על כלל זה (בדומה להוספת כלל היתר לפני כלל דחייה בתצורת חומת אש).

אפשר הכל (Any-Any-Any-Allow)

כדי ליצור מדיניות 'אפשר הכל', עליך להוסיף את מדיניות הדחיה שלמעלה ברכיב ריק ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

זה מאפשר גישה מ כל הפודים בכל מרחבי השמות (וכל ה-IP) לכל פוד במרחב השמות default. התנהגות זו מופעלת כברירת מחדל, כך שבדרך כלל אין צורך להגדיר אותה יותר. עם זאת, לפעמים ייתכן שיהיה עליך להשבית באופן זמני כמה הרשאות ספציפיות כדי לאבחן את הבעיה.

ניתן לצמצם את הכלל כדי לאפשר גישה רק ל סט ספציפי של תרמילים (app:balance) במרחב השמות default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

שילוב של פוליסות מרובות

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

1. בשדות from и to ניתן להגדיר שלושה סוגים של אלמנטים (שכולם משולבים באמצעות OR):

• namespaceSelector - בוחר את מרחב השמות כולו;
• podSelector - בוחר תרמילים;
• ipBlock — בוחר רשת משנה.

יתרה מכך, מספר האלמנטים (אפילו זהים) בתתי סעיפים from/to לא מוגבל. כולם ישולבו על ידי OR לוגי.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. בתוך סעיף הפוליסה ingress יכול להכיל אלמנטים רבים from (בשילוב של OR לוגי). באופן דומה, סעיף egress עשוי לכלול אלמנטים רבים to (משולב גם על ידי ניתוק):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. פוליסות שונות משולבות גם עם OR לוגי

אבל כאשר משלבים אותם, יש מגבלה אחת עליה הצביע כריס קוני: Kubernetes יכול לשלב רק מדיניות עם שונות policyTypes (Ingress או Egress). מדיניות המגדירה כניסה (או יציאה) תחליף זו את זו.

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

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

לאחר שחסמת את הגישה למרחב שמות (ראה "כלל ההסרה" למעלה), תוכל לבצע חריגים למדיניות הדחיה על ידי מתן אפשרות לחיבורים ממרחב שמות ספציפי באמצעות namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

כתוצאה מכך, כל הפודים במרחב השמות default תהיה גישה לתרמילים postgres במרחב השמות database. אבל מה אם אתה רוצה לפתוח גישה ל postgres רק תרמילים ספציפיים במרחב השמות default?

סנן לפי מרחבי שמות ותרמילים

Kubernetes גרסה 1.11 ומעלה מאפשרת לשלב אופרטורים namespaceSelector и podSelector באמצעות AND לוגי. זה נראה כך:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

מדוע זה מתפרש כ-AND במקום ה-OR הרגיל?

שים לב ש podSelector לא מתחיל במקף. ב-YAML זה אומר כך podSelector ועומד מולו namespaceSelector עיין לאותו רכיב רשימה. לכן, הם משולבים עם AND לוגי.

הוספת מקף לפני podSelector יביא להופעת רכיב רשימה חדש, שישולב עם הקודם namespaceSelector באמצעות OR לוגי.

לבחירת תרמילים עם תווית ספציפית בכל מרחבי השמות, הזן ריק namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

תוויות מרובות חוברות ל-I

כללים עבור חומת אש עם מספר אובייקטים (מארחים, רשתות, קבוצות) משולבים באמצעות OR לוגי. הכלל הבא יעבוד אם מקור החבילה תואם Host_1 או Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

להיפך, בקוברנטס התוויות השונות ב podSelector או namespaceSelector משולבים עם AND לוגי. לדוגמה, הכלל הבא יבחר תרמילים בעלי שתי התוויות, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

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

רשתות משנה וכתובות IP (IPBlocks)

חומות אש משתמשות ברשתות VLAN, כתובות IP ורשתות משנה כדי לפלח רשת.

ב-Kubernetes, כתובות IP מוקצות לתרמילים באופן אוטומטי ויכולות להשתנות לעתים קרובות, כך שתוויות משמשות לבחירת פודים ומרחבי שמות במדיניות רשת.

רשתות משנה (ipBlocks) משמשים בעת ניהול חיבורים חיצוניים (צפון-דרום) נכנסים (נכנסים) או יוצאים (יוצאים). לדוגמה, מדיניות זו נפתחת לכל הפודים ממרחב השמות default גישה לשירות DNS של Google:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

בורר הפוד הריק בדוגמה זו פירושו "בחר את כל הפודים במרחב השמות."

מדיניות זו מאפשרת גישה רק ל-8.8.8.8; גישה לכל IP אחר אסורה. אז בעצם, חסמת את הגישה לשירות ה-DNS הפנימי של Kubernetes. אם אתה עדיין רוצה לפתוח אותו, ציין זאת במפורש.

בדרך כלל ipBlocks и podSelectors סותרות זו את זו, מכיוון שלא נעשה שימוש בכתובות ה-IP הפנימיות של פודים ipBlocks. על ידי ציון תרמילים פנימיים של IP, למעשה תאפשר חיבורים אל/מפודים עם הכתובות הללו. בפועל, לא תדע באיזו כתובת IP להשתמש, וזו הסיבה שאסור להשתמש בהם לבחירת פודים.

כדוגמה נגדית, המדיניות הבאה כוללת את כל כתובות ה-IP ולכן מאפשרת גישה לכל שאר הפודים:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

אתה יכול לפתוח גישה רק לכתובות IP חיצוניות, למעט כתובות ה-IP הפנימיות של פודים. לדוגמה, אם רשת המשנה של הפוד שלך היא 10.16.0.0/14:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

יציאות ופרוטוקולים

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

שימו לב שהבורר ports חל על כל האלמנטים בבלוק to או from, המכיל. כדי לציין יציאות שונות עבור קבוצות שונות של אלמנטים, פיצול ingress או egress למספר תת-סעיפים עם to או from ובכל רישום היציאות שלך:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

פעולת יציאת ברירת מחדל:

• אם תשמיט את הגדרת היציאה לחלוטין (ports), זה אומר כל הפרוטוקולים וכל היציאות;
• אם תשמיט את הגדרת הפרוטוקול (protocol), זה אומר TCP;
• אם תשמיט את הגדרת היציאה (port), זה אומר כל היציאות.

שיטות עבודה מומלצות: אל תסתמך על ערכי ברירת מחדל, ציין מה אתה צריך במפורש.

שימו לב שאתם חייבים להשתמש ביציאות פוד, לא ביציאות שירות (עוד על כך בפסקה הבאה).

האם מוגדרות מדיניות עבור פודים או שירותים?

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

לדוגמה, אם שירות מאזין ליציאה 80, אך מפנה תעבורה ליציאה 8080 של הפוד שלו, עליך לציין בדיוק 8080 במדיניות הרשת.

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

גישה אדריכלית חדשה באמצעות Service Mesh (לדוגמה, ראה על Istio להלן - תרגום בערך) מאפשר לך להתמודד עם בעיה זו.

האם יש צורך לרשום גם Ingress וגם Egress?

התשובה הקצרה היא כן, כדי שפוד A יתקשר עם פוד B, יש לאפשר לו ליצור חיבור יוצא (בשביל זה צריך להגדיר מדיניות יציאה), ופוד B חייב להיות מסוגל לקבל חיבור נכנס ( לשם כך, בהתאם, אתה צריך מדיניות כניסה).

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

אם איזה תרמיל-מקור ייבחר על ידי אחד או יותר יְצִיאָה-פוליטיקאים, ההגבלות שיוטלו עליו ייקבעו לפי ניתוקם. במקרה זה, תצטרך לאפשר במפורש חיבור לתרמיל -לנמען. אם פוד לא נבחר על ידי מדיניות כלשהי, תעבורה יוצאת (יציאה) שלו מותרת כברירת מחדל.

באופן דומה, גורלו של התרמיל הואנִמעָן, שנבחר על ידי אחד או יותר חדירה-פוליטיקאים, ייקבעו לפי ניתוקם. במקרה זה, עליך לאפשר לו במפורש לקבל תעבורה מתרמיל המקור. אם פוד לא נבחר על ידי מדיניות כלשהי, כל תעבורת הכניסה עבורו מותרת כברירת מחדל.

ראה Stateful או Stateless להלן.

יומנים

מדיניות הרשת של Kubernetes אינה יכולה לרשום תעבורה. זה מקשה לקבוע אם מדיניות פועלת כמתוכנן ומסבך מאוד את ניתוח האבטחה.

בקרת תעבורה לשירותים חיצוניים

מדיניות הרשת של Kubernetes אינה מאפשרת לך לציין שם דומיין מלא (DNS) במקטעי יציאה. עובדה זו מובילה לאי נוחות משמעותית כאשר מנסים להגביל תנועה ליעדים חיצוניים שאין להם כתובת IP קבועה (כגון aws.com).

בדיקת מדיניות

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

kubernetes get networkpolicy <policy-name> -o yaml

זכור שמערכת האימות של Kubernetes אינה ניתנת לטעויות ועשויה לפספס סוגים מסוימים של שגיאות.

הוצאה לפועל

Kubernetes אינה מיישמת מדיניות רשת בעצמה, אלא היא בסך הכל שער API המעביר את נטל השליטה למערכת הבסיסית הנקראת ממשק רשת Container (CNI). הגדרת מדיניות באשכול Kubernetes מבלי להקצות את ה-CNI המתאים זהה ליצירת מדיניות בשרת ניהול חומת אש מבלי להתקין אותם על חומות אש. זה תלוי בך להבטיח שיש לך CNI הגון או, במקרה של פלטפורמות Kubernetes, מתארח בענן (תוכל לראות את רשימת הספקים כאן - משוער. עָבָר.), הפעל מדיניות רשת שתגדיר עבורך CNI.

שים לב ש-Kubernetes לא תזהיר אותך אם תגדיר מדיניות רשת ללא ה-CNI המתאים.

מדינה או חסרת מדינה?

כל ה-CNIs של Kubernetes שנתקלתי בהם הם סטטיסטיים (לדוגמה, Calico משתמש ב-Linux conntrack). זה מאפשר לפוד לקבל תגובות על חיבור ה-TCP שהוא יזם מבלי צורך להקים אותו מחדש. עם זאת, אני לא מודע לתקן Kubernetes שיבטיח אמינות.

ניהול מדיניות אבטחה מתקדם

הנה כמה דרכים לשפר את אכיפת מדיניות האבטחה ב-Kubernetes:

1. התבנית הארכיטקטונית של Service Mesh משתמשת במכולות צדדיות כדי לספק טלמטריה מפורטת ובקרת תעבורה ברמת השירות. כדוגמה אנחנו יכולים לקחת Istio.
2. חלק מספקי ה-CNI הרחיבו את הכלים שלהם כדי לחרוג ממדיניות הרשת של Kubernetes.
3. תופין אורקה מספק נראות ואוטומציה של מדיניות הרשת של Kubernetes.

חבילת Tufin Orca מנהלת את מדיניות הרשת של Kubernetes (והיא המקור לצילומי המסך למעלה).

מידע נוסף

• דוגמאות למדיניות רשת שהוכנה על ידי Ahmet Alp Balkan מ-GKE;
• תיעוד מהאתר הרשמי של Kubernetes;
• מדריך למודל הרשת של Kubernetes;
• סקריפט לבדיקת מדיניות רשת.

מסקנה

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

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

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• "חזרה לשירותי מיקרו עם Istio": חלק 1 (מבוא לתכונות העיקריות), חלק 2 (ניתוב, בקרת תנועה), חלק 3 (אבטחה);
• "מדריך מאויר לרשת ב-Kubernetes": חלקים 1 ו-2 (דגם רשת, רשתות שכבת על), חלק 3 (שירותים ועיבוד תעבורה);
• «Docker ו-Kubernetes בסביבות תובעניות אבטחה";
• «9 שיטות עבודה מומלצות לאבטחת Kubernetes";
• «11 דרכים (לא) להיפרץ ב- Kubernetes".

מקור: www.habr.com