مقدمه: از دیدن رویداد تا متوقف‌کردن آن
امنیت زمان اجرا (Runtime Security) در Kubernetes فقط به معنای پیدا کردن رفتار مشکوک نیست؛ ارزش عملی آن زمانی آشکار می‌شود که یک فرایند پیش از خواندن راز، اجرای ابزار اضافی یا تغییر مسیر ارتباطی متوقف شود. KubeArmor یک موتور متن‌باز اجرای امنیت زمان اجرا برای بارکاری‌های ابری‌محور است که طبق معرفی رسمی پروژه، برای سخت‌سازی و محصورسازی بارکاری‌ها از eBPF و ماژول‌های امنیتی لینوکس (Linux Security Modules یا LSM) استفاده می‌کند. این راهنمای تألیفی IROSG میان «واقعیت مستند» و «تحلیل تحریریه» تفاوت می‌گذارد.
نکته کلیدی این است که مشاهده (Observability) و اجرا/اعمال سیاست (Enforcement) دو کار متفاوت‌اند. مشاهده می‌گوید کدام فرایند در کدام کانتینر چه فایل، شبکه، قابلیت یا فراخوانی سیستمی را لمس کرده است؛ اعمال سیاست به هسته لینوکس می‌گوید اجازه بده، فقط ثبت کن، یا همان لحظه رد کن. KubeArmor این دو مسیر را کنار هم می‌گذارد: هویت کانتینر یا گره را به رویداد کم‌سطح پیوند می‌دهد، سیاست CRD را به سازوکار LSM ترجمه می‌کند و نتیجه را به لاگ و سامانه عملیات امنیتی می‌رساند.
معماری در یک نگاه: هویت، ناظر، نگهبان و گزارشگر
واقعیت مستند: چهار حلقه به‌هم‌پیوسته
در Kubernetes، KubeArmor به‌صورت DaemonSet روی هر گره اجرا می‌شود و در حالت مستقل نیز روی لینوکس، ماشین مجازی یا فلز خام قابل استفاده است. مؤلفه هویت کانتینر/گره (Container/Node Identity) اطلاعات API سرور و زمان‌اجرای کانتینر، مانند شناسه کانتینر، نام Pod، فضای نام، برچسب‌ها، PID Namespace و Mount Namespace را گردآوری می‌کند. بدین‌ترتیب رویداد کم‌سطحی مانند «PID فایل را باز کرد» به «کانتینر دارای برچسب app=my-web-app در Pod مشخص» پیوند می‌خورد و selector هدف درست را می‌یابد. مستندات هویت
System Monitor یا ناظر سامانه با eBPF اجرای فرایند، باز و حذف فایل، اتصال و پذیرش شبکه، تغییر قابلیت‌ها و برخی فراخوانی‌های سیستمی را می‌بیند. رویداد از هسته و BPF ring buffer به فضای کاربر می‌رسد و سپس هویت، مسیر، فرایند والد و نتیجه به آن افزوده می‌شود؛ این دیدپذیری به تغییر برنامه نیاز ندارد. شرح ناظر سامانه
Runtime Enforcer یا اعمال‌گر زمان اجرا نقش نگهبان را دارد. مستند رسمی می‌گوید سیاست سطح‌بالای KubeArmor به دستور قابل فهم برای AppArmor، SELinux یا BPF-LSM ترجمه می‌شود. هنگام راه‌اندازی، دسترس‌پذیری LSMها بررسی می‌شود و lsm.lsmOrder می‌تواند ترتیب ترجیح، مانند bpf، selinux و apparmor، را تعیین کند. نخستین گزینه قابل پشتیبانی و قابل مقداردهی فعال می‌شود. اگر هیچ اعمال‌گر راه نیفتد، KubeArmor عمدتاً برای پایش می‌ماند؛ پس نصب موفق برابر با مسدودسازی فعال نیست. Runtime Enforcer رسمی
Log Feeder خروجی را به پیام‌های ساخت‌یافته Protobuf و رابط gRPC تبدیل می‌کند. kArmor و کلاینت‌های دیگر می‌توانند هشدارها و لاگ‌ها را مصرف کنند و SIEM سازمان نیز می‌تواند به این جریان متصل شود. SOC در این حالت هم تلاش مسدودشده و هم رفتار Auditشده‌ای را می‌بیند که هنوز مجاز بوده است. شرح Log Feeder
eBPF چه چیزی اضافه می‌کند؟
eBPF برنامه‌های کوچک تأییدشده‌ای را در نقاط مشخص هسته اجرا می‌کند. در نقش مشاهده‌گر، رویداد را جمع و به فضای کاربر می‌فرستد؛ در نقش BPF-LSM، قواعد را از BPF Map می‌خواند و در قلاب LSM تصمیم می‌گیرد. تصمیم در همان مسیر امنیتی هسته گرفته می‌شود و برای هر تلاش نیاز به رفت‌وبرگشت کامل به عامل کاربری ندارد. بااین‌حال، این نکته ادعای «سربار صفر» نیست؛ نتیجه به kernel، توزیع و LSM موجود وابسته است.
سیاست CRD: زبان Kubernetes برای کنترل رفتار
ساختار و معنای عمل‌ها
نوع اصلی سیاست کانتینری KubeArmorPolicy با apiVersion برابر security.kubearmor.com/v1 است. metadata نام و فضای نام را مشخص می‌کند؛ selector با matchLabels یا matchExpressions هدف را برمی‌گزیند. process مسیر اجرایی، پوشه و زیرپوشه یا الگو را هدف می‌گیرد؛ file مسیر یا پوشه و readOnly را؛ network پروتکل‌های TCP، UDP و ICMP را؛ capabilities قابلیت‌هایی مانند net_raw را؛ و syscalls فراخوانی‌های معین را. severity از ۱ تا ۱۰، tag و message برای هشدار اختیاری‌اند. مشخصات رسمی سیاست
سه عمل Allow، Audit و Block هستند. Allow در مدل کم‌صلاحیت موارد صریح را عبور می‌دهد؛ Audit عمل را مجاز می‌کند و رویداد می‌سازد؛ Block آن را رد می‌کند و برنامه معمولاً Permission denied می‌گیرد. محدودیت مهم مستندات این است که system call monitoring فقط Audit را پشتیبانی می‌کند، حتی اگر مقدار دیگری نوشته شود.
نمونه محدودکردن اجرای ابزار مدیریت بسته:
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
name: block-pkg-mgmt-tools-exec
spec:
selector:
matchLabels:
app: nginx
process:
matchPaths:
- path: /usr/bin/apt
- path: /usr/bin/apt-get
action: Block
این سیاست اجرای مسیرهای نام‌برده را در مرز هسته رد می‌کند. تحلیل تحریریه: در تولید، مسیر و تصویر واقعی را تطبیق دهید و نمونه nginx را تعمیم ندهید؛ Allow را کوچک نگه دارید، چون Allow کردن ریشه فایل‌سیستم می‌تواند کمترین امتیاز را خنثی کند.
نصب آزمایشی مرحله‌به‌مرحله، بدون پریدن به Block
پیش‌نیاز و بررسی محیط
۱. خوشه آزمایشی Kubernetes، دسترسی kubectl و اجازه نصب Chart لازم است. راهنمای رسمی توصیه می‌کند پیش از نصب Support Matrix را بخوانید. جدول برای ترکیب‌های مختلف، مشاهده، قواعد Audit، قواعد Blocking و Network Segmentation را جداگانه نشان می‌دهد؛ «Full» یعنی مشاهده و اعمال و «Partial» یعنی فقط مشاهده. راهنمای استقرار و ماتریس پشتیبانی
۲. نوع گره، معماری و LSM فعال را یادداشت کنید. ردیف‌های ماتریس نشان می‌دهند که پلتفرم‌های مختلف BPF-LSM، AppArmor یا SELinux دارند و نمی‌توان وضعیت یک کلاستر سفارشی را از روی ردیف مشابه تضمین کرد.
۳. در namespace جدا و روی بارکاری غیرحساس شروع کنید. دیدپذیری فایل طبق راهنما پیش‌فرض خاموش است تا تله‌متری کمینه بماند؛ برای سیاست فایل‌محور باید آن را آگاهانه فعال کرد.
نصب و ایجاد هدف آزمایشی
دستورهای رسمی Chart چنین‌اند:
helm repo add kubearmor https://kubearmor.github.io/charts
helm repo update kubearmor
helm upgrade --install kubearmor-operator kubearmor/kubearmor-operator \
-n kubearmor --create-namespace
kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/pkg/KubeArmorOperator/config/samples/sample-config.yml
kArmor اختیاری است؛ راهنمای رسمی برای آن نصب‌کننده curl را پیشنهاد می‌کند و می‌گوید sudo فقط برای /usr/local/bin لازم است. سپس هدف بسازید:
kubectl create deployment nginx --image=nginx
POD=$(kubectl get pod -l app=nginx -o name)
ابتدا نسخه Audit سیاست apt را اعمال کنید و با kubectl exec -it $POD -- bash -c "apt update" رفتار را ببینید. سپس همان قانون را Block کنید. راهنمای رسمی برای Block خطای Permission denied و کد خروجی ۱۲۶ را نشان می‌دهد؛ در Audit، دستور عبور می‌کند و رویداد ثبت می‌شود. این تمرین مرز مشاهده و اعمال را روشن می‌کند.
دیدپذیری و لاگ
kubectl annotate ns default kubearmor-visibility="process,file,network" --overwrite
karmor logs -n default --json
رخداد ساخت‌یافته می‌تواند زمان، کلاستر و گره، namespace، Pod، برچسب، شناسه و تصویر کانتینر، PIDها، نام سیاست، شدت، عملیات، منبع، داده syscall، اعمال‌گر، Action و Result را حمل کند. این غنا برای SOC مفید است، اما شناسه کانتینر، مسیر، فرمان و برچسب‌ها ممکن است اطلاعات عملیاتی یا شخصی غیرمستقیم باشند؛ دسترسی، retention و ارسال رمزگذاری‌شده به SIEM را کنترل کنید.
مشاهده در برابر enforcement: یک مدل تصمیم‌گیری
می‌توان این تفاوت را با چهار حالت ساده توضیح داد:
| وضعیت | نتیجه برای برنامه | نتیجه برای SOC | کاربرد مناسب |
|---|---|---|---|
| مشاهده عمومی | رفتار اجرا می‌شود | لاگ سامانه | شناخت baseline |
| Audit | رفتار اجرا می‌شود | هشدار نقض/تطبیق | آزمون سیاست و کشف رفتار |
| Block | رفتار با خطا متوقف می‌شود | هشدار مسدودسازی | کنترل قطعی و کاهش سطح حمله |
| Allow کم‌صلاحیت | فقط موارد صریح عبور می‌کنند | رویدادهای عدم انطباق | سخت‌سازی نهایی |
اگر اعمال‌گر انتخاب نشود، انتظار Block را نباید به مشاهده تفسیر کرد. اگر فایل‌دیدپذیری خاموش باشد، نبود لاگ فایل به معنای نبود دسترسی نیست. اگر یک سیاست Allow وارد شود، posture پیش‌فرض باید با دقت تعیین شود؛ راهنمای رسمی نشان می‌دهد می‌توان posture فضای نام را به block تغییر داد و تنها اجرای nginx و bash را Allow کرد. چنین اقدامی نمونه zero-trust و «به‌طور پیش‌فرض ممنوع» است، اما کوچک‌ترین خطای فهرست مجاز می‌تواند سرویس را از کار بیندازد.
تحلیل تأثیر، مزایا و محدودیت‌ها
مزیت‌ها و کاربردهای مجاز
مزیت نخست، جلوگیری درون‌خطی است: پروژه می‌گوید LSM پیش از تکمیل عمل تصمیم می‌گیرد، نه اینکه پس از مشاهده نیت مخرب، فرایند یا Pod را بکشد. دوم، سیاست براساس هویت Kubernetes نوشته می‌شود و لازم نیست برای هر ابر زبان خام LSM را دستی بازنویسی کنید. سوم، فایل، اجرای برنامه، شبکه، capability و مشاهده فرایند در یک مدل CRD جمع می‌شوند. چهارم، محصول برای بارکاری کانتینری، گره و در حالت systemd برای VM/فلز خام مطرح شده است؛ قابلیت دقیق را باید از ماتریس همان پلتفرم خواند.
کاربرد مشروع شامل جلوگیری از package manager، حفاظت از token حساب سرویس، محدودکردن مسیر حساس، حذف CAP_NET_RAW، حسابرسی ICMP یا syscall و ساخت baseline برای SOC است؛ اینها کنترل دفاعی‌اند، نه ابزار اخلال یا دورزدن دسترسی.
محدودیت و failure mode
نبود LSM قابل مقداردهی، محصول را عمدتاً مشاهده‌ای می‌کند. ناسازگاری پلتفرم یا kernel نیز محتمل است؛ ماتریس بعضی ردیف‌ها را برای blocking منفی یا فقط مشاهده نشان می‌دهد. AppArmor به پروفایل و parser، SELinux به زمینه‌ها و ابزارهای مربوط، و BPF-LSM به برنامه‌ها، Mapها، قلاب LSM و قابلیت kernel نیاز دارد؛ خطای بارگذاری می‌تواند لاگ خطا بدون enforcement کامل بسازد.
مسیر file باید در image وجود داشته باشد و selector نادرست سیاست را بی‌اثر می‌کند؛ تغییر image یا entrypoint baseline را عوض می‌کند و recursive گسترده سرویس را تهدید می‌کند. چون کانال پرِ Log Feeder ممکن است پیام را drop کند، سلامت Daemon و شمارش drop را پایش کنید.
مقایسه محدود با Tracee و Falco؛ آنچه نمی‌دانیم
صفحات رسمی KubeArmor که در این پژوهش بررسی شدند جدول مستقیم، benchmark یا ادعای هم‌ترازی/برتری در برابر Tracee و Falco ارائه نمی‌کنند؛ بنابراین نسبت‌دادن معماری، پوشش رویداد یا CVSS به آن دو در این مقاله مجاز نیست. مقایسه مستند و محدود این است: KubeArmor در اسناد خود بر enforcement درون‌خطی با LSM، CRDهای هویت‌محور و سه‌گانه Allow/Audit/Block تأکید می‌کند، در حالی که از این منابع نمی‌توان درباره جزئیات محصول‌های دیگر نتیجه گرفت. در یک ارزیابی حرفه‌ای، Tracee و Falco را فقط در آزمایش جداگانه و با سنجه‌های یکسانِ دقت رویداد، امکان مسدودسازی، سربار، پشتیبانی kernel، کیفیت خروجی و ادغام SOC مقایسه کنید؛ این پیشنهاد روش‌شناختی است، نه ادعای نتیجه.
راهنمای سخت‌سازی zero-trust برای تیم دفاع
۱. مالک سرویس مسیرهای ضروری، فرایندهای فرزند، فایل‌های خواندنی و پروتکل‌ها را فهرست کند.
۲. visibility پردازش/فایل/شبکه را در namespace آزمایشی فعال و رفتار عادی را ثبت کنید.
۳. selector دقیق برچسبی بسازید و برای هر قانون severity، tag و پیام عملیاتی بگذارید.
۴. ابتدا Audit کنید؛ رفتار عادی، health check و jobهای مهاجرت را از رفتار مشکوک جدا کنید.
۵. پس از بازبینی SOC فقط مسیرهای پرخطر را Block کنید؛ برای Syscall انتظار Audit داشته باشید.
۶. posture را به block تغییر دهید و Allowهای کوچک را با آزمون سرویس و rollback اعتبارسنجی کنید.
۷. روی هر گره EnforcerType، سلامت Daemon، خطای بارگذاری، drop لاگ و نتیجه آزمون ممنوع را ثبت کنید.
۸. خروجی را به SIEM بدهید و retention، نقش‌ها، رمزنگاری انتقال و دسترسی پیمانکار را مستند کنید.
چک‌لیست انتشار
- [ ] پلتفرم و kernel با Support Matrix تطبیق داده شده است.
- [ ] BPF-LSM، AppArmor یا SELinux واقعی گره مشخص است.
- [ ] یک Block آزمایشی با خطای قابل مشاهده تأیید شده است.
- [ ] برای هر Allow فهرست ضروری و روش rollback وجود دارد.
- [ ] سیاست Syscall به‌اشتباه مسدودسازی تلقی نشده است.
- [ ] لاگ Audit و Block به SOC می‌رسد و drop آن پایش می‌شود.
- [ ] token، secret، socket و داده شخصی در لاگ طبقه‌بندی شده‌اند.
- [ ] تغییر image، برچسب یا kernel بازآزمایی را فعال می‌کند.
پرسش‌های متداول
آیا KubeArmor فقط برای Kubernetes است؟
خیر. منابع رسمی Kubernetes و حالت systemd برای کانتینر مستقل، VM و فلز خام را معرفی می‌کنند؛ قابلیت مؤثر باید برای همان حالت بررسی شود.
Audit یعنی امنیت اعمال شده است؟
خیر. Audit اجازه عبور می‌دهد و گزارش می‌سازد؛ جلوگیری به Block یا Allow کم‌صلاحیت و اعمال‌گر فعال نیاز دارد.
چرا لاگ می‌آید اما عمل مسدود نمی‌شود؟
نبود LSM قابل استفاده، پلتفرم فقط‌مشاهده، خطای مقداردهی اعمال‌گر یا selector نادرست محتمل است. ماتریس و سلامت Daemon را بررسی کنید.
آیا همه دیدپذیری‌ها را فعال کنیم؟
نه الزاماً. دیدپذیری فایل پیش‌فرض خاموش است تا تله‌متری کمینه شود؛ آن را هدفمند و با سیاست نگهداری داده فعال کنید.
آیا جایگزین admission یا RBAC است؟
این منابع چنین ادعایی ندارند. KubeArmor لایه زمان اجراست و مکمل admission، RBAC، امنیت زنجیره تأمین، شبکه و وصله‌کردن محسوب می‌شود.
نتیجه‌گیری
KubeArmor زمانی بیشترین ارزش را دارد که تیم از «دیدن رفتار» به «تصمیم قابل آزمون» برسد: هویت Kubernetes باید درست به namespaceهای لینوکس نگاشت شود، Runtime Enforcer باید واقعاً فعال باشد، CRD باید کم‌صلاحیت و مرحله‌ای طراحی شود، و Log Feeder باید نتیجه را به SOC برساند. eBPF و BPF-LSM مسیر کم‌سطح و درون‌هسته‌ای برای مشاهده و جلوگیری فراهم می‌کنند، اما سازگاری kernel و LSM، تفاوت Full و Partial در پلتفرم‌ها، خطای سیاست و ریزش احتمالی لاگ محدودیت‌های واقعی‌اند. رویکرد مسئولانه این است که از Audit و baseline شروع کنیم، با آزمایش Block صحت را ثابت کنیم، داده تله‌متری را کمینه و حفاظت کنیم، و تنها پس از بازبینی اثر سرویس، zero-trust را در تولید گسترش دهیم.
