نقش منابع را با هم یکی نگیریم
در cert-manager، منبع Certificate وضعیت مطلوب گواهی را توصیف می‌کند و به صادرکننده مربوط ارجاع می‌دهد. Issuer معمولاً در محدوده namespace تعریف می‌شود، درحالی‌که ClusterIssuer در سطح خوشه قابل ارجاع است. گواهی و کلید صادرشده در Secret هدف نگه‌داری می‌شوند و برنامه یا کنترل‌گر مصرف‌کننده باید از آن‌ها استفاده کند.
مستندات Certificate درباره چرخه صدور و تمدید توضیح می‌دهند. جزئیات زمان‌بندی، چرخش کلید و انتخاب صادرکننده باید با نسخه و تنظیمات واقعی تطبیق داده شود. یک مقدار پیش‌فرض در یک آموزش، قرارداد همیشگی همه نسخه‌ها نیست.
صدور، نگه‌داری و ارائه سه مرحله‌اند
ممکن است صادرکننده گواهی تازه را بسازد و Secret به‌روز شود، ولی برنامه هنوز نسخه قبلی را در حافظه نگه داشته باشد. بنابراین رویداد موفق cert-manager را باید کنار رفتار مصرف‌کننده دید. همچنین مجوز خواندن Secret، بخشی از مرز امنیتی نگه‌داری کلید خصوصی است.
تصویر این مقاله، کارت رسمی پروژه از مستندات آن است؛ تصویر نتیجه صدور گواهی در سامانه IROSG یا یک اسکرین‌شات آزمایش واقعی نیست.
سناریوی پیشنهادی برای یک محیط آزمایشی
یک نام سرویس غیرعملیاتی و صادرکننده مناسب محیط آزمایش انتخاب کنید. پیش از صدور، نام‌های مورد انتظار، مالک گواهی و محل مصرف را روی کاغذ ثبت کنید. بعد از صدور، یک کلاینت مستقل باید نام و زنجیره گواهی ارائه‌شده توسط سرویس را بررسی کند.
اکنون تمدید یا جایگزینی را در همان محیط امتحان کنید. شواهد را از دو طرف جمع کنید: تغییر منبع و Secret از یک سو، و تغییر گواهی ارائه‌شده به کلاینت از سوی دیگر. فاصله این دو رویداد می‌تواند ضعف مسیر بارگذاری مجدد را نشان دهد.
آزمون‌های منفی ضروری‌اند
یک ارجاع نادرست به صادرکننده، نبود مجوز یا قطع دسترسی به سرویس صدور را جداگانه آزمایش کنید. هدف، شناخت نشانه شکست و مسیر هشدار است؛ نه تولید اختلال در گواهی واقعی کاربران. معلوم کنید پس از رفع علت، روند صدور خودکار ادامه پیدا می‌کند یا اقدام دیگری لازم است.
مرز مسئولیت
cert-manager به‌جای شما درباره اینکه چه هویتی اجازه کدام عملیات را دارد تصمیم نمی‌گیرد. صدور گواهی، کنترل مجوز برنامه و حفاظت از کلید سه مسئولیت مرتبط اما متفاوت‌اند. پیشنهاد تحریریه ثبت مالک گواهی، مالک مصرف‌کننده و مسئول پاسخ به نزدیک‌شدن انقضا در یک فهرست مشترک است.
گواهی را از نام و مصرف‌کننده شروع کنیم
پیش از انتخاب صادرکننده، فهرست نام‌هایی را بنویسید که کلاینت واقعاً به آن‌ها متصل می‌شود. نام داخل خوشه، نام عمومی و نام استفاده‌شده توسط سامانه پایش ممکن است متفاوت باشند. گواهی باید با هویتی که کلاینت بررسی می‌کند هماهنگ باشد؛ قرار دادن نام‌های اضافی بدون نیاز، دامنه اعتبار را بی‌دلیل گسترش می‌دهد. سپس تعیین کنید گواهی در کدام Secret ذخیره می‌شود و کدام برنامه یا کنترل‌گر آن را می‌خواند. همین فهرست ساده از ساخت گواهی درست در محل اشتباه جلوگیری می‌کند.
برای سرویس عمومی، مسیر DNS و لبه ارائه TLS نیز بخشی از مسئله است. ممکن است درخواست کاربر ابتدا به CDN یا بارمتوازن‌کننده برسد و آن جزء گواهی خودش را ارائه کند. در چنین معماری‌ای، گواهی داخل خوشه لزوماً همان گواهی دیده‌شده توسط مرورگر نیست. نقشه را از کلاینت تا برنامه رسم کنید و هر نقطه پایان TLS را جدا بنویسید. هنگام عیب‌یابی انقضا، این کار مانع تعویض مکرر Secretی می‌شود که اصلاً در مسیر کاربر مصرف نمی‌شود.
صادرکننده، درخواست و خروجی را جدا ببینیم
Certificate خواسته‌ای پایدار است، در حالی که عملیات صدور می‌تواند منابع و وضعیت‌های میانی داشته باشد. برای تشخیص شکست، از وضعیت Certificate به درخواست مربوط و سپس صادرکننده حرکت کنید. اگر صادرکننده آماده نیست، مسئله نام دامنه برنامه لزوماً نقطه شروع مناسبی نیست. اگر درخواست صادر شده ولی Secret هدف هنوز مشکل دارد، باید مرحله ذخیره یا مجوز را بررسی کرد. این ترتیب مشاهده به جای حذف همه منابع، شواهد علت را نگه می‌دارد و از درخواست‌های تکراری بی‌فایده جلوگیری می‌کند.
در استفاده از ACME، اثبات کنترل نام دامنه مرحله مستقلی است. روش مبتنی بر HTTP به دسترسی مسیر چالش از بیرون وابسته است و روش مبتنی بر DNS به ثبت و مشاهده رکورد مناسب. انتخاب روش باید با معماری واقعی هماهنگ باشد. اگر سرویس فقط خصوصی است، باز کردن بی‌برنامه ورودی عمومی برای حل چالش می‌تواند تصمیم نامناسبی باشد. اگر از DNS استفاده می‌شود، اعتبار API باید تا حد ممکن به محدوده لازم محدود شود و در اختیار تمام برنامه‌های خوشه قرار نگیرد.
چرا محیط آزمایشی صدور ارزش دارد؟
پیش از صدور برای نام واقعی پرترافیک، فرایند را با محیط مناسب آزمایش کنید. هدف بررسی مجوز، مسیر شبکه، ثبت رکورد و تولید Secret است. گواهی آزمایشی ممکن است برای کلاینت عمومی مورد اعتماد نباشد و این شکست اعتماد نباید با شکست صدور اشتباه شود. در گزارش، مشخص کنید کدام مرحله انتظار موفقیت داشته است. اگر آزمایش فقط برای بررسی چالش طراحی شده، لازم نیست نتیجه آن را گواهی قابل استفاده کاربران تلقی کنید.
برای آزمون منفی، یک نام یا ارجاع نادرست را در محیط جدا انتخاب کنید و پیام وضعیت را بخوانید. سپس علت را اصلاح کنید و زمان رسیدن به وضعیت سالم را ثبت کنید. حذف و ساخت مکرر درخواست‌ها پیش از فهم علت ممکن است محدودیت‌های صادرکننده را درگیر کند و نشانه‌ها را مخدوش سازد. بهتر است هر تغییر یک فرضیه داشته باشد: آیا رکورد قابل مشاهده نیست، آیا اعتبار دسترسی رد می‌شود، یا آیا مسیر چالش به برنامه دیگری هدایت می‌شود؟ پاسخ این سؤال‌ها اقدام بعدی را تعیین می‌کند.
Secret به‌روز شده، اما برنامه چه می‌بیند؟
پس از صدور موفق، سریال و زمان اعتبار گواهی ذخیره‌شده را با گواهی ارائه‌شده از نقطه اتصال کاربر مقایسه کنید. اگر این دو متفاوت‌اند، مسیر مصرف را بررسی کنید. بعضی برنامه‌ها فایل را دوباره می‌خوانند و بعضی به بارگذاری مجدد یا راه‌اندازی نیاز دارند. نحوه اتصال Secret به کانتینر و الگوی خواندن برنامه نیز اهمیت دارد. صرف تغییر فایل در خوشه اثبات نمی‌کند فرایند کلید و گواهی تازه را در حافظه جایگزین کرده است.
در خوشه چندنمونه‌ای، همه نمونه‌ها را در نظر بگیرید. ممکن است فقط بخشی از آن‌ها گواهی تازه را ارائه کنند و خطا برای کاربران متناوب باشد. چند اتصال مستقل با ثبت مقصد و سریال بسازید و رفتار را مقایسه کنید. اگر بارمتوازن‌کننده نشست را نگه می‌دارد، یک کلاینت ممکن است همیشه به نمونه سالم برسد و مشکل را نبیند. پایش بیرونی باید به اندازه کافی متنوع باشد تا وضعیت یک نمونه قدیمی پشت میانگین موفقیت پنهان نشود.
تمدید را پیش از نزدیک شدن انقضا تمرین کنیم
تمدید موفق به باقی ماندن دسترسی صادرکننده و مسیر اعتبارسنجی وابسته است. تغییری که امروز ورودی HTTP یا مجوز DNS را حذف می‌کند شاید گواهی فعلی را خراب نکند، اما در زمان تمدید آشکار شود. پس بعد از تغییر شبکه یا حساب صادرکننده، تنها باز شدن صفحه وب را بررسی نکنید. امکان اجرای دوباره چرخه صدور باید در محیط مناسب آزمایش شود. این نگاه تفاوت میان سلامت لحظه‌ای و قابلیت ادامه کار در آینده را روشن می‌کند.
هشدار انقضا باید زمان کافی برای تشخیص و اصلاح داشته باشد و به مالک مشخص برسد. هشدار صرفاً بر اساس Secret کافی نیست اگر گواهی دیگری در لبه ارائه می‌شود. دو مشاهده مکمل مفیدند: وضعیت منابع صدور داخل خوشه و اعتبار گواهی مشاهده‌شده از بیرون. فاصله میان این دو می‌تواند تأخیر مصرف، تنظیم اشتباه لبه یا مسیر DNS متفاوت را آشکار کند. در مستند حادثه، نام مصرف‌کننده و محل پایان TLS باید کنار نام Certificate ثبت شود.
کلید خصوصی، پشتیبان و مرز اختیار
Secret در Kubernetes یک ظرف برای داده حساس است و دسترسی به آن باید محدود باشد. هر حسابی که بتواند کلید خصوصی را بخواند می‌تواند اثر امنیتی متفاوتی از حساب صرفاً مشاهده‌کننده وضعیت داشته باشد. مجوزهای خواندن Secret، ایجاد Pod و اجرای فرمان داخل Pod را با هم بررسی کنید؛ بعضی مسیرهای غیرمستقیم نیز به داده منتهی می‌شوند. این بررسی باید متناسب با محیط انجام شود و به نام‌گذاری Secret به عنوان «محرمانه» اکتفا نکند.
در بازیابی خوشه، علاوه بر منابع Certificate به اعتبار صادرکننده، کلیدهای لازم و رفتار مصرف‌کنندگان توجه کنید. بازگرداندن یک Secret قدیمی ممکن است گواهی منقضی یا کلید دیگر را برگرداند. پس از بازیابی، دوباره گواهی ارائه‌شده را بررسی کنید و انتظار نداشته باشید سبز بودن منبع قدیمی تمام وضعیت بیرونی را ثابت کند. برای مطالعه جزئیات مسیر تشخیص، راهنمای عیب‌یابی رسمی cert-manager نقطه شروع مناسبی است؛ مثال‌های این بخش سناریوهای آموزشی برای طراحی آزمون هستند و نتیجه آزمایش واقعی IROSG محسوب نمی‌شوند.
تشخیص خطای اعتماد از خطای نام
کلاینت ممکن است گواهی را دریافت کند ولی به صادرکننده آن اعتماد نداشته باشد. این وضعیت با نام نادرست در گواهی یا پایان زمان اعتبار تفاوت دارد. در گزارش، متن دقیق خطای کلاینت و زنجیره ارائه‌شده را ثبت کنید. برای سرویس داخلی با مرجع خصوصی، توزیع اعتماد به کلاینت‌ها یک پروژه مستقل است؛ صدور موفق گواهی به تنهایی باعث اعتماد سیستم‌عامل‌ها و زبان‌های برنامه‌نویسی مختلف نمی‌شود. هر مصرف‌کننده ممکن است مخزن اعتماد یا روش بارگذاری متفاوتی داشته باشد.
نمونه آموزشی مفید این است که یک کلاینت دارای اعتماد درست و یک کلاینت بدون آن را به سرویس یکسان وصل کنید. سرور در هر دو مورد گواهی یکسانی ارائه می‌کند، اما نتیجه اعتبارسنجی فرق دارد. سپس نام اتصال را تغییر دهید تا خطای نام را نیز ببینید. با این آزمایش، تیم می‌آموزد هر پیام TLS با تعویض Secret حل نمی‌شود. گاهی اصلاح باید در مخزن اعتماد کلاینت یا نامی که برنامه برای اتصال استفاده می‌کند انجام شود.
در تغییر مرجع صدور، دوره هم‌پوشانی اعتماد را طراحی کنید. اگر گواهی تازه پیش از آماده شدن کلاینت‌ها ارائه شود، سرویس با وجود گواهی معتبر قطع می‌شود. ترتیب تغییر می‌تواند شامل توزیع اعتماد تازه، بررسی مصرف‌کنندگان، صدور و ارائه گواهی جدید و سپس حذف اعتماد قدیمی باشد. جزئیات باید با سیاست سازمان و نرم‌افزار واقعی تطبیق یابد. ثبت این ترتیب در برنامه تغییر از اقدام هم‌زمان و غیرقابل تشخیص روی صادرکننده و مصرف‌کننده جلوگیری می‌کند.
