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

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

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

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

ברמה הבסיסית, כאשר Calico מחבר פוד לרשת (ראה תרשים למטה), הוא מחבר אותו למארח באמצעות ממשק Ethernet וירטואלי (veth). התעבורה שנשלחת על ידי הפוד מגיעה למארח מהממשק הווירטואלי הזה ומעובדת באותו אופן כאילו הגיעה מממשק רשת פיזי. כברירת מחדל, Calico שמה לממשקים אלה caliXXX. מכיוון שהתעבורה מגיעה דרך הממשק הווירטואלי, היא עוברת דרך iptables כאילו התרמיל נמצא במרחק קפיצה אחת. לכן, כאשר תנועה מגיעה אל/מפוד, היא מועברת מנקודת מבטו של המארח.

בצומת Kubernetes המריץ Calico, אתה יכול למפות ממשק וירטואלי (veth) לעומס עבודה באופן הבא. בדוגמה למטה, אתה יכול לראות ש-veth#10 (calic1cbf1ca0f8) מחובר ל-cnx-manager-* במרחב השמות של calico-monitoring.

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m                            ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...

בהתחשב בעובדה ש-Calico יוצרת ממשק ותיק עבור כל עומס עבודה, כיצד היא אוכפת מדיניות? לשם כך, Calico יוצר ווים בשרשראות שונות של נתיב עיבוד המנות באמצעות iptables.

התרשים שלהלן מציג את השרשראות המעורבות בעיבוד מנות ב-iptables (או בתת-מערכת netfilter). כאשר מנה מגיעה דרך ממשק רשת, היא עוברת תחילה דרך שרשרת PREROUTING. לאחר מכן מתקבלת החלטת ניתוב, ובהתבסס על כך, החבילה עוברת דרך INPUT (מופנה לתהליכים מארח) או FORWARD (מופנים לפוד או לצומת אחר ברשת). מהתהליך המקומי, החבילה עוברת דרך שרשרת ה-OUTPUT ולאחר מכן POSTROUTING לפני שנשלחת לכבל.

שימו לב שהפוד הוא גם ישות חיצונית (מחוברת ל-Veth) מבחינת עיבוד iptables. בואו נסכם:

• תנועה מועברת (נט, מנותבת או אל/מפוד) עוברת ברשתות PREROUTING - FORWARD - POSTROUTING.
• התנועה לתהליך המארח המקומי עוברת דרך שרשרת PREROUTING - INPUT.
• התנועה מתהליך המארח המקומי עוברת דרך שרשרת OUTPUT - POSTROUTING.

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

1. מדיניות נקודת קצה (תרמיל) של עומס עבודה
2. מדיניות נקודת קצה מארח
3. אפשרות ApplyOnForward
4. מדיניות PreDNAT
5. מדיניות ללא מעקב

הבה נתחיל בבחינת אופן החלת מדיניות על נקודות קצה של עומס עבודה (Pods Kubernetes או OpenStack VMs), ולאחר מכן נסתכל על אפשרויות המדיניות עבור נקודות קצה מארח.

נקודות קצה של עומס עבודה

מדיניות נקודת קצה של עומס עבודה (1)

זוהי אפשרות להגן על תרמילי ה-kubernetes שלך. Calico תומכת בעבודה עם Kubernetes NetworkPolicy, אך היא מספקת גם מדיניות נוספת - Calico NetworkPolicy ו-GlobalNetworkPolicy. Calico יוצר שרשרת לכל פוד (עומס עבודה) ומחבר את שרשרות ה-INPUT וה-OUTPUT עבור עומס העבודה לטבלת הסינון של שרשרת FORWARD.

מארח נקודות קצה

מדיניות נקודת קצה מארח (2)

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

מדיניות ApplyOnForward (3)

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

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

מדיניות PreDNAT (4)

ב-Kubernetes, ניתן לחשוף יציאות של ישות שירות חיצונית באמצעות אפשרות NodePorts או, לחלופין (בעת שימוש ב-Calico), על ידי פרסום שלהן באמצעות אפשרויות Cluster IPs או External IPs. Kube-proxy מאזן תעבורה נכנסת הקשורה לשירות לתרמילים של השירות המקביל באמצעות DNAT. בהתחשב בכך, כיצד אוכפים מדיניות עבור תעבורה המגיעה דרך NodePorts? כדי להבטיח שהמדיניות הזו מיושמה לפני שהתעבורה מעובדת על ידי DNAT (שהוא מיפוי בין host:port לשירות המתאים), Calico מספקת פרמטר עבור GlobalNetworkPolicy הנקרא "preDNAT: true".

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

בעת יצירת מדיניות עם Pre-DNAT, חשוב להקפיד על התעבורה שאתה רוצה לעבד ולאפשר לדחות את הרוב. תעבורה המסומנת כ'אפשר' במדיניות הקדם-DNAT לא תיבדק עוד על ידי מדיניות נקודת המארח, בעוד שתעבורה שנכשלת במדיניות הקדם-DNAT תמשיך דרך הרשתות הנותרות.
Calico קבעה חובה להפעיל את האופציה applyOnForward בעת שימוש ב-preDNAT, מכיוון שבהגדרה יעד התעבורה טרם נבחר. ניתן להפנות את התנועה לתהליך המארח, או להעביר אותה לפוד או לצומת אחר.

מדיניות ללא מעקב (5)

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

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

כאשר אתה מגדיר את האפשרות "doNotTrack: true" ב-Calico globalNetworkPolicy, היא הופכת למדיניות **לא מעקב** והיא מיושמת מוקדם מאוד בצינור עיבוד המנות של לינוקס. בהסתכלות על הדיאגרמה שלמעלה, מדיניות ללא מעקב מוחלת בשרשרת PREROUTING ו-OUTPUT בטבלה הגולמית לפני תחילת מעקב החיבור (conntrack). כאשר מנה מותרת על ידי המדיניות הבלתי מעקבת, היא מסומנת כדי להשבית את מעקב החיבורים עבור אותה מנה. זה אומר:

• המדיניות ללא מעקב מוחלת על בסיס לכל מנה. אין מושג של חיבור (או זרימה). לחוסר קשרים יש כמה השלכות חשובות:
• אם אתה רוצה לאפשר גם תעבורת בקשה וגם תעבורת תגובה, אתה צריך כלל גם עבור נכנסות וגם יוצאות (מכיוון ש-Calico משתמשת בדרך כלל ב-conntrack כדי לסמן את תעבורת התגובה כמותרת).
• המדיניות ללא מעקב לא פועלת עבור עומסי עבודה של Kubernetes (פודים), מכיוון שבמקרה זה אין דרך לעקוב אחר החיבור היוצא מהפוד.
• NAT אינו פועל כהלכה עם מנות ללא מעקב (מאחר שהקרנל מאחסן את מיפוי ה-NAT ב-conntrack).
• כאשר עוברים את הכלל "אפשר הכל" במדיניות הבלתי במעקב, כל החבילות יסומנו כבלתי מעקב. זה כמעט תמיד לא מה שאתה רוצה, אז חשוב להיות מאוד סלקטיבי לגבי החבילות המותרות על ידי מדיניות לא במעקב (ולאפשר לרוב התעבורה לעבור דרך מדיניות רגילה במעקב).
• מדיניות ללא מעקב מוחלת ממש בתחילת צינור עיבוד המנות. חשוב מאוד להבין זאת בעת יצירת מדיניות Calico. אתה יכול לקבל מדיניות פוד עם order:1 ופוליסה ללא מעקב עם order:1000. זה לא ישנה. המדיניות ללא מעקב תיושם לפני המדיניות עבור הפוד. פוליסות ללא מעקב מכבדות צו ביצוע רק בינן לבין עצמן.

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

תוצאות של

בדקנו את אפשרויות המדיניות השונות (Host endpoint, ApplyOnForward, preDNAT ו-Untracked) ב-Calico וכיצד הן מיושמות לאורך נתיב עיבוד המנות. הבנה כיצד הם פועלים עוזרת בפיתוח מדיניות יעילה ובטוחה. עם Calico אתה יכול להשתמש במדיניות רשת גלובלית החלה על תווית (קבוצה של צמתים ותרמילים) ולהחיל מדיניות עם פרמטרים שונים. זה מאפשר למקצועני אבטחה ועיצוב רשת להגן בנוחות על "הכל" (סוגי נקודות קצה) בבת אחת באמצעות שפת מדיניות אחת עם מדיניות Calico.

תודות: אני רוצה להודות שון קרמפטון и אלכסה פוליטה על סקירתם ומידע יקר ערך.

מקור: www.habr.com