معرفی
این راهنما بر پایه مستندات رسمی پروژه نوشته شده و هدف آن ساختن یک مدل ذهنی دقیق برای طراحی، عملیات و عیب‌یابی است.
نکته 1
Pod Security Admission جایگزین داخلی و استاندارد برای enforce کردن Pod Security Standards است.
نکته 2
حالت‌های enforce، audit و warn امکان rollout مرحله‌ای policy را می‌دهند.
نکته 3
Restricted سخت‌گیرانه‌تر است و قبل از rollout باید workloadهای legacy و exceptionها مشخص شوند.
برداشت عملیاتی IROSG
قبل از هر تغییر Production، نسخه، وابستگی، سطح دسترسی، rollback و observability را بررسی کنید. منبع رسمی همین صفحه مرجع اصلی جزئیات است.
پذیرش پاد در کدام نقطه تصمیم می‌گیرد؟
وقتی درخواستی برای ایجاد یا تغییر منبع به API Kubernetes می‌رسد، چند مرحله پیش از ذخیره و اجرا طی می‌شود. Pod Security Admission بخشی از کنترل پذیرش است و مشخصات پاد را با سطح سیاست انتخاب‌شده مقایسه می‌کند. این کنترل، اسکن محتوای تصویر یا پایش رفتار داخل فرایند نیست. اگر مشخصات پاد مجاز باشد، همچنان ممکن است برنامه آسیب‌پذیر یا پیکربندی شبکه نامناسب باشد. شناخت این مرز کمک می‌کند کنترل را در جای درست زنجیره امنیت قرار دهید.
برای مثال، سیاست می‌تواند درخواست بعضی امتیازهای میزبان را رد کند، اما از روی همان بررسی نمی‌فهمد برنامه در پاسخ به ورودی کاربر چه منطق اشتباهی دارد. همچنین حسابی که اجازه ایجاد پاد ندارد، با گذر از سیاست امنیت پاد صاحب آن مجوز نمی‌شود. کنترل دسترسی API و کنترل مشخصات پاد دو پرسش جدا را پاسخ می‌دهند. در طراحی، هرکدام را مستقل آزمایش کنید تا یک نتیجه موفق به اشتباه پوشش همه لایه‌ها تلقی نشود.
سه سطح را بر اساس نیاز بار کاری انتخاب کنید
سطح Privileged محدودیت‌های استاندارد امنیت پاد را اعمال نمی‌کند و برای همه بارهای عادی انتخاب مناسبی نیست. Baseline برای جلوگیری از برخی امتیازهای پرخطر طراحی شده و سازگاری بیشتری با برنامه‌های رایج دارد. Restricted محدودیت‌های سخت‌گیرانه‌تری می‌خواهد و معمولاً به اصلاح مشخصات امنیتی برنامه نیاز دارد. این سطوح جای قضاوت درباره نیاز واقعی برنامه را نمی‌گیرند. انتخاب سطح باید با نوع بار، توان اصلاح تصویر و دامنه اعتماد هماهنگ شود.
یک عامل سطح گره ممکن است برای کار خود به دسترسی‌هایی نیاز داشته باشد که یک خدمت وب عادی نباید داشته باشد. قرار دادن هر دو در یک فضای نام با سیاست باز، مرز را مبهم می‌کند. بهتر است بارهای دارای نیاز ویژه را با مالکیت و دسترسی روشن جدا کنید. استثنا باید به یک نیاز مشخص مربوط باشد و بازبینی شود. اگر همه برنامه‌ها برای راحتی در سطح آزاد اجرا شوند، مزیت اصلی کنترل پذیرش از بین می‌رود.
حالت‌های اخطار، حسابرسی و الزام
می‌توان سیاست را به گونه‌ای به کار گرفت که تخلف هشدار داده شود، در حسابرسی ثبت شود یا درخواست رد شود. این حالت‌ها برای مراحل مختلف مهاجرت مفیدند. اخطار به سازنده منبع کمک می‌کند مشکل را پیش از الزام ببیند. حسابرسی برای دید مرکزی به تخلف‌ها مناسب است، به شرط آنکه مسیر گزارش واقعاً جمع‌آوری و بررسی شود. الزام جلوی پذیرش مشخصات نامعتبر را می‌گیرد. فعال کردن فقط اخطار و سپس فرض مسدود شدن درخواست‌ها اشتباه است.
برای تمرین، یک فضای نام آزمایشی با حالت اخطار بسازید و پادی با مشخصات ناسازگار ارسال کنید. بررسی کنید درخواست چه نتیجه‌ای دارد و هشدار کجا دیده می‌شود. سپس در همان محیط حالت الزام را فعال و درخواست را دوباره آزمایش کنید. تفاوت نتیجه باید روشن باشد. این تمرین را با ابزار استقرار واقعی تیم نیز انجام دهید، زیرا بعضی رابط‌ها هشدار API را کمتر آشکار نشان می‌دهند. سیاستی که پیامش به توسعه‌دهنده نمی‌رسد، فرایند اصلاح کندتری خواهد داشت.
نسخه سیاست را آگاهانه تثبیت کنید
تعریف استانداردها می‌تواند با نسخه Kubernetes تغییر کند. اگر سیاست به آخرین تعریف اشاره کند، ارتقای خوشه ممکن است الزامات تازه‌ای وارد کند. تثبیت نسخه سیاست می‌تواند تغییر را قابل برنامه‌ریزی‌تر کند، ولی نیاز به بازبینی و ارتقای عمدی دارد. هیچ‌یک از دو روش بدون نگهداری کامل نیست. پیش از ارتقا، بارهای موجود و قالب‌های استقرار را با نسخه هدف ارزیابی کنید و تخلف‌های تازه را در محیط آزمایشی ببینید.
نسخه سیاست را در همان مخزنی نگه دارید که تنظیمات فضای نام مدیریت می‌شود. اگر کسی برچسب را دستی تغییر دهد و ابزار اعلامی آن را برگرداند، رفتار پذیرش می‌تواند برای تیم گیج‌کننده شود. مالک تنظیم و روش تغییر باید روشن باشد. در گزارش ارتقا، نسخه خوشه، نسخه سیاست و نتیجه آزمون پادهای نماینده را کنار هم ثبت کنید. این کار کمک می‌کند خطای پس از ارتقا به تغییر مشخصی نسبت داده شود، نه به عبارت مبهم «سخت‌گیری بیشتر امنیت».
اصلاح تصویر و مشخصات به جای حذف کنترل
اگر برنامه برای اجرای عادی به کاربر ریشه وابسته است، ابتدا علت را بررسی کنید. ممکن است فقط مالکیت یک مسیر یا درگاه انتخابی باعث این وابستگی شده باشد. اصلاح تصویر، ایجاد مسیر قابل نوشتن مناسب و انتخاب کاربر غیرریشه می‌تواند نیاز را برطرف کند. اما تغییر شناسه کاربر بدون بررسی دسترسی فایل‌ها ممکن است برنامه را در شروع متوقف کند. آزمون باید نوشتن فایل موقت، خواندن تنظیمات و رفتار هنگام راه‌اندازی دوباره را پوشش دهد.
قابلیت‌های لینوکس و افزایش امتیاز را نیز جدا بررسی کنید. برنامه‌ای که فقط درخواست وب پاسخ می‌دهد معمولاً به مجموعه وسیعی از قابلیت‌های میزبان نیاز ندارد. با این حال، حذف یک قابلیت بدون شناخت استفاده واقعی ممکن است عملیات خاصی را خراب کند. از محیط آزمایشی و بار نماینده استفاده کنید و دلیل هر نیاز باقی‌مانده را ثبت کنید. هدف رسیدن به یک مشخصات حداقلی قابل توضیح است، نه مجموعه‌ای از گزینه‌های کپی‌شده که هیچ‌کس اثرشان را نمی‌داند.
خطای استقرار ممکن است در پادهای ساخته‌شده ظاهر شود
تیم اغلب یک Deployment یا Job ایجاد می‌کند، نه پاد مستقیم. کنترل‌گر بعداً پاد را می‌سازد و ممکن است ایجاد آن به علت سیاست رد شود. بنابراین موفقیت ثبت منبع بالادستی به تنهایی نشان نمی‌دهد بار اجرا خواهد شد. رخدادهای کنترل‌گر و پیام‌های مربوط به ساخت پاد را بررسی کنید. اگر تعداد نمونه آماده صفر است، پیش از تغییر ظرفیت گره، خطای پذیرش را در نظر بگیرید. این ترتیب از عیب‌یابی اشتباه زمان‌بندی جلوگیری می‌کند.
در خط ساخت، قالب نهایی پاد را ارزیابی کنید، نه فقط فایل اولیه‌ای که بعداً توسط ابزارهای دیگر تغییر می‌کند. تزریق‌کننده‌ها، نمودارهای بسته و تنظیمات محیط می‌توانند مشخصات نهایی را متفاوت کنند. یک قالب سالم در محیط توسعه ممکن است در تولید ظرف جانبی متفاوتی بگیرد. آزمون باید به مسیر واقعی ساخت نزدیک باشد. پیام تخلف را به تیم مالک همان بخش برسانید تا اصلاح در منبع درست انجام شود و در انتشار بعدی دوباره از بین نرود.
بارهای موجود و زمان اجرای الزام
تغییر سیاست پذیرش را با اصلاح فوری همه پادهای در حال اجرا یکسان ندانید. کنترل پذیرش روی درخواست‌ها عمل می‌کند؛ بار موجود ممکن است تا زمانی که بازسازی نشده همان وضعیت را حفظ کند. در نتیجه پس از فعال کردن الزام، خدمت ظاهراً سالم است ولی هنگام انتشار بعدی پاد تازه رد می‌شود. برای جلوگیری از غافلگیری، پیش از تغییر، قالب‌های موجود را ارزیابی و بازسازی کنترل‌شده نمونه‌ها را در برنامه بگنجانید. موفقیت روز اول معیار کافی نیست.
یک آزمایش مناسب این است که پاد ناسازگار را در حالت آزاد ایجاد کنید، سپس سیاست را سخت‌تر کنید و تلاش ایجاد نمونه تازه را ببینید. تفاوت عمر نمونه موجود و درخواست تازه را مستند کنید. این تمرین به تیم عملیات کمک می‌کند بفهمد چرا خطا ممکن است چند روز پس از تغییر سیاست ظاهر شود. برنامه انتشار باید با تیم امنیت هماهنگ باشد تا اصلاح قالب پیش از نیاز اضطراری به بازسازی انجام شود.
استثناها باید محدود و قابل مشاهده باشند
گاهی یک مؤلفه زیرساختی به اختیار ویژه نیاز دارد. استثنا را با مرز روشن و حداقل دامنه طراحی کنید و افراد مجاز به استفاده از آن را محدود نگه دارید. اگر هر توسعه‌دهنده بتواند بار خود را به فضای نام آزاد منتقل کند، سیاست سخت‌گیرانه فضای نام عادی اثر کمی خواهد داشت. کنترل دسترسی به ایجاد و تغییر فضاهای نام و برچسب‌های سیاست بخشی از طراحی است. خود سیاست بدون حفاظت از محل تنظیم آن کافی نیست.
برای هر استثنا، مالک، دلیل فنی و برنامه بازبینی ثبت کنید. ممکن است نسخه تازه نرم‌افزار نیاز قدیمی را حذف کرده باشد. استثنای بدون تاریخ و مالک به مرور به مسیر عمومی فرار از کنترل تبدیل می‌شود. آزمون منفی باید نشان دهد حساب عادی نمی‌تواند سیاست فضای نام را ضعیف کند یا از مقصد استقرار غیرمجاز استفاده کند. این آزمون مکمل بررسی مشخصات پاد است و مرز مدیریتی را می‌سنجد.
معیار تحویل سیاست
برای تحویل، مجموعه‌ای از بارهای نماینده انتخاب کنید: خدمت وب، کار زمان‌بندی‌شده، برنامه دارای حجم و عامل زیرساختی. برای هرکدام انتظار پذیرش یا رد را از قبل بنویسید. سپس پیام خطا، مسیر اصلاح و آزمون انتشار دوباره را ثبت کنید. کنترل‌های شبکه، اسکن تصویر، مدیریت راز و پایش زمان اجرا باید جدا باقی بمانند. Pod Security Admission زمانی موفق است که امتیازهای نامطلوب را در مرز ایجاد پاد محدود کند و تیم بتواند دلیل تصمیم را بفهمد. یک سیاست قابل توضیح و آزموده از مجموعه برچسب‌هایی که فقط در ممیزی دیده می‌شوند ارزش بیشتری دارد.
یک مسیر اصلاح برای توسعه‌دهنده
پیام رد شدن باید به اقدام مشخص تبدیل شود. در راهنمای تیم، برای خطاهای پرتکرار توضیح دهید کدام بخش مشخصات نیاز به تغییر دارد و چه آزمونی پس از تغییر لازم است. برای نمونه، انتخاب کاربر غیرریشه باید همراه بررسی مالکیت مسیرهای نوشتنی باشد؛ حذف دسترسی میزبان باید با روش جایگزین دریافت داده هماهنگ شود. دادن یک فایل نمونه عمومی بدون توضیح علت ممکن است خطا را موقتاً پنهان کند، اما در برنامه بعدی دوباره تکرار می‌شود.
یک درخواست تغییر کوچک از توسعه‌دهنده بخواهید که فقط همان نیاز امنیتی را اصلاح کند. پس از استقرار آزمایشی، هم پذیرش موفق و هم رفتار واقعی برنامه را ببینید. اگر برنامه هنوز اختیار ویژه می‌خواهد، دلیل را با شواهد ثبت و با مالک بستر بررسی کنید. این فرایند کمک می‌کند امنیت به حذف کور گزینه‌ها یا دور زدن سیاست تبدیل نشود و تیم به تدریج تصاویر و قالب‌های قابل استفاده مجدد و محدودتر بسازد.
