چهار لایه امنیتی برای کوبرنتیز؛ از در ورودی تا هسته‌ی لینوکس

تصور کنید در یک خانه‌ی جدید، قبل از آوردن حتی یک تکه مبل، قفل‌ها، دوربین‌ها و دروازه‌ها را نصب می‌کنید. برای یک خوشه‌ی کوبرنتیز که می‌خواهد میزبان بارهای کاری واقعی باشد هم باید همین کار را کرد: امنیت باید قبل از استقرار اولین workload فعال باشد.

این همان فلسفه‌ی پشت یک پشته‌ی امنیتی چهارلایه برای یک خوشه‌ی ۲۹ نودی RKE2 است؛ خوشه‌ای که دیگر یک «پروژه‌ی دست‌ساز آزمایشگاهی» نیست و به یک محیط تولیدی با رویکرد اعتماد صفر (Zero-Trust) تبدیل شده. در چنین محیطی که میزبان ارائه‌دهندگان هویت مثل Keycloak، موتورهای رمزنگاری مانند HashiCorp Vault، خطوط لوله‌ی یادگیری ماشین Kubeflow و رجیستری‌های خصوصی Harbor است، شعاع انفجار (Blast Radius) یک نفوذ یا فرار از کانتینر بسیار بزرگ می‌شود. بنابراین، امنیت یک ضرورت است، نه گزینه.

معماری یک دفاع لایه‌ای

هیچ موتور امنیتی واحدی نمی‌تواند کل چرخه‌ی حیات یک workload را پوشش دهد. فلسفه‌ی دفاع در عمق می‌گوید چند لایه‌ی مستقل بسازیم. در این معماری، چهار نگهبان که هرکدام در لایه‌ای متفاوت از سیستم‌عامل و کوبرنتیز عمل می‌کنند، بدون وابستگی به هم کنار هم مستقر شده‌اند:

نگهبان	ابزار	وظیفه
دربان (The Bouncer)	Kyverno	مسدود کردن مانیفست‌های ناامن در مرحله‌ی Admission
قفل‌ها (The Locks)	KubeArmor	نظارت بر فراخوانی‌های سیستمی در سطح هسته‌ی لینوکس و امکان مسدودسازی
دوربین مداربسته (The CCTV)	Falco	شناسایی و هشدار درباره‌ی رفتارهای غیرعادی در زمان اجرا
بازرس (The Inspector)	Trivy	اسکن مداوم برای یافتن آسیب‌پذیری‌ها (CVE) و پیکربندی‌های نادرست

هرکدام از این ابزارها به‌طور مستقل کار می‌کنند. اگر یکی از آن‌ها از کار بیفتد، بقیه متوجه نمی‌شوند و همین نکته‌ی کلیدی است. این پشته چهار زمان کلیدی را پوشش می‌دهد: پیش از ورود workloadها به API، هنگام اجرای آن‌ها در سطح کرنل، موقع بروز رفتار غیرعادی و پس از استقرار برای اسکن مداوم.

دربان در ورودی: Kyverno

Kyverno کنترلر اصلی Admission است. هر تعامل با API خوشه، قبل از ذخیره شدن در etcd، از وب‌هوک‌های آن عبور می‌کند. اگر یک مانیفست با قوانین از پیش تعریف‌شده تطبیق نداشته باشد، درخواست رد می‌شود. همچنین Kyverno می‌تواند مانیفست‌ها را در حین عبور تغییر دهد (Mutate)؛ مثلا به‌طور خودکار برای هر namespace جدید یک NetworkPolicy بسازد یا امضای دیجیتال یک تصویر کانتینری را با Cosign تایید کند.

در این پیاده‌سازی، Kyverno نسخه‌ی ۳.۸.۰ در یک namespace جداگانه نصب شده و مدیریت آن به‌طور کامل با GitOps و از طریق ArgoCD انجام می‌شود. این یعنی خداحافظی با kubectl applyهای دستی و پراکنده؛ هر تغییر در تنظیمات امنیتی به‌صورت یک کامیت قابل ردیابی ثبت می‌شود.

یک نکته‌ی عملیاتی این است که Kyverno تنها نگهبان در ورودی نیست. حتی قبل از آن، مکانیسم داخلی و رایگان کوبرنتیز یعنی Pod Security Admission (PSA)، خطاهای ابتدایی را می‌گیرد. مثلا اگر یک اپراتور خسته نیمه‌شب دستور kubectl run nginx --image=nginx بزند، PSA به‌دلیل رعایت‌نشدن حداقل‌های امنیتی (مثل runAsNonRoot) این درخواست را رد می‌کند، بدون اینکه لازم باشد Kyverno وارد عمل شود. این لایه‌بندی عمدی است: ارزان‌ترین نگهبان، ارزان‌ترین اشتباه را می‌گیرد.

قفل‌ها روی هر در: KubeArmor

Kyverno تعیین می‌کند چه چیزی وارد شود؛ KubeArmor مشخص می‌کند پس از ورود چه کارهایی مجاز است. این نکته‌ای است که خیلی از محیط‌های آزمایشی (Homelab) نادیده می‌گیرند: یک Pod می‌تواند همه‌ی بررسی‌های Admission را رد کند اما حین اجرا سراغ فایل /etc/shadow برود یا داخل یک کانتینر دیتابیس یک shell غیرمنتظره اجرا کند.

KubeArmor این شکاف را در جایی می‌بندد که دور زدنش سخت است: هسته‌ی لینوکس. این ابزار با تکیه بر ماژول‌های امنیتی لینوکس (LSM) مثل AppArmor و BPF-LSM، سیاست‌ها را در سطح Pod اعمال می‌کند. وقتی یک عمل ممنوع انجام شود، kernel همان‌جا آن را رد می‌کند.

با این حال، شروع محتاطانه حیاتی است. در این استقرار، KubeArmor فعلا در حالت Audit کار می‌کند. یعنی همه‌ی فراخوانی‌های سیستمی، دسترسی‌های فایل و اتصالات شبکه را رصد و لاگ می‌کند، اما چیزی را مسدود نمی‌کند. هدف این مرحله شناخت الگوی رفتار عادی خوشه است. بعد از آن می‌توان سیاست‌های «حداقل دسترسی» (least privilege) نوشت و حالت را به Enforce تغییر داد. فعال‌سازی فوری حالت مسدودسازی می‌تواند سرویس‌های حیاتی زیرساخت را از کار بیندازد.

سه تله‌ی عملیاتی KubeArmor: ۱. تداخل با Cilium eBPF: پروفایل محدودکننده‌ی پیش‌فرض KubeArmor می‌تواند مانع mount شدن فایل‌سیستم eBPF توسط DaemonSetهای Cilium شود. راه‌حل: افزودن annotation unconfined به این DaemonSetها. ۲. قفل‌شدن Podهای در حال خاتمه: در نسخه‌های جدیدتر کوبرنتیز، مکانیسم annotate کردن Podها توسط KubeArmor می‌تواند باعث بماندن آن‌ها در حالت «Terminating» به‌طور نامحدود شود. ۳. محدود کردن پلاگین‌های ذخیره‌سازی: پلاگین‌های CSI مثل Rook-Ceph که مستقیم با کرنل کار می‌کنند، نباید زیر پروفایل‌های LSM محدودکننده اجرا شوند؛ وگرنه mount شدن volumeها شکست می‌خورد.

جمع‌بندی این بخش: KubeArmor یک «چاقوی جراحی» است، نه یک پتو. workloadهای کاربری را سخت‌گیرانه محدود کنید، اما اجازه دهید زیرساختی‌هایی که مستقیم با کرنل حرف می‌زنند، آزادتر کار کنند.

دوربین روی سقف: Falco

قفل‌ها جلوی نفوذهای از پیش شناخته‌شده را می‌گیرند. اما یک اصل قدیمی امنیت می‌گوید: «حمله‌ای که برایش قاعده ننوشته‌اید، همان است که موفق می‌شود.» اینجا Falco وارد می‌شود. Falco چیزی را مسدود نمی‌کند؛ همه‌چیز را می‌بیند و به‌محض مشاهده‌ی حرکت غیرعادی هشدار می‌دهد.

وقتی KubeArmor فهرست «بد شناخته‌شده» را در کرنل اعمال می‌کند، Falco با eBPF به tracepointهای کرنل وصل می‌شود و فراخوانی‌های سیستمی را با مجموعه‌ای از قواعد تطبیق می‌دهد. اجرای کد بدون فایل از حافظه، یک اتصال خروجی غیرمنتظره از یک Pod، یا اجرای دستور sudo داخل یک کانتینر — شاید هیچ‌کدام قفل KubeArmor را فعال نکنند، اما همه، دوربین Falco را روشن می‌کنند.

در این استقرار، Falco به‌صورت DaemonSet روی هر نود و با درایور modern_ebpf نصب شده است. فعلا همه‌ی هشدارها فقط به stdout می‌روند و از طریق kubectl logs دیده می‌شوند. این نقطه‌ضعف فعلی پشته است: «دوربینی که کسی آن را تماشا نمی‌کند، جلوی حادثه را نمی‌گیرد.»

Falco به‌صورت داخلی و با زیرسیستم Falcosidekick می‌تواند هشدارها را به سرویس‌های بیرونی مثل Slack، Discord، PagerDuty یا سامانه‌های لاگ مثل Loki بفرستد. فعال‌سازی‌اش با تغییر یک flag در مقادیر Helm ممکن است. دلیل فعال‌نشدن فعلی، نیاز به مدیریت امن credentialهای این سرویس‌هاست که باید مثلا از طریق Vault تامین شوند.

بازرس در گشت: Trivy

سه نگهبان اول، «اکنون» را پایش می‌کنند: چیزی که در حال ورود است، در حال اجراست یا همین لحظه رفتار بدی دارد. Trivy چیزی را دنبال می‌کند که آن‌ها نمی‌بینند: زمان. یک تصویر کانتینری ممکن است روز جمعه هنگام push کاملا سالم و امضاشده باشد، اما تا دوشنبه صبح به‌دلیل افشای یک آسیب‌پذیری بحرانی (CVE)، به تهدید تبدیل شود. قفل‌ها سالم‌اند، دوربین چیزی نمی‌بیند؛ تصویر در سکوت مشکل‌دار شده است.

اپراتور Trivy به‌طور مداوم موجودی خوشه را اسکن می‌کند و یافته‌ها را به‌صورت منابع سفارشی (Custom Resources) در کوبرنتیز می‌نویسد. این گزارش‌ها شامل آسیب‌پذیری‌های تصاویر، ممیزی پیکربندی workloadها، بررسی‌های RBAC و حتی گزارش انطباق با استانداردهای CIS و NSA است.

نتیجه‌ای که در این خوشه به‌چشم آمد، غافلگیرکننده بود: طبق گزارش Trivy، بدترین متخلف از نظر تعداد آسیب‌پذیری‌های بحرانی، خود رجیستری خصوصی Harbor است. اجزای مختلف Harbor بین ۲۶ تا ۳۳ آسیب‌پذیری بحرانی دارند. انتشار چنین نتیجه‌ای خوشایند نیست، اما دقیقا دلیل نیاز به بازرس همین است. Harbor همان سرویسی است که باید بقیه‌ی تصاویر را اسکن کند، اما خودش سنگین‌ترین بار CVE را در خوشه دارد؛ چیزی که هیچ‌کدام از سه نگهبان دیگر نشان نمی‌دادند.

یک تله‌ی مهم Trivy: اسکن‌نشدن پنهانی تصاویر خصوصی. برای کشیدن تصویر از رجیستری‌های نیازمند احراز هویت، Trivy به imagePullSecrets تعریف‌شده روی ServiceAccount همان namespace نیاز دارد. اگر این secret تنظیم نشده باشد، اسکن بی‌سروصدا شکست می‌خورد و گزارش‌ها «پاک» به‌نظر می‌رسند؛ نه چون تصویر امن است، بلکه چون Trivy اصلا به آن دسترسی پیدا نکرده است.

جمع‌بندی: کدام ابزار را انتخاب کنم؟

سؤال رایج «کدام‌یک؟» (مثلا Falco یا Kyverno) از اساس درست نیست. سؤال صحیح این است: «برای این لایه‌ی خاص، کدام ابزار مناسب‌تر است؟» امنیت یک خط لوله است و هر نگهبان، یک مرحله‌ی متفاوت از آن را پوشش می‌دهد.

لایه	ابزار انتخاب‌شده	جایگزین‌های معروف	دلیل انتخاب
Admission / Policy-as-Code	Kyverno	OPA/Gatekeeper، Kubewarden، PSA داخلی	سیاست‌های YAMLمحور (بدون نیاز به Rego) + قابلیت Mutate و Generate
اعمال محدودیت در زمان اجرا (Runtime Enforcement)	KubeArmor	AppArmor/Seccomp مستقیم، SELinux	یکپارچه‌سازی ساده با کوبرنتیز، امکان Audit قبل از Enforce
شناسایی رفتار غیرعادی (Runtime Detection)	Falco	Cilium Tetragon، Tracee	جامعه‌ی فعال، قواعد ازپیش‌آماده‌ی گسترده، اتصال آسان با eBPF
اسکن مداوم و ممیزی (Continuous Scanning)	Trivy Operator	Snyk، Grype، Clair	بی‌نیاز از پایگاه‌داده‌ی خارجی، گزارش‌های مبتنی بر CRD، پوشش گسترده (CVE، SBOM، Compliance)

نکته‌ی پایانی این است که شروع این مسیر امنیتی، نیازمند فعال‌سازی هم‌زمان و کامل همه‌ی ابزارها نیست. می‌توانید با PSA و Kyverno شروع کنید، بعد حالت Audit در KubeArmor را اضافه کنید، سپس Falco را برای نظارت مستقر کنید و در نهایت اسکن مداوم Trivy را راه بیندازید. مهم‌ترین قدم همان تغییر نگرش است: امنیت را نه یک ویژگی برای «بعدا»، بلکه شالوده‌ی پلتفرم بدانید؛ قبل از استقرار هر workload حیاتی.