چه زمانی سیاست بررسی می‌شود؟
Kyverno می‌تواند به‌عنوان کنترل‌گر پذیرش پویا در Kubernetes کار کند. API Server درخواست‌های مرتبط را به webhook می‌فرستد و موتور سیاست، قواعد منطبق را ارزیابی می‌کند. در کنار این مسیر، کنترل‌گرهای دیگری برای کارهای پس‌زمینه و تهیه گزارش منابع وجود دارند.
مستند معماری، مدیریت webhook، تمدید گواهی ارتباط و کنترل‌گرهای گزارش را مسئولیت‌های جدا معرفی می‌کند. بنابراین نبود گزارش تازه، ردشدن یک درخواست و اختلال گواهی webhook، سه نشانه‌اند که نباید بدون بررسی به یک علت نسبت داده شوند.
این مقاله به معماری و روش آزمون می‌پردازد، نه یک API ثابت برای همه نسخه‌ها. نوع سیاست و نحو پیکربندی باید با مستندات انتشار نصب‌شده تطبیق داده شود؛ نمونه یک نسخه قدیمی را بدون بررسی به خوشه جدید منتقل نکنید.
سیاست پیشنهادی در یک محیط فرضی
هدف را محدود انتخاب کنید؛ مثلاً وجود برچسب مالک روی Deploymentهای یک namespace آزمایشی. ابتدا مشخص کنید چه منابعی باید مشمول باشند و کدام منابع سیستمی خارج از دامنه‌اند. از همان ابتدا یک استثنای بدون تاریخ برای همه namespaceها نسازید.
سه نمونه آماده کنید: منبع صحیح، منبع فاقد برچسب و منبع خارج از دامنه. نتیجه هر سه باید با قرارداد شما تطبیق کند. سپس منبعی را که قبل از ایجاد سیاست وجود داشته بررسی کنید. مشاهده تخلف در گزارش منابع موجود، لزوماً به معنی اصلاح یا حذف خودکار آن نیست.
از مشاهده تا اعمال محدود
پیشنهاد تحریریه این است که ابتدا اثر سیاست را در حالت گزارش یا ممیزی متناسب با نسخه بسنجید و پس از شناخت مصرف‌کنندگان، اعمال محدود را امتحان کنید. ثبت خطای قابل فهم برای توسعه‌دهنده مهم است: ردشدن درخواست باید توضیح دهد چه چیزی باید اصلاح شود.
در یک آزمایش جداگانه، در دسترس نبودن webhook را شبیه‌سازی کنید. درباره رفتار API Server، timeout و دامنه تأثیر تصمیم بگیرید. این آزمون باید خارج از محیط کاربران انجام شود، زیرا مسیر پذیرش می‌تواند بر ایجاد یا تغییر منابع اثر بگذارد.
نگه‌داری سیاست
کنار هر سیاست، مالک، هدف و مثال‌های آزمون را نگه دارید. وقتی API یا برنامه تغییر می‌کند، آزمون‌ها باید نشان دهند قرارداد هنوز معتبر است. الگوی پیکربندی کوتاه و دارای آزمون معمولاً از مجموعه استثناهای بزرگ و بی‌مالک قابل نگه‌داری‌تر است. نمودار همراه، تصویر اصلی معماری پروژه Kyverno است.
سیاست را از یک نیاز قابل آزمون آغاز کنید
پیش از نوشتن هر قاعده، جمله‌ای بنویسید که کاربر و نتیجه آن مشخص باشد. برای نمونه، هر بار کاری تیم فروش باید برچسب مالک داشته باشد تا هشدارهای هزینه و خرابی به گروه درست برسند. این نیاز با ممنوع کردن همه منابع فاقد هر نوع برچسب فرق دارد. سپس نوع منابع، فضای نام و عملیات مورد نظر را تعیین کنید. سیاستی که دامنه آن روشن است، هم پیام خطای قابل فهم‌تری دارد و هم استثناهای کمتری تولید می‌کند.
نمونه‌های آزمون را پیش از تعمیم سیاست آماده کنید. یک منبع صحیح، یک منبع فاقد داده لازم، یک منبع با مقدار خالی و یک منبع خارج از دامنه بسازید. اگر قاعده روی قالب پاد در کنترل‌گرها اثر دارد، نمونه کنترل‌گر و پاد حاصل را نیز بررسی کنید. موفقیت تنها رد شدن یک فایل نادرست نیست؛ منبع درست باید همچنان قابل ایجاد و به‌روزرسانی باشد. در غیر این صورت، سیاست می‌تواند مسیر انتشار عادی تیم را بی‌دلیل مسدود کند.
پذیرش، گزارش و اصلاح مسئولیت‌های متفاوت دارند
مسیر پذیرش هنگام درخواست تغییر به رابط Kubernetes وارد عمل می‌شود. گزارش پس‌زمینه می‌تواند منابع موجود را بررسی کند، اما دیدن تخلف در گزارش به معنای حذف یا اصلاح آن منبع نیست. اگر هدف اصلاح خودکار است، باید قابلیت مناسب و دامنه اثر آن صریحاً طراحی شود. مخلوط کردن این مسئولیت‌ها باعث می‌شود تیم فکر کند محیط پاک شده، در حالی که تنها گزارشی از وضعیت ناسازگار تهیه شده است.
در یک محیط آزمایشی، ابتدا منبع ناسازگار را ایجاد کنید و سپس سیاست را اضافه کنید. رفتار منبع موجود را با درخواست ایجاد یک منبع تازه مقایسه کنید. بعد یک به‌روزرسانی بی‌ارتباط روی منبع قدیمی امتحان کنید و نتیجه را ثبت کنید. این آزمایش نشان می‌دهد سیاست در کدام نقطه مسیر کار توسعه‌دهنده را تغییر می‌دهد. در برنامه مهاجرت، منابع قدیمی را با مالک مشخص اصلاح کنید تا اعمال سیاست به مجموعه بزرگی از استثناهای دائمی وابسته نشود.
Mutation باید قابل پیش‌بینی باشد
اگر سیاست فیلدی را به منبع اضافه یا تغییر می‌دهد، کاربر باید بتواند نتیجه نهایی را بفهمد. برای مثال، اضافه کردن یک برچسب پیش‌فرض می‌تواند مفید باشد، اما بازنویسی بی‌خبر یک مقدار تجاری ممکن است رفتار برنامه را تغییر دهد. میان مقدار غایب و مقدار صریح تفاوت بگذارید و قرارداد سیاست را مستند کنید. همچنین چند سیاست که یک فیلد را تغییر می‌دهند ممکن است تعامل پیچیده‌ای ایجاد کنند؛ آزمون هر قاعده به صورت جدا کافی نیست.
پیکربندی تولیدشده توسط ابزار انتشار را با شیء پذیرفته‌شده در خوشه مقایسه کنید. اگر سامانه همگام‌سازی مدام تفاوت می‌بیند و آن را برمی‌گرداند، ممکن است تغییر خودکار سیاست با انتظار ابزار انتشار در تضاد باشد. این حلقه را با خاموش کردن تصادفی کنترل‌ها حل نکنید. مالکیت فیلد، ترتیب پردازش و روش مقایسه باید روشن شود. سیاست خوب باید بتواند در کنار جریان معمول توسعه کار کند، نه اینکه هر انتشار به توضیح دستی نیاز داشته باشد.
خرابی webhook بخشی از طراحی دسترس‌پذیری است
وب‌هوک در مسیر مدیریت منابع قرار دارد و تأخیر یا عدم دسترسی آن می‌تواند بر ایجاد و تغییر بارهای کاری اثر بگذارد. این مسئله با قطع ترافیک برنامه‌های موجود یکسان نیست، ولی در زمان بازیابی حادثه بسیار مهم است؛ اگر نیاز به ایجاد پاد تازه دارید، مسیر پذیرش باید رفتار مشخصی داشته باشد. درباره توقف یا ادامه درخواست هنگام شکست ارتباط تصمیم آگاهانه بگیرید. هر انتخاب میان خطر عبور درخواست بررسی‌نشده و خطر مسدود شدن عملیات مدیریت، مصالحه‌ای دارد.
در آزمایش غیرتولیدی، ارتباط با وب‌هوک را مختل کنید و نوع درخواست‌های متأثر، زمان انتظار و پیام خطا را ببینید. سپس بازیابی را بررسی کنید و مطمئن شوید تلاش‌های معوق به رفتار غیرمنتظره منجر نمی‌شوند. دامنه سیاست و انتخاب منابع سیستمی در این آزمایش اهمیت دارد. یک قاعده بسیار گسترده ممکن است روی مؤلفه‌هایی اثر بگذارد که برای بازیابی همان سامانه سیاست لازم هستند. مسیر اضطراری باید محدود، ثبت‌شده و از قبل تمرین‌شده باشد.
استثنا را به یک تصمیم قابل بازبینی تبدیل کنید
بعضی بارهای کاری به ویژگی‌هایی نیاز دارند که با سیاست عمومی ناسازگارند. استثنا باید منبع یا گروه مشخص، دلیل فنی، مالک و زمان بازبینی داشته باشد. افزودن یک فضای نام عمومی که هر کس بتواند در آن منبع بسازد، می‌تواند کل هدف سیاست را دور بزند. بنابراین مجوز ایجاد یا تغییر استثنا و مجوز تغییر برچسب‌های تعیین‌کننده دامنه نیز بخشی از مدل امنیتی هستند. تنها متن قاعده را بررسی نکنید؛ مسیر ورود به دامنه استثنا را هم ببینید.
برای یک استثنای واقعی، آزمون کنید که بار کاری مجاز پذیرفته می‌شود و بار کاری مشابه خارج از محدوده همچنان رد می‌شود. بعد از رفع نیاز، استثنا را حذف و آزمون‌ها را دوباره اجرا کنید. اگر تعداد استثناها پیوسته افزایش می‌یابد، شاید سیاست با نیاز محیط هماهنگ نیست یا برنامه مهاجرت کافی وجود ندارد. شمارش استثنا بدون تحلیل علت آنها شاخص کاملی نیست، اما روند آن می‌تواند نشانه خوبی برای بازنگری طراحی باشد.
سیاست تصاویر به زنجیره اعتماد وابسته است
وقتی قاعده‌ای درباره تصویر کانتینر می‌نویسید، مشخص کنید چه چیزی را می‌خواهید کنترل کنید: نام مخزن، شناسه محتوایی، امضاکننده یا شواهد ساخت. این کنترل‌ها معادل نیستند. قرار گرفتن تصویر در یک مخزن مورد اعتماد به تنهایی نمی‌گوید چه کدی داخل آن است، و امضای معتبر بدون هویت مجاز نیز الزاماً سیاست سازمان را برآورده نمی‌کند. قرارداد پذیرش باید دقیق باشد تا تیم انتشار بداند چه مدرکی لازم دارد.
خطای دسترسی به مخزن یا سامانه دریافت اطلاعات تصویر را نیز در آزمون بگنجانید. اگر ارزیابی سیاست به وابستگی بیرونی احتیاج دارد، سلامت و تأخیر آن وابستگی بخشی از مسیر پذیرش می‌شود. کش ممکن است به عملکرد کمک کند، اما باید بدانید داده تا چه زمانی معتبر فرض می‌شود. جزئیات گزینه‌ها و قابلیت‌ها به نسخه وابسته‌اند؛ از مستندات همان انتشار و نمونه‌های آزموده‌شده استفاده کنید و نتیجه یک نمونه اینترنتی را تضمین عمومی رفتار ندانید.
گزارش برای توسعه‌دهنده و عملیات
پیام رد درخواست باید نام مسئله و راه اصلاح را بیان کند. جمله‌ای مثل «درخواست نامعتبر است» توسعه‌دهنده را به حدس زدن مجبور می‌کند، در حالی که اشاره به برچسب یا فیلد لازم قابل اقدام است. در گزارش مدیریتی، تعداد تخلف را با تعداد منابع مشمول و عمر تخلف همراه کنید. ده تخلف تازه با ده تخلف قدیمی بدون مالک وضعیت یکسانی نیستند. این زمینه کمک می‌کند اصلاح‌ها بر اساس اثر واقعی اولویت‌بندی شوند.
در پایان هر تغییر سیاست، نسخه قاعده، نمونه‌های آزمون و نتیجه محیط محدود را نگه دارید. هنگام ارتقای Kubernetes یا Kyverno، همین نمونه‌ها باید دوباره اجرا شوند تا تغییر نحو یا رفتار آشکار شود. اگر سیاست حذف یا غیرفعال می‌شود، علت و اثر آن را ثبت کنید و کنترل جایگزین را مشخص سازید. هدف نهایی داشتن مجموعه‌ای از فایل‌های سیاست نیست؛ هدف این است که درخواست مجاز قابل پیش‌بینی پذیرفته شود، درخواست ناسازگار توضیح روشن بگیرد و محیط موجود مسیر اصلاح قابل اجرا داشته باشد.
آزمون تغییر مجاز در کنار آزمون رد درخواست
یک آزمون رگرسیون مفید، به‌روزرسانی تصویر یک برنامه سالم بدون تغییر سایر فیلدهاست. اگر سیاست مربوط به برچسب مالک است، چنین انتشار عادی باید با قرارداد مورد انتظار سازگار بماند. سپس همان درخواست را با حذف برچسب لازم اجرا کنید و پیام رد را بررسی کنید. این جفت آزمون نشان می‌دهد کنترل دقیقاً به نیاز اعلام‌شده مربوط است و به طور اتفاقی همه تغییرها را مسدود نمی‌کند.
برای منابعی که به صورت خودکار توسط کنترل‌گرها تولید می‌شوند، منبع اولیه و شیء حاصل را جدا بررسی کنید. ممکن است توسعه‌دهنده فقط قالب اصلی را ویرایش کند و هرگز شیء نهایی را مستقیم نسازد. پیام سیاست باید در جایی قابل مشاهده باشد که او بتواند علت شکست را پیدا کند. در غیر این صورت، وضعیت انتشار ظاهراً معلق می‌ماند و تیم به اشتباه سراغ مشکل زمان‌بندی یا شبکه می‌رود.
این آزمون‌ها را با حسابی انجام دهید که سطح دسترسی معمول توسعه‌دهنده را دارد. اجرای همه بررسی‌ها با حساب مدیر ممکن است استثنا یا مسیر ویژه‌ای را فعال کند و رفتار واقعی کاربران را پنهان سازد. ثبت هویت آزمایش، دامنه سیاست و نسخه منبع، نتیجه را برای بازبینی بعدی قابل اتکا می‌کند.
