https://virgool.io/feed/@ShamimShahraeini fa 2026-06-18 20:10:04 https://files.virgool.io/upload/users/1772751/avatar/avatar.png?height=120&width=120 https://virgool.io/@ShamimShahraeini https://virgool.io/@ShamimShahraeini/my-understanding-of-k8s-networking-ep1-uzxb5r0fpzvq IntroductionNetworking is a central part of Kubernetes, but it can be challenging to understand exactly how it is expected to work and how it actually works. Overall, there are 4 distinct networking challenges to address:Highly-coupled container-to-container communications: This is solved by inter Pods network(CNI), specifically by localhost and the port number exposed communications. Pod-to-Pod communications: Deligated to Network Plugins; Every pod gets its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports It can be solved by directly addressing its IP addressPod-to-Service communications: This is covered by services. External-to-Service communications: This is covered by services. CNIs?It is a Cloud Native Computing Foundation project, consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted. Because of this focus, CNI has a wide range of support and the specification is simple to implement.In other word, CNI plugin is responsible for inserting a network interface into the container network namespace (e.g., one end of a virtual ethernet (veth) pair) and making any necessary changes on the host (e.g., attaching the other end of the veth into a bridge). It then assigns an IP address to the interface and sets up the routes consistent with the IP Address Management section by invoking the appropriate IP Address Management (IPAM) plugin.Flow of how it actually works:When the container runtime expects to perform network operations on a container, it (like the kubelet in the case of K8s) calls the CNI plugin with the desired command.The container runtime also provides related network configuration and container-specific data to the plugin.The CNI plugin performs the required operations and reports the result.note: CNI is called twice by K8s (kubelet) to set up loopback and eth0 interfaces for a pod.Detailed information:- Basic commands are: ADD, DEL, CHECK and VERSION- Plugins are executables- Spawned by the runtime when network operations are desired- Fed JSON configuration via stdin- Also fed container-specific data via stdin- Report structured result via stdoutServices?They are an abstract way to expose an application running on a set of Pods as a network service, and a policy by which to access them through each other (This will mostly be used in microservice-based architectures). The set of Pods targeted by a Service is usually determined by a selector.There are three main types of communications between Kubernetes services:Cluster IP - which is the usual way of accessing a service from inside the cluster.https://projectcalico.docs.tigera.io/about/about-kubernetes-servicesNode port - which is the most basic way of accessing a service from outside the cluster.https://projectcalico.docs.tigera.io/about/about-kubernetes-servicesLoadbalancer - which uses an external loadbalancer as a more sophisticated way to access a service from outside the cluster.https://projectcalico.docs.tigera.io/about/about-kubernetes-servicesVirtual IPs?Every node in a Kubernetes cluster runs a kube-proxy and It is responsible for implementing a form of virtual IP for Services of type other than ExternalName.There are three kinds of service proxy:User space proxy mode - kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service it opens a port (randomly chosen) on the local node. user-space proxy installs iptables rules which capture traffic to the Service's clusterIP (which is virtual) and port. The rules redirect that traffic to the proxy port which proxies the backend Pod and if failed and would automatically retry with a different backend Podhttps://kubernetes.io/docs/concepts/services-networking/service/iptables proxy mode - kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service, it installs iptables rules, which capture traffic to the Service's clusterIP and port, and redirect that traffic to one of the Service's backend sets. For each Endpoint object, it installs iptables rules which select a backend Pod but only backends that test out as healthy. The traffic is handled by Linux netfilter without the need to switch between userspace and the kernel space.https://kubernetes.io/docs/concepts/services-networking/service/IPVS proxy mode - kube-proxy watches Kubernetes Services and Endpoints, calls netlink interface to create IPVS rules accordingly and synchronizes IPVS rules with Kubernetes Services and Endpoints periodically. It uses a hash table as the underlying data structure and works in the kernel space. https://kubernetes.io/docs/concepts/services-networking/service/ Shamim Shahraeini Shamim Shahraeini Tue, 11 Oct 2022 15:48:33 +0330 https://virgool.io/@ShamimShahraeini/dns-zqs1xac8g1tj مقدمهمعرفی سامانه‌ی نام دامنه (DNS)زمانی‌که زیرساخت شبکه‌ای یک سازمان محدود به چند تجهیز و سرویس ساده، و همواره ثابت باشه، سیستم‌ها برای برقراری ارتباط با همدیگه و تبادل درخواست‌هاشون، می‌تونند به طور مستقیم از آدرس IP هم استفاده کنند. اما با رشد زیرساخت‌های هر شرکت و افزایش تعداد دستگاه‌ها، سامانه‌‌ها و اپلیکیشن‌ها که نیازمند اتصال با همدیگه و یا حتی ایجاد ارتباط با سامانه‌های غیر بومی اون شرکت و اینترنتی هستن، بهتر است که سیستم‌ها با نام‌‌های مرتبط که برای انسان ملموس‌تر از IP هست، همدیگه رو صدا بزنن. واسه همین نیاز به مکانیزمی برای مشخص کردن آدرس IP متناظر با هر نام وجود داره.اولین و ساده‌ترین راه‌حلی که برای این مشکل مطرح میشه، استفاده از فایلی با نام host هست. اینجوریه که، برای هر سیستمی که قصد ارتباط با سایر سیستم‌ها با نام رو داره، در این فایل آدرس IP متناظر با نام سیستم‌های مرتبط، درج میشه. اما با گسترده‌تر شدن سامانه‌ها و اضافه شدن دستگاه‌ها به ساختار سازمان‌ها، در عمل استفاده از فایل host و مدیریتش در هر سیستم، کاری دشوار و حتی ناممکنه. همین عامل باعث معرفی سرویسی با نام Domain Name Service (DNS) شد.بنابراین به طور مختصر و مفید، سامانه نام دامنه، سیستم سلسه‌مراتبی نام‌گذاری برای دستگاه‌ها، سامانه‌ها یا موارد دیگر، که به شبکه اینترنت یا شبکه محلی یه سازمان متصل باشن، هست :)ساختارش چجوریه؟چجوری کار میکنه؟انواع مختلف جستجوهای DNSوقتی آدرس IP یک وب سایت رو می‌خوایم، از یک سرور DNS سوال میکنیم، اما این همه‌ی ماجرا نیست. غیرممکنه که همه نام دامنه‌ها و سوابق موجود در جهان توو یک سرور DNS ذخیره بشن، در واقع سرورهای DNS از هم اطلاعات رو درخواست میکنن که این درخواست‌ها انواع مختلفی داره:1. Recursive queries 2. Iterative queries 3. Inverse queriesرکورد؟وقتی میخواهیم به گوگل دسترسی پیدا کنیم، یک سرور DNS در forward lookup zone خودش آدرس IP سایت رو جستجو میکنه و نتایج رو به ما بازمی گردونه. این یک رکورد Aه.انواع مهم رکوردهای DNS که باهاش سر و کار داریم؟A/AAA => A records are the most basic type of DNS record and are used to point a domain or subdomain to an IP address. A is an IPv4 record and AAA is an IPv6 address record.CNAME => Common Name records are used to point a domain or subdomain to another hostname.MX => the Mail Exchange record for mail delivery, required "priority" value as a part of their entry to indicate which mail server should be used.NS => the NS record specifies an authoritative name server for given host.SRV => the Server Locator record to designate a host and port for certain services, such as LDAP, for domain.SOA => the Start Of Authority record specifies core information about DNS zone, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone. Shamim Shahraeini Shamim Shahraeini Sun, 18 Sep 2022 12:11:51 +0430 https://virgool.io/@ShamimShahraeini/dnssec-ys8nmvbfv1ok مقدمهمعرفی سامانه‌ی نام دامنه (DNS)زمانی‌که زیرساخت شبکه‌ای یک سازمان محدود به چند تجهیز و سرویس ساده، و همواره ثابت باشه، سیستم‌ها برای برقراری ارتباط با همدیگه و تبادل درخواست‌هاشون، می‌تونند به طور مستقیم از آدرس IP هم استفاده کنند. اما با رشد زیرساخت‌های هر شرکت و افزایش تعداد دستگاه‌ها، سامانه‌‌ها و اپلیکیشن‌ها که نیازمند اتصال با همدیگه و یا حتی ایجاد ارتباط با سامانه‌های غیر بومی اون شرکت و اینترنتی هستن، بهتر است که سیستم‌ها با نام‌‌های مرتبط که برای انسان ملموس‌تر از IP هست، همدیگه رو صدا بزنن. واسه همین نیاز به مکانیزمی برای مشخص کردن آدرس IP متناظر با هر نام وجود داره.اولین و ساده‌ترین راه‌حلی که برای این مشکل مطرح میشه، استفاده از فایلی با نام host هست. اینجوریه که، برای هر سیستمی که قصد ارتباط با سایر سیستم‌ها با نام رو داره، در این فایل آدرس IP متناظر با نام سیستم‌های مرتبط، درج میشه. اما با گسترده‌تر شدن سامانه‌ها و اضافه شدن دستگاه‌ها به ساختار سازمان‌ها، در عمل استفاده از فایل host و مدیریتش در هر سیستم، کاری دشوار و حتی ناممکنه. همین عامل باعث معرفی سرویسی با نام Domain Name Service (DNS) شد.بنابراین به طور مختصر و مفید، سامانه نام دامنه، سیستم سلسه‌مراتبی نام‌گذاری برای دستگاه‌ها، سامانه‌ها یا موارد دیگر، که به شبکه اینترنت یا شبکه محلی یه سازمان متصل باشن، هست :)معرفی افزونه‌ی امن سامانه‌ی نام دامنه (DNSSEC)تعریفش؟سیستم نام دامنه (DNS) موقعی طراحی شده که اینترنت یه جای دوستانه و قابل اعتمادی بوده. پروتکل به خودی خودش محافظت کمی در برابر پاسخ‌های مخرب یا جعلی به کوئری‌ها، میکنه -یا حتی میتونیم بگیم محافظتی نمیکنه :)-. افزونه‌های امنیتی DNS (همون DNSSEC) در واقع، با اضافه کردن امضاهای دیجیتالی به داده‌های DNS، این نیاز به امن شدن رو تا حدودی، برطرف میکنن؛ بنابراین میشه هر پاسخ DNS رو از نظر یکپارچگی -یکی از اصلهای امنیته (یعنی پیام در حین انتقال تغییر نکرده)- تأیید کرد و همچنین از نظر صحت -اینم یه اصل دیگس (یعنی داده ها توسط منبع واقعی ایجاد و فرستاده شدن، نه از طریق هکری چیزی)-. در دنیای ایده آل وقتی DNSSEC به طور کامل مستقر بشه، هر پاسخ DNS قابل تأیید و اعتماده.ساختارش؟ولی دنیا ایده آل نیس:)) DNSSEC یک تونل کاملا امن رو ایجاد نمیکنه. داده‌های DNS رو رمزگذاری یا مخفی نمیکنه و حتی به طور مستقل از زیرساخت‌های کلید عمومی موجود (PKI) کار میکنه. به گواهینامه های SSL یا کلید مخفی مشترک احتیاج نداره. ولی با در نظر گرفتن backwards compatibility طراحی شده و میتونه بدون تأثیر بر dns "قدیمیِ" نا امن استفاده بشه.چجوری کار میکنه؟در سه مولفه اصلی زیرساخت DNS مستقر شده:سرور Recursive: افراد(Clients) از سرورهای بازگشتی(Recursive) برای جستجوی نام دامنه های خارجی مانند www.example.com استفاده میکنن. اپراتورهای سرورهای بازگشتی باید اعتبارسنجی DNSSEC رو فعال کنن. با فعال کردن validation، سرورهای بازگشتی یه سری تسک‌های اضافی روی هر پاسخ DNS که دریافت میکنن انجام میدن، تا از صحتش اطمینان حاصل بکنن.سرور Authoritative:اپراتورهای سرورهای بازگشتی(Recursive) و TLDها از سرورهای معتبر(Authoritative) برای ریزالو دامنه‌هایی که پابلیش میکنن، استفاده میکنن. اپراتورهای معتبری که داده‌های DNS رو بر روی dns سرورهاشون منتشر میکنن، باید داده‌هایی که انتشار میدن رو امضا کنن. این مستلزم ایجاد رکورد resourceهای اضافی، و انتشارشون در دامنه‌های والد در صورت لزومه. با فعال کردن DNSSEC، سرورهای Authoritative علاوه بر پاسخ‌های استانداردی که تا الان ارایه میدادن، به درخواست داده‌های DNS با اطلاعات اضافی مانند امضاها و کلیدهای دیجیتالی پاسخ میدن.اپلیکیشن: این مولفه در هر دستگاه سرویس‌گیرنده ای از وب سرور گرفته تا تلفن‌های هوشمند هست. شامل کتابخانه‌های resolver در سیستم‌عامل‌های مختلف و برنامه‌هایی مانند مرورگرهای وب میشه.چی به dns اضافه میکنه؟شش نوع رکورد جدید معرفی میکنه:RRSIG (digital signature)با فعال کردن DNSSEC ، تقریباً در هر جواب DNS (A ، PTR ، MX ، SOA ، DNSKEY و غیره) حداقل یک امضای RRSIG یا رکورد منبع وجود داره. این امضاها توسط سرورهای dns بازگشتی که به عنوان resolverهای معتبر شناخته میشن، برای تأیید پاسخ های دریافت شده استفاده میشه.DNSKEY (public key)برای صحت داده‌ها DNSSEC به رمزنگاری کلید عمومی متکیه. چندین کلید در DNSSEC وجود داره، برخی خصوصی، برخی عمومی. کلیدهای عمومی به عنوان بخشی از داده‌های zone در جهان منتشر میشن و در نوع رکورد DNSKEY ذخیره میشن. به طور کلی، دو دسته کلید در DNSSEC وجود داره، از کلید Zone Signing (ZSK) برای محافظت از تمام داده های zone و از Key Signing Key (KSK) برای محافظت از کلیدهای دیگر استفاده میشه.DS (parent-child)یکی از مولفه های مهم DNSSEC اینه که zone والد میتونه برای zone فرزند خود "ضمانت" کنه. رکورد DS اطلاعات قابل تأیید (تولید شده از یکی از کلیدهای عمومی یه فرزند)ه که zone والد در مورد فرزند خود به عنوان بخشی از زنجیره اعتماد منتشر میکنه.NSEC (proof of nonexistence)NSEC3 (proof of nonexistence)NSEC3PARAM (proof of nonexistence)رکورد منابع NSEC ، NSEC3 و NSEC3PARAM با یک مسئله بسیار جالب روبرو هستن: اثبات اینکه همچین چیزی واقعاً وجود نداره.نکته ریزه: رمزنگاری کلید عمومی با مفهوم یک جفت کلید کار میکنه، یکی به صورت عمومی در دسترس همه قرار میگیره و اون یکی به صورت خصوصی مخفی نگه داشته میشه. DNSSEC هم همینطوره، در حالی که کلید قفل رو خصوصی نگه می‌داریم، کلید عمومی را به بقیه میدیم.چجوری جستجوی DNS رو تغییر میده؟جستجوی DNS قدیمی (ناامن) ساده اس:مثلا فرض کنیم که یه dns سرور بازگشتی از کلاینت درخواست رو میگیره تا نام www.isc.org رو جستجو کنه. dns سرور بازگشتی سرور(های) authoritative مسئول رو ردیابی میکنه، درخواست رو به یکی از dns سرورهای authoritative میفرسته و منتظر میمونه تا dns سرور authoritative مربوطه پاسخ بده.توو جستجوی DNS امن:با فعال کردن اعتبار سنجی DNSSEC، یک dns سرور (شناخته شده یا یک validating resolver) رکوردهای اضافی رو در جستجوی خود درخواست خواهد کرد، به این امید که dns سرورهای authoritative که remoteان بیش از پاسخ به سوالش بهش پاسخ بدن. در صورت دریافت پاسخ های DNSSEC در واقع، validating resolver محاسبات رمزنگاری رو برای تأیید صحت (مبدا داده درست باشه) و یکپارچگی (داده ها در حین انتقال تغییر نکرده باشه) پاسخ ها انجام میده، و حتی به zone والد به عنوان بخشی از تأییدش درخواست میده. این فرایند get-key, validate, ask-parent, parent, and its parent, and its parent رو تکرار میکنه، تا زمانی که validating resolver به کلید مورد اعتماد برسه. در دنیای ایده آل که DNSSEC پیاده شده تووش، تمام validating resolver فقط باید به یک کلید اعتماد کنن: اونم کلید rootه.نکته ریزه: زنجیره اعتماد چیه؟ هیچ zone اصلی برای root وجود نداره. ولی خب توو امنیت، بالاخره باید به یه کسی اعتماد کرد و در دنیای کاملاً محافظت شده DNSSEC (بعداً در مورد وضعیت ناقص فعلی صحبت میکنیم)، هر validating resolver فقط باید به یک نهاد اعتماد کنه، یعنی dns سرور root. هر validating resolver از قبل کلید root رو در فایل خودش داره. بنابراین پس از دریافت پاسخ، جواب دریافت شده رو اعتبار سنجی میکنه و با کلیدی که در فایلش داره مقایسه میکنه و این دو باید با هم مطابقت داشته باشن. اگر همه resolverها این مراحل رو انجام بدن یعنی که ما میتونیم به پاسخ root اعتماد کنیم، بنابراین میتونیم به .org اعتماد کنیم و بنابراین میتونیم به isc.org اعتماد کنیم. این به عنوان "زنجیره اعتماد" در DNSSEC شناخته میشه.چرا DNSSEC مهمه؟برخی از دلایلی که ممکنه مجابمون کنه DNSSEC رو در نظر بگیریم:یه وب سایت خوب باشیم: با فعال کردن اعتبار سنجی DNSSEC بر روی سرورهای DNSمون، با بررسی پاسخ هایی که بهمون برمیگرده، از کاربران و سرورهای خودمون بیشتر محافظت میکنیم. با امضای zoneمون، این امکان رو برای افرادی که مرتبطن هم فراهم میکنیم تا داده های zone خودشون رو تأیید کنن. هرچی افراد بیشتری DNSSEC رو ساپورت کنن اینترنت به طور کلی برای همه امن تر میشه.امنیت پیشرفته (C.Y.A.): در صورت نقض امنیت مبتنی بر DNS، مانند cache poisoning یا domain hijacking، بعد از تمام خسارت های مالی و تجاری که به نام دامنه مون وارد شده، ممکنه زیر نظر هم گرفته بشیم به خاطر هر اقدام پیشگیرانه ای که میتونستیم اجرا کنیم و نکردیم:( . مثه این میمونه که وب سایتمون فقط از طریق HTTP در دسترس باشه اما نه از طریق HTTPS.ویژگی های جدید: DNSSEC نه تنها امنیت رو افزایش میده، بلکه علاوه بر اون سطح امنیتی جدید، مجموعه ای کاملا جدید از ویژگی ها هم اضافه میکنه. به خاطر اعتماد کامل به DNS، امکان انتشار گواهینامه های SSL در DNS یا کلیدهای PGP برای رمزگذاری کاملاً خودکار ایمیل از طریق پلت فرم SSH هم وجود داره.بررسی اجمالی EDNSپاسخ های DNS قدیمی معمولاً اندازه کوچکی دارن (کمتر از 512 بایت) و خیلی خوشگل توو پکت UDP کوچک قرار میگیرن. سازوکار Extension برای DNS (EDNS یا EDNS (0)) مکانیزمیه که امکان برای ارسال داده های DNS در بسته های بزرگتر از طریق UDP رو به ما میده. برای پشتیبانی از EDNS، سرور DNS و شبکه باید آماده بشن تا از اندازه پکت بزرگتر و چندین قطعه پشتیبانی کنن.این برای DNSSEC مهمه، زیرا بیت +do سیگنال DNSSEC-awareness رو در EDNS حمل میکنه، و پاسخ های DNSSEC بزرگتر از پاسخ های نرمال DNS در حالت معمولیه. اگر سرورهای DNS و محیط شبکه نتونن از بسته های بزرگ UDP پشتیبانی کنن، این امر باعث انتقال مجدد آن از طریق TCP میشه یا پاسخ های بزرگتر UDP کنار گذاشته میشن. کاربران احتمالاً DNS کندی رو تجربه کنن و یا به طور کلی قادر به resolve کردن بعضی نام های خاص نیستن. Shamim Shahraeini Shamim Shahraeini Sun, 04 Sep 2022 13:09:38 +0430