یکی از مباحثی که همیشه تو زمینه Container Security جای خالی آن حس می‌شده، بحث Container Image Signing بوده است. این مبحث که بتوانیم آرتیفکتهایی چون ایمیج هامون رو Sign کنیم و در طول کار باهاشون، آنهارو Verify بکنیم، جزو مباحثی است که به شدت در حوزه هایی چون CI و ... کاربردی است. قابل ذکر است که پروژه Moby در حال توسعه چنین مکانیزمی می‌باشد، پروژه‌ای تحت عنوان Notary که خب مطمئن نیستم که هنوز بصورت Stable منتشر شده باشد!!
اما پروژه مد نظر ما پروژه ایست با نام Cosign زیر مجموعه شرکت Sigstore که بصورت تخصصی روی مبحث Software Signing و Transparency Service فعالیت دارند. ارزش یکبار نگاه کردن را دارد شک نکنید.🤘🤘
Link:

◾️https://raesene.github.io/blog/2021/03/21/Trying-out-cosign/

#security #opensource #devops #devsecops
〰️〰️〰️〰️〰️〰️
© @DevOpsEx

Enterprise Security Architecture | Vahid Nameni
خب چند وقته پیش یکی از افراد فعال در حوزه DevSecOps به نام آقای وحید نامنی یک وبینار به حالت پرسش و پاسخ در یوتیوب برگذار کردند که گفتم قرار بدهم تا دوستانی که علاقه دارند بتونن از حرفای ایشون استفاده کنند. تاپیک هایی که سمت فیلد Container Security ها ایشون مطرح می‌کنند بسیار مفید هست و اواسط Talk راجب اینکه چه چیز هایی باید در این مسیر یاد بگیرید و بلد باشید هم اشاراتی می‌کنن و یک نقشه راه معرفی می‌کنن. این Talk رو می‌تونید از لینک زیر مشاهده کنید.
ویدیو اصلی:
◾️https://www.youtube.com/watch?v=QmByS5JxxAY&t=3421s
برگذار کننده اصلی اینگونه Talk ها:
📲@livesecuritytalks
#security #opensource #devops #devsecops
〰️〰️〰️〰️〰️〰️
© @DevOpsEx

A Comparison Of Linux Container Images❗️
چند وقته پیش به نوشته جالبی از آقای Scott McCarty برخورد کردم گفتم بزارم شاید دوستان هم استفاده کردند. موضوع مورد بحث این هست که ایشون یک مقایسه بسیار جالب از تمام Container Image های Base انجام داده‌اند و از جهاتی چون موارد زیر آنهارو مقایسه کرده‌اند:
Architecture
Security
Binary Hardening
Performance
نکته جالبی هم راجب بحث ایمیج های DistroLess ارائه دادند که خوندنش خالی از لطف نبوده و دید نسبتا خوب و کاملی در انتخاب یک Base ایمیج متناسب با کارتون به شما می‌دهد.
ضمنا ایشون Content های به شدت پرمحتوایی در زمینه Container Internals و Container Standards ها دارن که می‌تونید در چنل یوتیوبشون اونهارو هم مطالعه کنید و استفاده کنید.
Link:
◾️https://crunchtools.com/comparison-linux-container-images/
Youtube Channel:
◾️https://www.youtube.com/channel/UCkWQhDzOxooYHp5LrTqnkdg
#container #docker #opensource #devops
〰️〰️〰️〰️〰️〰️
© @DevOpsEx

همیشه برام جالب بود که دلیل اصلی اینکه پلتفرم هایی مثل کوبرنتیز و یا داکر سرویس هایی رو تحت عنوان docker-proxy و kube-proxy نوشتن و هدف نهایی پشت این سرویس ها چی بوده و از چه مشکلاتی جلوگیری می کنن؟
کار مهمی که امروزه این سرویسها انجام میدن این هست که بقولی ما بتونیم حتی از طریق Local Network به اون پاد یا کانتینر مد نظرمون برسیم ( مشخصا این سرویس ها وظایف دیگه‌ای رو هم بر عهده دارند! ) چیزی که به شکل دیفالت در لینوکس ممکن نیست چرا که کرنل با پکت هایی که از شبکه داخلی آمده باشن 127.0.0.1/8 به شکلی خاصی رفتار می‌کنه چیزی که به ظاهر از RFC 1122 مقرر شده اینگونه باشه. به زبانی ساده تر، یک نود در شبکه هیچوقت پکتی که آدرس Destination اون 127.0.0.1 رو نمی‌تونه Transmit بکنه و به اصطلاح اون رو Drop میکنه.
ولی خب چیزی که همیشه مد نظرم بود ما بجای اینکه سرویسهایی بنویسیم مثل همون Proxy ها می‌تونیم به راحتی با ست کردن یک متغیر sysctl به نام route_localnet و یکمی بازی با IPTables مشکل رو حل کنیم یا دور بزنیم و به کانتینر مد نظرمون از طریق Localhost برسیم.
و خب بعد از حدود یک هفته تحقیق فهمیدم که در سال 2020 یک CVE-2020-8558 تحت همین سناریو بیرون آمد که اگر داکر یا کوبر با این متغیر کار بکنن چه مشکلی پیش میاد.
A flaw was found in Kubernetes that allows attackers on adjacent networks to reach services exposed on localhost ports, previously thought to be unreachable. This flaw allows an attacker to gain privileges or access confidential information for any services listening on localhost ports that are not protected by authentication.
و چقدر اون موقع به شکل راحتی سرویسهایی که به 127.0.0.1 به اصطلاح Bind شدن بدون هیچگونه Authentication و یا Encryption ای می‌تونن Expose بشن به خودی خود! که خب همین عامل باعث شد که داکر و یا کوبر سرویس هایی رو برای مدیریت بهتر این مشکلات بنویسن چرا که لینوکس به شکل دیفالت حتی Rule های IPTables رو برای پکت های Local Network در نظر نمی‌گیره !!

CVE-2020-8558:
◾️Link 1 Link 2
For More Info:
◾️Link 3

#container #docker #opensource #devops #devsecops
〰️〰️〰️〰️〰️〰️
© @DevOpsEx

Proxies in Kubernetes
◾️https://kubernetes.io/docs/concepts/cluster-administration/proxies/
Cracking Kubernetes Node Proxy (aka kube-proxy)

◾️https://arthurchiao.art/blog/cracking-k8s-node-proxy/

Connection Tracking (conntrack)
◾️https://arthurchiao.art/blog/conntrack-design-and-implementation/
A Deep Dive into Iptables and Netfilter Architecture
◾️https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture
Awesome BPF Resources
◾️https://arthurchiao.art/blog/awesome-bpf/
#container #kubernetes #opensource #devops #devsecops #networking
〰️〰️〰️〰️〰️〰️
© @DevOpsEx

خب بعد از چند وقت بریم سراغ ادامه تاپیک جذاب همیشگی یعنی Container Networking ولی اینبار یکمی دقیق‌تر راجب طرز پیاده‌سازیش تو Kubernetes و نگاهی به بخشی از بقولی Under The Hood مکانیزم‌های استفاده‌شده برای تحقق این موضوع، چیزهایی مثل طرز پیاده‌سازی سرویس Kube-Proxy تو دو مد iptables و IPVS و تفاوت‌هاشون به شکل دقیق و همینطور روش‌هایی که CNI هایی مثل Calico برای Advertise کردن CIDR پاد استفاده می‌کنن یعنی دو تکنولوژی BGP و BIRD و درنهایت پیاده‌سازی OverLay Network به کمک مفاهیمی چون VXLAN و IPinIP.
◽️این پست ادامه بحث این پسته.
◽️عمده ریسورس‌های معرفی‌شده در لینک‌های زیر توسط آقای Dustin Specker نوشته شده است یکی از بهترین‌های این حوزه!
⚡️Links⚡️
Container Networking Series:

...
iptables: How Kubernetes Services Direct Traffic to Pods
IPVS: How Kubernetes Services Direct Traffic to Pods
Kubernetes Networking from Scratch: Using BGP and BIRD to Advertise Pod Routes
...

◾️https://dustinspecker.com/series/container-networking/
Deep Dive Kube-Proxy With iptables Mode:
◾️https://serenafeng.github.io/2020/03/26/kube-proxy-in-iptables-mode/
Container Networking From Scratch - Kristen Jacobs:
◾️https://www.youtube.com/watch?v=6v_BDHIgOY8
#container #kubernetes #opensource #devops #devsecops #networking
〰️〰️〰️〰️〰️〰️
© @DevOpsEx