درک گزینه های خط مشی شبکه با Calico

پلاگین شبکه Calico طیف گسترده ای از سیاست های شبکه را با یک نحو یکپارچه برای محافظت از میزبان های سخت افزاری، ماشین های مجازی و پادها فراهم می کند. این خط‌مشی‌ها می‌توانند در یک فضای نام اعمال شوند یا خط‌مشی‌های شبکه جهانی باشند که برای آن اعمال می‌شوند نقطه پایان میزبان (برای محافظت از برنامه هایی که مستقیماً روی هاست اجرا می شوند - میزبان می تواند سرور یا ماشین مجازی باشد) یا نقطه پایان بار کاری (برای محافظت از برنامه های در حال اجرا در کانتینرها یا ماشین های مجازی میزبانی شده). خط‌مشی‌های Calico به شما این امکان را می‌دهند که با استفاده از گزینه‌هایی مانند preDNAT، unracked و applicationOnForward، اقدامات امنیتی را در نقاط مختلف مسیر بسته اعمال کنید. درک نحوه عملکرد این گزینه ها می تواند به بهبود امنیت و عملکرد کلی سیستم شما کمک کند. این مقاله ماهیت این گزینه‌های خط‌مشی Calico (preDNAT، unracked و applicationOnForward) را توضیح می‌دهد که برای نقاط پایانی میزبان اعمال می‌شوند، با تأکید بر آنچه در مسیرهای پردازش بسته (زنجیره‌های iptabels) اتفاق می‌افتد.

این مقاله فرض می‌کند که شما درک اساسی از نحوه عملکرد خط‌مشی‌های شبکه Kubernetes و Calico دارید. اگر نه، توصیه می کنیم آن را امتحان کنید آموزش خط مشی اصلی شبکه и آموزش حفاظت از میزبان قبل از خواندن این مقاله از Calico استفاده کنید. همچنین از شما انتظار داریم که درک اولیه ای از کار داشته باشید از iptables در لینوکس

چلوار سیاست شبکه جهانی به شما امکان می دهد مجموعه ای از قوانین دسترسی را بر اساس برچسب ها (به گروه هاست ها و بارهای کاری/پاد) اعمال کنید. اگر از سیستم‌های ناهمگن با هم استفاده می‌کنید - ماشین‌های مجازی، یک سیستم مستقیماً روی سخت‌افزار، یا یک زیرساخت kubernetes، بسیار مفید است. علاوه بر این، می‌توانید از خوشه (گره‌ها) خود با استفاده از مجموعه‌ای از خط‌مشی‌های اعلامی محافظت کنید و سیاست‌های شبکه را برای ترافیک ورودی اعمال کنید (به عنوان مثال، از طریق سرویس NodePorts یا External IPs).

در یک سطح اساسی، زمانی که Calico یک pod را به شبکه متصل می کند (نمودار زیر را ببینید)، آن را با استفاده از یک رابط اترنت مجازی (veth) به میزبان متصل می کند. ترافیک ارسال شده توسط پاد از این رابط مجازی به میزبان می آید و به همان روشی پردازش می شود که گویی از یک رابط فیزیکی شبکه است. به طور پیش فرض، Calico نام این رابط ها را caliXXX می گذارد. از آنجایی که ترافیک از طریق رابط مجازی می‌آید، از طریق iptable‌ها به‌گونه‌ای می‌گذرد که گویی پاد یک هاپ دورتر است. بنابراین، هنگامی که ترافیک به/از یک پاد می آید، از دید میزبان هدایت می شود.

در یک گره 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 برای هر بار کاری یک رابط veth ایجاد می کند، چگونه سیاست ها را اجرا می کند؟ برای انجام این کار، Calico قلاب هایی را در زنجیره های مختلف مسیر پردازش بسته با استفاده از iptable ایجاد می کند.

نمودار زیر زنجیره های درگیر در پردازش بسته در iptables (یا زیرسیستم netfilter) را نشان می دهد. هنگامی که یک بسته از طریق یک رابط شبکه می رسد، ابتدا از طریق زنجیره PREROUTING عبور می کند. سپس یک تصمیم مسیریابی گرفته می شود و بر این اساس، بسته از طریق INPUT (به فرآیندهای میزبان هدایت می شود) یا FORWARD (به یک pod یا گره دیگری در شبکه هدایت می شود) می گذرد. از فرآیند محلی، بسته قبل از ارسال به کابل از طریق زنجیره OUTPUT و سپس POSTROUTING عبور می کند.

توجه داشته باشید که pod از نظر پردازش iptables نیز یک موجود خارجی (متصل به veth) است. بیایید خلاصه کنیم:

• ترافیک هدایت‌شده (nat، مسیریابی یا به/از یک غلاف) از زنجیره‌های PREROUTING - FORWARD - POSTROUTING عبور می‌کند.
• ترافیک به فرآیند میزبان محلی از زنجیره PREROUTING - INPUT عبور می کند.
• ترافیک از فرآیند میزبان محلی از طریق زنجیره OUTPUT - POSTROUTING انجام می شود.

Calico گزینه های سیاستی را ارائه می دهد که به شما امکان می دهد خط مشی ها را در همه زنجیره ها اعمال کنید. با در نظر گرفتن این موضوع، بیایید به گزینه های مختلف پیکربندی خط مشی موجود در Calico نگاه کنیم. اعداد موجود در لیست گزینه های زیر با اعداد موجود در نمودار بالا مطابقت دارند.

1. خط‌مشی نقطه پایانی بار کاری (pod).
2. خط‌مشی نقطه پایانی میزبان
3. گزینه ApplyOnForward
4. خط مشی PreDNAT
5. سیاست پیگیری نشده

بیایید با بررسی نحوه اعمال خط‌مشی‌ها برای نقاط پایانی بار کاری (Kubernetes pods یا OpenStack VM) شروع کنیم و سپس به گزینه‌های خط‌مشی برای نقاط پایانی میزبان نگاه کنیم.

نقاط پایانی بار کاری

خط مشی نقطه پایان بار کاری (1)

این گزینه ای برای محافظت از غلاف های kubernetes شما است. Calico از کار با Kubernetes NetworkPolicy پشتیبانی می کند، اما خط مشی های اضافی - Calico NetworkPolicy و GlobalNetworkPolicy را نیز ارائه می دهد. Calico یک زنجیره برای هر غلاف (بار کاری) ایجاد می کند و زنجیره های INPUT و OUTPUT را برای بار کاری به جدول فیلتر زنجیره FORWARD قلاب می کند.

نقاط پایانی میزبان

خط‌مشی نقطه پایان میزبان (2)

سیاست های Calico علاوه بر CNI (رابط شبکه کانتینری) توانایی محافظت از خود میزبان را نیز فراهم می کند. در Calico، می توانید با تعیین ترکیبی از رابط میزبان و در صورت لزوم، شماره پورت، یک نقطه پایانی میزبان ایجاد کنید. اجرای خط مشی برای این نهاد با استفاده از جدول فیلتر در زنجیره های INPUT و OUTPUT انجام می شود. همانطور که از نمودار می بینید، (2) آنها برای فرآیندهای محلی در گره/میزبان اعمال می شوند. یعنی اگر خط‌مشی ایجاد کنید که برای نقطه پایانی میزبان اعمال می‌شود، بر ترافیک رفتن به/از پادهای شما تأثیری نخواهد داشت. اما یک رابط / نحو واحد برای مسدود کردن ترافیک میزبان و پادهای شما با استفاده از سیاست های Calico ارائه می دهد. این امر فرآیند مدیریت سیاست ها را برای یک شبکه ناهمگن بسیار ساده می کند. پیکربندی خط‌مشی‌های نقطه پایانی میزبان برای افزایش امنیت خوشه یکی دیگر از موارد استفاده مهم است.

خط مشی ApplyOnForward (3)

گزینه ApplyOnForward در خط‌مشی شبکه جهانی Calico در دسترس است تا به همه ترافیکی که از نقطه پایانی میزبان می‌گذرد، سیاست‌ها اعمال شود، از جمله ترافیکی که توسط میزبان ارسال می‌شود. این شامل ترافیک ارسال شده به پاد محلی یا هر جای دیگری در شبکه است. Calico نیاز دارد که این تنظیم برای خط‌مشی‌هایی با استفاده از PreDNAT فعال و ردیابی نشده باشد، به بخش‌های زیر مراجعه کنید. علاوه بر این، ApplyOnForward می تواند برای نظارت بر ترافیک میزبان در مواردی که از روتر مجازی یا نرم افزار NAT استفاده می شود استفاده شود.

توجه داشته باشید که اگر نیاز به اعمال سیاست شبکه یکسان برای هر دو فرآیند میزبان و پاد دارید، نیازی به استفاده از گزینه ApplyOnForward ندارید. تنها کاری که باید انجام دهید این است که یک برچسب برای نقطه پایانی مورد نیاز و بار کاری (pod) ایجاد کنید. Calico به اندازه کافی هوشمند است تا خط‌مشی را بر اساس برچسب‌ها، بدون توجه به نوع نقطه پایانی (Hostendpoint یا حجم کاری) اعمال کند.

خط مشی PreDNAT (4)

در Kubernetes، پورت های موجودیت سرویس را می توان با استفاده از گزینه NodePorts یا به صورت اختیاری (هنگام استفاده از Calico)، با تبلیغات آنها با استفاده از گزینه های Cluster IP یا External IPs در معرض دید خارجی قرار داد. پراکسی Kube ترافیک ورودی متصل به یک سرویس به غلافهای سرویس مربوطه را با استفاده از DNAT متعادل می کند. با توجه به این موضوع، چگونه می‌توانید سیاست‌های ترافیکی را که از NodePortها وارد می‌شود، اعمال کنید؟ برای اطمینان از اینکه این خط‌مشی‌ها قبل از پردازش ترافیک توسط DNAT (که یک نگاشت بین میزبان:پورت و سرویس مربوطه است) اعمال می‌شوند، Calico یک پارامتر برای globalNetworkPolicy به نام "preDNAT: true" ارائه می‌کند.

هنگامی که pre-DNAT فعال است، این سیاست ها در نمودار (4) - در جدول mangle زنجیره PREROUTING - بلافاصله قبل از DNAT اجرا می شوند. ترتیب معمول خط‌مشی‌ها در اینجا رعایت نمی‌شود، زیرا اعمال این سیاست‌ها خیلی زودتر در مسیر پردازش ترافیک اتفاق می‌افتد. با این حال، خط مشی های preDNAT ترتیب کاربرد را در بین خود رعایت می کنند.

هنگام ایجاد خط‌مشی با Pre-DNAT، مهم است که مراقب ترافیکی باشید که می‌خواهید پردازش کنید و اجازه دهید اکثریت رد شوند. ترافیکی که در خط‌مشی pre-DNAT به‌عنوان «مجاز» علامت‌گذاری شده است، دیگر توسط خط‌مشی نقطه میزبان بررسی نمی‌شود، در حالی که ترافیکی که خط‌مشی قبل از DNAT را رعایت نمی‌کند، از طریق زنجیره‌های باقی‌مانده ادامه خواهد یافت.
Calico فعال کردن گزینه applyOnForward را هنگام استفاده از preDNAT اجباری کرده است، زیرا طبق تعریف هنوز مقصد ترافیک انتخاب نشده است. ترافیک می تواند به فرآیند میزبان هدایت شود، یا می توان آن را به یک پاد یا گره دیگر هدایت کرد.

خط مشی پیگیری نشده (5)

شبکه ها و برنامه ها می توانند تفاوت های زیادی در رفتار داشته باشند. در برخی موارد شدید، برنامه ها ممکن است اتصالات کوتاه مدت زیادی ایجاد کنند. این می تواند باعث شود که conntrack (یکی از اجزای اصلی پشته شبکه لینوکس) به اتمام برسد. به طور سنتی، برای اجرای این نوع برنامه ها در لینوکس، باید به صورت دستی conntrack را پیکربندی یا غیرفعال کنید، یا قوانین iptables را برای دور زدن conntrack بنویسید. اگر می‌خواهید اتصالات را در سریع‌ترین زمان ممکن پردازش کنید، سیاست ردیابی نشده در Calico گزینه ساده‌تر و کارآمدتر است. به عنوان مثال، اگر از massive استفاده می کنید حافظه پنهان یا به عنوان یک اقدام اضافی برای محافظت در برابر DDOS.

این را بخوان پست های وبلاگ (یا ترجمه ما) برای اطلاعات بیشتر، از جمله تست های عملکرد با استفاده از خط مشی ردیابی نشده.

هنگامی که گزینه "doNotTrack: true" را در Calico globalNetworkPolicy تنظیم می کنید، به یک خط مشی **ردیابی نشده** تبدیل می شود و خیلی زود در خط لوله پردازش بسته های لینوکس اعمال می شود. با نگاهی به نمودار بالا، سیاست های ردیابی نشده در زنجیره های PREROUTING و OUTPUT در جدول خام قبل از شروع ردیابی اتصال (conntrack) اعمال می شوند. هنگامی که یک بسته توسط خط مشی ردیابی نشده مجاز است، برای غیرفعال کردن ردیابی اتصال برای آن بسته علامت گذاری می شود. به این معنی:

• خط مشی ردیابی نشده بر اساس هر بسته اعمال می شود. هیچ مفهومی از اتصال (یا جریان) وجود ندارد. عدم اتصال چندین پیامد مهم دارد:
• اگر می خواهید ترافیک درخواست و پاسخ را مجاز کنید، به یک قانون برای هر دو ورودی و خروجی نیاز دارید (زیرا Calico معمولاً از conntrack برای علامت گذاری ترافیک پاسخ به عنوان مجاز استفاده می کند).
• خط مشی ردیابی نشده برای بارهای کاری Kubernetes (pods) کار نمی کند، زیرا در این حالت راهی برای ردیابی اتصال خروجی از پاد وجود ندارد.
• NAT با بسته های ردیابی نشده درست کار نمی کند (زیرا هسته نقشه NAT را در conntrack ذخیره می کند).
• هنگام عبور از قانون "Allow all" در خط مشی ردیابی نشده، همه بسته ها به عنوان ردیابی نشده علامت گذاری می شوند. این تقریباً همیشه آن چیزی نیست که شما می‌خواهید، بنابراین مهم است که در مورد بسته‌های مجاز توسط سیاست‌های ردیابی نشده بسیار گزینشی باشید (و اجازه دهید بیشتر ترافیک از طریق خط‌مشی‌های ردیابی معمولی عبور کند).
• سیاست های پیگیری نشده در همان ابتدای خط لوله پردازش بسته اعمال می شود. درک این موضوع هنگام ایجاد سیاست های Calico بسیار مهم است. می توانید یک خط مشی pod با order:1 و یک خط مشی پیگیری نشده با order:1000 داشته باشید. این مهم نخواهد بود. خط مشی Untracked قبل از خط مشی برای pod اعمال می شود. خط‌مشی‌های پیگیری نشده فقط در بین خود به دستور اجرا احترام می‌گذارند.

از آنجایی که یکی از اهداف سیاست doNotTrack اجرای این خط‌مشی خیلی زود در خط لوله پردازش بسته لینوکس است، Calico تعیین گزینه applyOnForward را هنگام استفاده از doNotTrack الزامی می‌کند. با مراجعه به نمودار پردازش بسته، توجه داشته باشید که خط مشی untracked(5) قبل از هر تصمیم مسیریابی اعمال می شود. ترافیک می تواند به فرآیند میزبان هدایت شود، یا می توان آن را به یک پاد یا گره دیگر هدایت کرد.

نمایش نتایج: از

ما به گزینه های مختلف خط مشی (Host endpoint، ApplyOnForward، preDNAT و Untracked) در Calico و نحوه اعمال آنها در مسیر پردازش بسته نگاه کردیم. درک نحوه کار آنها به توسعه سیاست های مؤثر و ایمن کمک می کند. با Calico می توانید از یک خط مشی شبکه جهانی استفاده کنید که برای یک برچسب (گروهی از گره ها و پادها) اعمال می شود و خط مشی هایی را با پارامترهای مختلف اعمال می کنید. این امر به متخصصان امنیت و طراحی شبکه اجازه می‌دهد تا با استفاده از یک زبان خط مشی واحد با خط‌مشی‌های Calico به راحتی از "همه چیز" (انواع نقطه پایانی) به طور همزمان محافظت کنند.

تصدیق: جا دارد تشکر کنم شان کرامپتون и الکسا پولیتا برای بررسی و اطلاعات ارزشمند آنها.

منبع: www.habr.com