سیاست روی چه چیزی اعمال می‌شود؟
NetworkPolicy بومی Kubernetes با انتخاب Podها و توصیف ترافیک ورودی یا خروجی، مرز ارتباط را مشخص می‌کند. اجرای واقعی آن به افزونه شبکه‌ای نیاز دارد که این قابلیت را پشتیبانی کند. بنابراین ساخت یک شیء NetworkPolicy بدون بررسی پیاده‌سازی شبکه، شاهد اعمال محدودیت نیست.
سیاست‌های بومی Kubernetes ماهیت اجازه‌دهنده دارند و اجازه‌های چند سیاست مرتبط با هم ترکیب می‌شوند. یک Pod که برای یک جهت هنوز تحت سیاست محدودکننده قرار نگرفته، همان وضعیت Pod ایزوله‌شده را ندارد. Calico علاوه بر پشتیبانی از این مدل، قابلیت‌های سیاستی گسترده‌تری دارد؛ نباید همه آنها را ویژگی استاندارد NetworkPolicy معرفی کرد.
چرا DNS اولین قربانی آزمایش عجولانه است؟
وقتی خروجی برنامه محدود می‌شود، وابستگی‌هایی که قبلاً پنهان بودند آشکار می‌شوند: حل نام، ارتباط با پایگاه داده، سرویس هویت و ابزار پایش. بازبودن پورت برنامه به‌تنهایی کافی نیست. مقصد DNS و مسیر واقعی آن را در خوشه خود پیدا کنید؛ عدد یا برچسب یک مثال اینترنتی ممکن است برای خوشه شما مناسب نباشد.
تمرین پیشنهادی تحریریه
در namespace جداگانه سه برنامه فرضی بسازید: وب، API و یک مصرف‌کننده غیرمجاز. ابتدا ارتباط‌های فعلی را ثبت کنید. سپس فقط API را انتخاب کنید و دسترسی از وب را اجازه دهید؛ ارتباط مصرف‌کننده غیرمجاز باید ناموفق شود. هر آزمون را با نام سرویس و آدرس مستقیم تکرار کنید تا خطای DNS را با ردشدن اتصال برنامه اشتباه نگیرید.
برای مرحله خروجی، پیش از محدودسازی، فهرست وابستگی‌ها را کامل کنید. آزمون موفق فقط این نیست که یک درخواست مجاز جواب دهد؛ باید یک درخواست ممنوع نیز واقعاً رد شود. همچنین بررسی کنید Pod جدید با همان برچسب‌ها چه سیاستی می‌گیرد.
معیار نگهداری
پیشنهاد ما ثبت دلیل هر اجازه و مالک آن در کنار تغییر سیاست است. سیاستی که دیگر کسی علت وجودش را نمی‌داند، دیر یا زود به یک استثنای دائمی تبدیل می‌شود. توسعه تدریجی سیاست با آزمون‌های تکرارپذیر، از یک فایل بزرگ با اجازه‌های گسترده قابل‌اعتمادتر است.
پیش از نوشتن سیاست، مسیر بسته را مشخص کنید
برای برنامه‌ای که از وب به API و سپس به پایگاه داده متصل می‌شود، سه رابطه مجزا وجود دارد. اجازه ورود کاربر به وب، اجازه خروج وب به API را ایجاد نمی‌کند. همچنین انتخاب API برای محدودسازی ترافیک ورودی، به تنهایی خروج آن به پایگاه داده را محدود نمی‌کند. برای هر رابطه، مبدأ، مقصد، پروتکل و درگاه را بنویسید. اگر از نام سرویس استفاده می‌شود، حل نام یک رابطه مستقل است. این جدول کوچک بعداً به مجموعه آزمون تبدیل می‌شود و کمک می‌کند وابستگی نامشخص را با یک اجازه کلی به همه مقصدها پنهان نکنید.
در همان جدول مشخص کنید مقصد داخل خوشه است یا بیرون آن. اتصال به سرویس خارجی ممکن است به آدرس‌هایی وابسته باشد که تغییر می‌کنند. NetworkPolicy استاندارد را نباید فهرست مجاز نام دامنه فرض کرد. اگر نیاز شما سیاست بر اساس نام دامنه است، باید قابلیت و محدودیت راهکار مکمل را جدا بررسی کنید. همچنین آدرس واقعی دیده‌شده در نقطه اعمال سیاست ممکن است با چیزی که برنامه تصور می‌کند فرق داشته باشد؛ ترجمه آدرس و مسیر سرویس در این موضوع اثر دارند. نتیجه را با مشاهده ترافیک آزمایشی بسنجید، نه فقط خواندن manifest.
انتخاب‌گرها و خطاهای منطقی رایج
برچسب Pod بخشی از قرارداد امنیتی می‌شود وقتی سیاست بر اساس آن انتخاب می‌کند. اگر تیم استقرار برچسب را تغییر دهد، ممکن است برنامه دیگر زیر پوشش همان سیاست نباشد. بنابراین نام برچسب‌ها را مانند یک رابط پایدار مستند کنید. در آزمایش، Pod تازه‌ای با همان نقش بسازید و بررسی کنید که رفتار آن با نسخه قبلی یکسان است. فقط آزمایش Pod قدیمی کافی نیست؛ rollout بعدی باید همان محدودیت را به طور خودکار به ارث ببرد.
ساختار انتخاب‌گر فضای نام و انتخاب‌گر Pod را با دقت بخوانید. نوشتن آنها در یک عضو واحد یا در اعضای مستقل می‌تواند معنای ترکیبی متفاوتی ایجاد کند. برای جلوگیری از اشتباه، به جای اتکا به ظاهر فایل، دو مبدأ با برچسب مشابه در دو فضای نام متفاوت بسازید. یکی باید اجازه داشته باشد و دیگری نباید. این آزمون کوچک خطایی را آشکار می‌کند که ممکن است در یک محیط تک‌فضای‌نام پنهان بماند. همچنین انتخاب‌گر خالی را آگاهانه استفاده کنید، چون معمولاً دامنه بسیار وسیع‌تری از یک برنامه دارد.
اگر چند سیاست یک Pod را انتخاب کنند، باید مجموع اجازه‌ها را بررسی کنید. اضافه کردن یک سیاست محدودکننده جدید لزوماً اجازه گسترده سیاست قدیمی را خنثی نمی‌کند. در بازبینی، همه سیاست‌های مرتبط با همان Pod را فهرست کنید و برای هر مسیر مجاز، مشخص کنید کدام شیء آن را اجازه داده است. حذف یا اصلاح یک سیاست باید همراه با آزمون مسیرهای مجاز و ممنوع باشد. نام فایل یا توضیح بالای آن مرجع نهایی رفتار نیست؛ انتخاب‌گرها و قواعد مؤثر تعیین‌کننده‌اند.
DNS را به عنوان یک سرویس واقعی آزمایش کنید
ابتدا از داخل Pod آزمایشی یک نام شناخته‌شده داخلی را حل کنید و نتیجه را ثبت کنید. سپس اتصال به همان سرویس با آدرس مستقیم را بسنجید. اگر اتصال مستقیم کار می‌کند ولی نام حل نمی‌شود، مشکل احتمالاً در وابستگی DNS یا تنظیمات حل نام است. اگر هر دو شکست می‌خورند، به مسیر برنامه نیز توجه کنید. این تفکیک ساده از اضافه کردن اجازه‌های وسیع برای حل یک خطای محدود جلوگیری می‌کند و زمان تشخیص را کاهش می‌دهد.
در خوشه‌ای که از کش محلی DNS یا معماری متفاوتی استفاده می‌کند، مقصد واقعی پرس‌وجو ممکن است همان Podهای DNS مرکزی نباشد. فایل تنظیم resolver داخل Pod و مستندات استقرار خوشه را بررسی کنید. درخواست‌های DNS نیز فقط یک الگوی ثابت ندارند؛ در طراحی آزمون، رفتار واقعی کلاینت و نیاز به پروتکل‌های پشتیبانی‌شده را لحاظ کنید. موفق بودن یک پرس‌وجوی کوچک، پوشش همه پاسخ‌ها و شرایط را ثابت نمی‌کند. هدف این نیست که درگاه‌های بیشتری بی‌دلیل باز شوند؛ هدف شناخت مسیر مورد نیاز در محیط خودتان است.
اجرای مرحله‌ای با امکان مشاهده
یک فضای نام آزمایشی انتخاب کنید که سرویس‌های حیاتی خوشه در آن نباشند. از سیاست ورود شروع کنید و پس از روشن شدن رفتار، خروج را محدود کنید. در هر مرحله یک کلاینت مجاز و یک کلاینت غیرمجاز داشته باشید. برای آزمون ناموفق، زمان انتظار محدود تعیین کنید تا نتیجه آویزان نماند. رد اتصال، timeout و پاسخ خطای خود برنامه معنی یکسان ندارند؛ وضعیت دقیق را در گزارش بنویسید. اگر درخواست به برنامه رسیده و برنامه آن را رد کرده، این الزاماً شاهد مسدود شدن شبکه نیست.
پس از موفقیت آزمایش، یک نمونه کم‌ترافیک از workload واقعی را انتخاب کنید. رفتار راه‌اندازی، دریافت تنظیمات، اتصال به سرویس هویت و ارسال داده پایش را نیز بسنجید. برخی وابستگی‌ها فقط هنگام شروع فرایند یا چرخش اعتبارنامه استفاده می‌شوند و آزمون درخواست معمولی آنها را نمی‌بیند. بازسازی Pod پس از اعمال سیاست کمک می‌کند این مسیرها آشکار شوند. برای سرویس‌هایی که کار زمان‌بندی‌شده دارند، یک اجرای واقعی همان کار را در دوره ارزیابی بگنجانید.
تفاوت سیاست شبکه و مجوز برنامه
اجازه اتصال شبکه به معنای اجازه خواندن هر داده در برنامه نیست. اگر وب به API دسترسی دارد، API همچنان باید هویت و مجوز درخواست را بررسی کند. NetworkPolicy معمولاً نمی‌داند کاربر کدام گزارش را درخواست کرده یا توکن او برای چه پروژه‌ای معتبر است. به همین ترتیب، رمزنگاری ارتباط و اعتبارسنجی گواهی مسئولیتی جدا دارند. سیاست شبکه دامنه ارتباط را کوچک می‌کند، اما جای کنترل دسترسی در لایه برنامه را نمی‌گیرد.
همچنین باید حدود پوشش را بشناسید. رفتار ترافیک میزبان، Podهای دارای شبکه میزبان و مسیرهای خاص افزونه را با مستندات همان نسخه بررسی کنید. یک آزمایش موفق میان دو Pod عادی را به همه مسیرهای خوشه تعمیم ندهید. اگر از قابلیت‌های اختصاصی Calico مانند سیاست‌های گسترده‌تر استفاده می‌کنید، نام نوع شیء و تفاوت آن با NetworkPolicy بومی را در مستند تیم بنویسید. این کار هنگام مهاجرت افزونه شبکه یا بررسی پیکربندی توسط تیم دیگر از برداشت اشتباه جلوگیری می‌کند.
نگهداری سیاست همراه با تغییر برنامه
هر مسیر مجاز بهتر است به یک نیاز مشخص متصل باشد: وب به API برای خواندن محصول، API به پایگاه داده برای ثبت سفارش و برنامه به DNS برای حل نام. اگر یک وابستگی حذف شد، اجازه مربوط را نیز در همان تغییر بررسی کنید. سیاست‌های قدیمی که هیچ آزمونی آنها را پوشش نمی‌دهد به تدریج دامنه دسترسی را افزایش می‌دهند. مرور دوره‌ای می‌تواند از مقایسه فهرست وابستگی‌های فعلی با قواعد موجود شروع شود، بدون اینکه همه قواعد یک‌باره حذف شوند.
برای بازگشت، نسخه قبلی سیاست را آماده نگه دارید و بدانید چه کسی مجاز به اعمال آن است. در یک اختلال، باز کردن خروج به همه مقصدها ممکن است خدمت را برگرداند ولی علت را پنهان کند؛ اگر استثنای اضطراری لازم شد، محدوده و زمان پایان آن را ثبت کنید. پس از رفع مشکل، یک آزمون جدید برای همان وابستگی اضافه کنید. ارزش حادثه برای تیم در این است که دفعه بعد مسیر ناشناخته به یک فرض آزموده تبدیل شده باشد، نه اینکه استثنای موقت برای همیشه باقی بماند.
ثبت نتیجه به شکلی که بعداً قابل اعتماد باشد
برای هر آزمون، نام فضای نام، برچسب‌های مبدأ و مقصد، درگاه و نتیجه را کنار هم نگه دارید. اگر فقط بنویسید «شبکه قطع شد»، همکار بعدی نمی‌تواند تشخیص دهد آیا سیاست درست کار کرده یا برنامه مقصد از ابتدا خاموش بوده است. پیش از آزمون ممنوع، سلامت مقصد را از مبدأ مجاز بررسی کنید. پس از آزمون نیز یک اتصال مجاز دیگر انجام دهید تا تغییر اتفاقی سرویس نتیجه را مخدوش نکرده باشد. این ترتیب ساده به آزمایش منفی اعتبار می‌دهد.
در بررسی عملکرد، بار معمول سرویس را قبل و بعد از تغییر مقایسه کنید، اما عدد یک آزمایش کوتاه را به همه خوشه تعمیم ندهید. تعداد قواعد، روش اجرای سیاست و مسیر بسته می‌توانند در نتیجه اثر داشته باشند. اگر افزایش تأخیر مشاهده شد، ابتدا همان مسیر و همان بار را تکرار کنید و هم‌زمان سلامت گره و سرویس مقصد را ببینید. هدف این است که رابطه تغییر سیاست و رفتار شبکه با شاهد روشن شود. نتیجه خوب، مجموعه‌ای از مسیرهای ضروریِ فعال و مسیرهای غیرضروریِ بسته است که تیم بتواند دلیل هر کدام را توضیح دهد.
