معرفی
این راهنما بر پایه مستندات رسمی پروژه نوشته شده و هدف آن ساختن یک مدل ذهنی دقیق برای طراحی، عملیات و عیب‌یابی است.
نکته 1
eBPF می‌تواند به tracepoint، kprobe، network hook و نقاط دیگر متصل شود.
نکته 2
Verifier و محدودیت‌های runtime برای ایمنی طراحی شده‌اند، اما دسترسی load کردن eBPF خود یک privilege حساس است.
نکته 3
ابزارهای observability و امنیت runtime باید overhead و compatibility kernel را اندازه‌گیری کنند.
برداشت عملیاتی IROSG
قبل از هر تغییر Production، نسخه، وابستگی، سطح دسترسی، rollback و observability را بررسی کنید. منبع رسمی همین صفحه مرجع اصلی جزئیات است.
برنامه eBPF کجا اجرا می‌شود؟
eBPF را بهتر است سازوکاری برای اجرای برنامه محدود در نقاط مشخص کرنل ببینیم، نه یک ابزار واحد با قابلیت ثابت. نوع برنامه تعیین می‌کند به چه نقطه‌ای وصل می‌شود و چه داده یا عملیاتی در دسترس دارد. برنامه متصل به رخداد ردیابی، برنامه شبکه و برنامه مربوط به کنترل امنیتی قراردادهای یکسان ندارند. پیش از انتخاب ابزار، نقطه مشاهده یا اعمال تصمیم را مشخص کنید. این انتخاب تعیین می‌کند چه چیزی را می‌توانید ببینید و چه چیزی بیرون دید باقی می‌ماند.
در یک مثال آموزشی، می‌خواهید تعداد رخدادهای یک عملیات را برای فرایند آزمایشی بشمارید. ابتدا نقطه‌ای را انتخاب کنید که به همان عملیات مربوط است، سپس شناسه فرایند یا زمینه لازم را برای محدود کردن دامنه به کار ببرید. شمارش همه رخدادهای میزبان می‌تواند پرحجم باشد و پاسخ مسئله کوچک شما را دشوار کند. خروجی باید توضیح دهد دقیقاً چه رخدادی شمرده شده؛ شمار فراخوانی یک تابع لزوماً برابر شمار درخواست موفق کاربر نیست.
Verifier چه تضمینی می‌دهد و چه چیزی را نمی‌دهد؟
Verifier پیش از پذیرش برنامه، ویژگی‌هایی از دسترسی حافظه و مسیرهای اجرای آن را بررسی می‌کند. این سازوکار برای محدود کردن رفتار ناامن اهمیت دارد، اما صحت منطق کسب‌وکار یا درست بودن تفسیر داده را ثابت نمی‌کند. برنامه‌ای می‌تواند از نظر verifier پذیرفته شود و همچنان متریک اشتباه تولید کند یا سیاست نامناسب اعمال کند. پس آزمون منطقی و آزمون اثر روی سیستم همچنان ضروری‌اند.
اگر برنامه رد شد، پیام verifier را به عنوان شاهد فنی بخوانید. خطا ممکن است از دسترسی‌ای باشد که کران آن برای تحلیل روشن نیست یا از عملیاتی که نوع برنامه اجازه نمی‌دهد. افزودن تغییر تصادفی تا پذیرش، بدون فهم علت، نگه‌داری را سخت می‌کند. نمونه را کوچک کنید و همان دسترسی یا مسیر مسئله‌دار را جدا بررسی کنید. هدف فقط عبور از verifier نیست؛ هدف داشتن برنامه‌ای است که رفتار و محدودیتش قابل توضیح باشد.
Mapها چگونه داده را نگه می‌دارند؟
Map یکی از راه‌های نگه‌داری و تبادل داده میان برنامه eBPF و فضای کاربر است. نوع map باید با الگوی استفاده هماهنگ باشد: شمارنده ثابت، جدول کلیددار و داده وابسته به CPU نیازهای متفاوتی دارند. انتخاب ساختار بیش از حد بزرگ حافظه مصرف می‌کند و انتخاب ظرفیت ناکافی می‌تواند داده را از دسترس خارج یا عملیات را ناموفق کند. در طراحی، تعداد کلیدهای ممکن و عمر آن‌ها را تخمین بزنید و سپس زیر بار واقعی اندازه بگیرید.
کلیدی مثل شناسه فرایند به تنهایی ممکن است در طول زمان دوباره استفاده شود. اگر داده قدیمی پاک نشود، نتیجه به فرایند تازه نسبت داده می‌شود. قرارداد عمر کلید و پاک‌سازی باید روشن باشد. برای آزمون، فرایندهای کوتاه‌عمر متعددی بسازید و ببینید مصرف map و نتیجه شمارش چگونه تغییر می‌کند. این آزمایش ساده نشان می‌دهد آیا ابزار برای سیستم بلندمدت طراحی شده یا فقط در اجرای کوتاه آزمایشگاهی درست به نظر می‌رسد.
هم‌زمانی و شمارنده‌های دقیق
کرنل روی چند CPU هم‌زمان کار می‌کند و رخدادها ممکن است از چند مسیر به داده مشترک دسترسی داشته باشند. یک شمارنده ظاهراً ساده هم نیازمند توجه به هم‌زمانی است. استفاده از map وابسته به CPU یا سازوکار مناسب دیگر می‌تواند راهی برای کاهش رقابت باشد، اما جمع‌آوری در فضای کاربر نیز باید معنای آن را رعایت کند. نتیجه نهایی باید مشخص کند مقادیر لحظه‌ای‌اند یا در بازه‌ای جمع شده‌اند.
برای اعتبارسنجی، بار کنترل‌شده‌ای با تعداد عملیات معلوم تولید کنید. شمارش ابزار را با منبع مستقل مقایسه کنید و اختلاف را توضیح دهید. اگر نقطه hook قبل از موفقیت عملیات است، ممکن است تلاش‌های ناموفق هم شمرده شوند. این اختلاف الزاماً نقص ابزار نیست، ولی باید در نام متریک و مستندات آن روشن باشد. ابهام در معنای شمارنده می‌تواند تصمیم ظرفیت یا تشخیص امنیتی را به خطا ببرد.
انتقال رخداد به فضای کاربر
ارسال هر رخداد به برنامه کاربر هزینه دارد. در بار زیاد، مصرف‌کننده ممکن است از تولید عقب بماند و buffer محدود پر شود. بنابراین ابزار باید افت رخداد و سلامت مسیر خروجی را قابل مشاهده کند. نبود پیام در رابط کاربری می‌تواند ناشی از نبود رخداد یا شکست جمع‌آوری باشد. یک رویداد آزمایشی شناخته‌شده برای کنترل سلامت و یک شمارنده افت برای کیفیت داده، دو شاهد مکمل هستند.
گاهی بهتر است تجمیع ساده در همان مسیر انجام شود و فقط نتیجه دوره‌ای منتقل گردد. این انتخاب حجم داده را کم می‌کند، ولی جزئیات رویداد منفرد را از بین می‌برد. تصمیم باید از پرسش تحلیل بیاید. اگر فقط نرخ عملیات لازم است، نگه‌داری محتوای کامل هر رخداد ضروری نیست. اگر بررسی حادثه به زمینه دقیق نیاز دارد، نمونه‌برداری یا فیلتر هدفمند می‌تواند میان حجم و ارزش داده تعادل ایجاد کند.
سازگاری کرنل و قابلیت‌های موجود
شماره نسخه کرنل تنها سرنخ است؛ تنظیمات ساخت، قابلیت‌های backportشده و محدودیت محیط نیز اهمیت دارند. پیش از نصب ابزار، روش رسمی تشخیص قابلیت‌ها را اجرا کنید و نتیجه را نگه دارید. وجود یک ویژگی در مستندات آخرین کرنل به معنی وجود آن روی میزبان شما نیست. در کانتینر نیز کرنل میزبان تعیین‌کننده است؛ تغییر ایمیج کاربر به تنهایی ویژگی کرنل را اضافه نمی‌کند.
BTF و روش‌هایی مانند CO-RE می‌توانند حمل‌پذیری بعضی برنامه‌ها را بهتر کنند، اما نباید آن‌ها را تضمین اجرای هر برنامه روی هر میزبان دانست. نوع hook، helperهای لازم و محدودیت‌های امنیتی همچنان باید بررسی شوند. ماتریس کوچکی از کرنل‌ها و توزیع‌های پشتیبانی‌شده خود بسازید و آزمون‌های اصلی را روی آن‌ها اجرا کنید. هنگام ارتقای میزبان، همان آزمون‌ها کمک می‌کنند شکست ابزار مشاهده پیش از حادثه واقعی دیده شود.
دسترسی بارگذاری و مرز اعتماد
توان بارگذاری یا مدیریت برنامه eBPF یک اختیار حساس است. دادن دسترسی گسترده به یک agent برای راحتی نصب باید با نیاز واقعی آن سنجیده شود. ابزار مشاهده ممکن است به داده‌هایی دست یابد که برنامه عادی نباید ببیند. اعتبار منبع باینری، روش به‌روزرسانی و حفاظت از پیکربندی بخشی از این مرز اعتمادند. نام «مشاهده‌پذیری» به خودی خود ابزار را کم‌خطر نمی‌کند.
برای سرویس چندتیمی، مشخص کنید چه کسی می‌تواند برنامه تازه بار کند، mapها را بخواند یا تغییر دهد و خروجی را دریافت کند. جداسازی خواندن متریک از اختیار تغییر برنامه می‌تواند مفید باشد. log عملیات مدیریتی و نسخه برنامه فعال را نگه دارید. اگر هنگام رخداد امنیتی ندانید چه کدی در کرنل متصل بوده، تحلیل رفتار ابزار و میزبان دشوار می‌شود. موجودی برنامه‌ها و نقاط اتصال باید قابل بازرسی باشد.
مشاهده با جلوگیری تفاوت دارد
یک برنامه ردیابی معمولاً شاهد تولید می‌کند و الزاماً عملیات را متوقف نمی‌کند. در مقابل بعضی نقاط اتصال امکان اثرگذاری بر مسیر شبکه یا تصمیم امنیتی دارند. محصولی که از eBPF استفاده می‌کند باید دقیقاً بگوید در کدام نقطه و با چه قراردادی جلوگیری می‌کند. از نام فناوری نمی‌توان نتیجه گرفت همه رخدادهای نامجاز مسدود می‌شوند. آزمون باید هم هشدار و هم نتیجه واقعی عملیات را جدا بررسی کند.
برای نمونه یک اتصال آزمایشی نامجاز تولید کنید. اگر هشدار ثبت شد ولی اتصال انجام شد، ابزار در آن مسیر نقش تشخیص داشته است. این نتیجه باید در طراحی پاسخ لحاظ شود، نه اینکه به عنوان نقص مبهم گزارش شود. اگر سیاست جلوگیری فعال است، آزمون منفی باید ثابت کند عملیات واقعاً رد شده و برنامه مجاز همچنان کار می‌کند. جلوگیری گسترده بدون این دو شاهد می‌تواند دسترس‌پذیری را آسیب بزند.
اندازه‌گیری هزینه و پاک‌سازی
هزینه ابزار را با و بدون بارگذاری برنامه در شرایط یکسان بسنجید. نرخ رخداد، تعداد کلیدها و حجم خروجی را ثبت کنید؛ عدد سربار بدون این زمینه قابل تعمیم نیست. یک ابزار کم‌هزینه در میزبان آرام ممکن است زیر بار فراخوانی شدید رفتار متفاوتی داشته باشد. به‌ویژه مسیرهای پرتکرار باید با دقت انتخاب و فیلتر شوند. اندازه‌گیری تأخیر دنباله توزیع نیز می‌تواند اثری را نشان دهد که میانگین پنهان می‌کند.
در پایان آزمایش، نقاط اتصال و منابع باقی‌مانده را بررسی کنید. pin شدن بعضی منابع می‌تواند عمر آن‌ها را از فرایند بارگذار جدا کند. توقف برنامه کاربر همیشه به معنی حذف همه وضعیت مرتبط نیست. دستورالعمل خروج باید نشان دهد چه چیزی جدا و چه چیزی حفظ می‌شود و چرا. پس از حذف، یک آزمون کوتاه تأیید کند برنامه دیگر اثر مورد نظر را ندارد. این چرخه کامل، استفاده از eBPF را قابل کنترل و قابل بازگشت نگه می‌دارد.
مرز هویت کانتینر و میزبان
شناسه فرایند و نشانی‌ها در namespaceهای مختلف می‌توانند نمایش متفاوتی داشته باشند. ابزار باید روشن کند داده را از دید میزبان گزارش می‌کند یا از دید کانتینر. اگر یک رخداد به workload اشتباه نسبت داده شود، قاعده امنیتی و تحلیل کارایی هر دو آسیب می‌بینند. در آزمایش، دو کانتینر با برنامه مشابه بسازید و رخداد را فقط در یکی تولید کنید. سپس هویت گزارش‌شده را با اطلاعات runtime تطبیق دهید.
تغییر سریع عمر کانتینرها نیز مهم است. داده زمینه‌ای ممکن است بعد از حذف کانتینر دیگر به سادگی در دسترس نباشد. روش ابزار در ثبت یا بازیابی این زمینه را بررسی کنید و از نام کوتاه قابل تکرار به عنوان تنها شناسه استفاده نکنید. زمان، شناسه پایدار رخداد و هویت workload باید کنار هم حفظ شوند. اگر ابزار در لحظه جمع‌آوری نتوانسته زمینه را پیدا کند، بهتر است این ابهام را آشکار کند تا اینکه اطلاعات نادرست را با قطعیت نمایش دهد. چنین محدودیتی باید در تحلیل حادثه نیز صریح بماند و با حدس درباره صاحب فرایند جایگزین نشود.
