در یک سامانه سفارش، سرویس پرداخت درخواست تأیید را از سرویس سفارش دریافت می‌کند. هر دو روی Kubernetes اجرا می‌شوند و آدرس Podها با جایگزینی نمونه‌ها تغییر می‌کند. تیم می‌خواهد مسیر ارتباط رمز شود و مقصد بتواند هویت فرستنده را ارزیابی کند. فهرست ثابت نشانی‌های IP با این چرخه عمر سازگار نیست. Linkerd هویت بار کاری را به ServiceAccount مرتبط می‌کند و پراکسی کنار برنامه می‌تواند اتصال به پراکسی مقصد را با گواهی مناسب برقرار کند. برای فهم محدوده این حفاظت باید دید درخواست از برنامه تا مقصد از کدام اجزا می‌گذرد و کدام بخش واقعاً عضو شبکه مش است.
مسیر داده از دو پراکسی عبور می‌کند
در استقرار مرسوم با تزریق پراکسی، هر Pod مش‌شده یک پراکسی Linkerd دارد. ترافیک مشمول قواعد هدایت به پراکسی محلی می‌رسد و پراکسی درباره اتصال به مقصد تصمیم می‌گیرد. در سمت دیگر، پراکسی ورودی ارتباط را دریافت و درخواست را به برنامه پشت خود منتقل می‌کند. بنابراین رمزگذاری میان دو پراکسی انجام می‌شود. برنامه می‌تواند همچنان روی رابط محلی خود با قرارداد داخلی مورد انتظار کار کند. اگر برنامه از قبل TLS ویژه خود را اجرا می‌کند، تحلیل پروتکل و قابلیت مشاهده باید مطابق همان الگو بررسی شود. وجود دو لایه رمزگذاری ممکن است دید پراکسی به محتوای درخواست را محدود کند.
صفحه کنترل برای کشف مقصد، هویت و سیاست نقش دارد، ولی درخواست هر کاربر برای عبور از شبکه مجبور نیست از یک سرور مرکزی صفحه کنترل بگذرد. مسیر واقعی داده در پراکسی‌های کنار بارهای کاری قرار دارد. این تفکیک برای عیب‌یابی مهم است. خطای صدور گواهی در صفحه کنترل می‌تواند توان ایجاد ارتباط‌های معتبر آینده را تحت تأثیر قرار دهد، در حالی که کندی برنامه مقصد در مسیر داده دیده می‌شود. اگر همه خطاهای شبکه با بررسی مصرف پردازنده صفحه کنترل آغاز شوند، بخش مهمی از شواهد در پراکسی یا خود برنامه نادیده می‌ماند.
صدور نخستین گواهی چگونه انجام می‌شود؟
پراکسی هنگام راه‌اندازی ماده کلیدی لازم را محلی ایجاد می‌کند و برای دریافت گواهی با مؤلفه identity ارتباط می‌گیرد. زنجیره اعتماد در اختیار پراکسی قرار دارد تا بتواند سمت مقابل این مرحله را اعتبارسنجی کند. درخواست صدور با هویت ServiceAccount مربوط به Pod پیوند دارد و توکن مناسب به سامانه هویت امکان بررسی آن ادعا را می‌دهد. پس از موفقیت، پراکسی گواهی کوتاه‌عمر برای همان هویت دریافت می‌کند. این گردش کار نیاز به توزیع یک کلید خصوصی مشترک بین تمام Podهای یک سرویس را کاهش می‌دهد. هر نمونه می‌تواند ماده خصوصی خود را در محدوده محلی نگه دارد.
اگر Pod تازه اجرا شده ولی گواهی دریافت نکرده است، مسیر بررسی از هویت همان Pod آغاز می‌شود. ServiceAccount تنظیم‌شده، امکان دسترسی به مؤلفه identity، صحت زمان و اعتبار زنجیره صدور را بررسی کنید. یک برنامه سالم می‌تواند در این مرحله هنوز آماده سرویس‌دهی امن نباشد. از سوی دیگر، موفقیت صدور برای یک Pod نشان نمی‌دهد همه namespaceها یا حساب‌های سرویس شرایط یکسان دارند. آزمون باید یک نمونه از هر الگوی پیکربندی مهم را شامل شود. ثبت شناسه namespace، حساب سرویس و زمان رخداد به جدا کردن مشکل یک برنامه از خرابی عمومی صدور کمک می‌کند.
هویت منطقی و مجوز درخواست
دو Pod که با یک ServiceAccount در یک namespace اجرا می‌شوند معمولاً از دید الگوی هویت مش، نماینده یک هویت کاری هستند. این رفتار برای نسخه‌های متعدد یک سرویس مناسب است. اما اگر چند برنامه با وظایف متفاوت از یک حساب مشترک استفاده کنند، سیاستی که بر همان هویت تکیه دارد نمی‌تواند آن‌ها را به دقت از هم تفکیک کند. در مثال سفارش، انتخاب حساب جداگانه برای سرویس سفارش و سرویس گزارش‌گیری معنا دارد. سپس مقصد می‌تواند مجوز ارتباط را بر اساس نقش واقعی بار کاری تعریف کند. این انتخاب باید با مسئولیت برنامه و نیاز دسترسی هماهنگ باشد.
تأیید هویت فرستنده مرحله‌ای جدا از تصمیم درباره اجازه انجام عملیات است. پراکسی ممکن است ارتباط معتبر میان دو هویت را برقرار کند ولی برنامه همچنان باید مجوز کاربر نهایی برای دیدن سفارش را بررسی کند. هویت سرویس سفارش اثبات نمی‌کند هر کاربر پشت آن حق بازپرداخت دارد. برای طراحی کامل، سه موضوع را جدا ثبت کنید. کدام بار کاری به مقصد وصل شده، آن بار کاری اجازه استفاده از کدام مسیر را دارد و کاربر نهایی اجازه انجام کدام تغییر را دارد. خطاهای این سه لایه باید نشانه‌های قابل تشخیص داشته باشند تا پشتیبانی بتواند پاسخ درست بدهد.
پوشش واقعی رمزگذاری را پیدا کنیم
رمزگذاری خودکار زمانی معنا پیدا می‌کند که ارتباط میان پراکسی‌های واجد شرایط برقرار شود. ترافیک به یک مقصد بیرونی، یک Pod بدون پراکسی یا مسیری که از هدایت معاف شده می‌تواند رفتار متفاوتی داشته باشد. در گزارش پوشش امنیتی باید دامنه دقیق ذکر شود. درصد Podهای دارای پراکسی، درصد اتصال‌های مش‌شده و درصد درخواست‌های مجاز سه عدد متفاوت هستند. برای نمونه ممکن است هر دو Deployment تزریق داشته باشند اما یک Job قدیمی همچنان مستقیم به همان سرویس متصل شود. مشاهده فقط دو نمونه اصلی باعث می‌شود مسیر استثنا در ارزیابی جا بماند.
برای آزمون، یک درخواست میان دو عضو مش ارسال کنید و شواهد هویت دو سمت را از داده‌های پراکسی ببینید. سپس از یک کلاینت خارج از مش همان مسیر را امتحان کنید و نتیجه را با سیاست مورد انتظار مقایسه کنید. اگر هدف ردکردن فرستنده‌های تأییدنشده است، صرف مشاهده ارتباط رمز روی مسیر مثبت این شرط را ثابت نمی‌کند. آزمون منفی باید از مسیر کنترل‌شده انجام شود و پاسخ، نام مقصد و زمان ثبت شود. اجازه پیش‌فرض محیط و قواعد اختصاصی آن سرویس در نتیجه اثر دارند. تغییر سیاست روی یک مسیر کوچک، بررسی نتیجه را آسان‌تر می‌کند.
ریشه اعتماد، صادرکننده و گواهی بار کاری
چرخه عمر گواهی بار کاری با چرخه عمر گواهی صادرکننده و ریشه اعتماد یکسان نیست. پراکسی گواهی کوتاه‌عمر خود را تازه می‌کند، اما این گردش خودکار مسئولیت نگه‌داری اعتبار صادرکننده را از تیم حذف نمی‌کند. پایان اعتبار یک صادرکننده می‌تواند ایجاد یا تمدید گواهی‌های تازه را دچار مشکل کند. سنجش سلامت باید تاریخ‌های مربوط به هر لایه را جدا ببیند. بررسی فقط یک اتصال فعال می‌تواند خطر نزدیک‌شدن تاریخ انقضا را پنهان کند، زیرا آن اتصال شاید هنوز با گواهی‌ای که پیش‌تر صادر شده کار کند. ساعت نادرست میزبان نیز می‌تواند خطای ظاهراً مشابه بسازد.
تغییر ریشه اعتماد به توزیع درست اطلاعات اعتماد در میان پراکسی‌ها نیاز دارد. اگر بخشی از بارهای کاری فقط ریشه قبلی و بخش دیگر فقط ریشه بعدی را بشناسند، ارتباط میان آن‌ها ممکن است شکست بخورد. برنامه تغییر باید مرحله هم‌پوشانی، شیوه توزیع، شواهد پذیرش گواهی‌های جدید و زمان کنار گذاشتن زنجیره قبلی را مشخص کند. جزئیات فرمان‌ها به نسخه و روش نصب وابسته است. یک محیط آزمایشی با دو سرویس واقعی می‌تواند این گذار را پیش از اجرای گسترده نشان دهد. برنامه بازگشت نیز باید با وضعیت گواهی‌هایی که در دوره گذار صادر شده‌اند سازگار باشد.
هزینه پراکسی و رفتاری که برنامه می‌بیند
قرار گرفتن پراکسی در مسیر، مصرف پردازنده و حافظه و بخشی از تأخیر را به هر Pod اضافه می‌کند. اندازه این هزینه به تعداد اتصال، نرخ درخواست، اندازه داده و ویژگی پروتکل وابسته است. یک بنچمارک ساده با پاسخ کوچک ممکن است نماینده انتقال فایل یا جریان‌های طولانی نباشد. مقایسه را با بار یکسان، تعداد نمونه یکسان و اندازه‌گیری صدک‌های تأخیر انجام دهید. میانگین پایین می‌تواند افزایش تأخیر درخواست‌های کندتر را پنهان کند. همچنین منابع پراکسی باید در محاسبه ظرفیت گره و تصمیم‌های مقیاس‌دهی لحاظ شوند تا برنامه و پراکسی برای بودجه‌ای نامناسب رقابت نکنند.
زمان‌بندی شروع و پایان Pod نیز بر تجربه کاربر اثر دارد. وقتی نمونه تازه آماده می‌شود، دریافت هویت و آمادگی پراکسی بخشی از مسیر خدمت‌رسانی است. هنگام خاتمه نمونه، اتصال‌های در جریان باید فرصت مناسب داشته باشند. اگر برنامه زودتر از پراکسی یا بدون هماهنگی متوقف شود، خطا ممکن است فقط هنگام انتشار نسخه جدید دیده شود. برای آشکار کردن این مسئله، آزمون را در حال اجرای ترافیک پیوسته انجام دهید و همزمان یک انتشار تدریجی اجرا کنید. زمان خطاها را با رخدادهای ایجاد و خاتمه Pod تطبیق دهید. طبیعت متناوب خطا نباید باعث شود آن را صرفاً به شبکه نسبت دهند.
وقتی سرویس سفارش به پرداخت نمی‌رسد
از مبدأ شروع کنید و نام مقصد، پورت و نمونه انتخاب‌شده را ثبت کنید. سپس بررسی کنید هر دو سمت پراکسی دارند و مسیر مورد نظر مشمول هدایت است. اگر پراکسی مقصد را پیدا نمی‌کند، اطلاعات کشف سرویس و وضعیت endpointها را ببینید. اگر ارتباط TLS شکست می‌خورد، هویت مورد انتظار، زمان، زنجیره اعتماد و اعتبار گواهی اهمیت بیشتری دارند. اگر TLS موفق است ولی درخواست رد می‌شود، تصمیم سیاست و مجوز برنامه را بررسی کنید. این ترتیب میان خطاهای مسیریابی، اعتماد و اجازه تفاوت می‌گذارد و از تعویض بی‌دلیل گواهی در هر خطای دسترسی جلوگیری می‌کند.
پس از رفع مشکل، مسیر مثبت را با همان هویت اولیه تکرار کنید و یک مسیر غیرمجاز را نیز بررسی کنید. ثبت هر دو نتیجه کمک می‌کند اصلاح دسترسی ناخواسته ایجاد نکرده باشد. برای پایش روزمره، وضعیت صدور و تمدید، شمار ارتباط‌های دارای هویت، خطاهای سیاست و تجربه درخواست نهایی را کنار هم بگذارید. تیم برنامه با زمان پاسخ و نتیجه تجاری کار می‌کند و تیم زیرساخت با صحت مسیر و گواهی. پیوند این شواهد از طریق شناسه سرویس، namespace و زمان درخواست امکان می‌دهد هر تیم همان بخش از ارتباط را بررسی کند که مسئول آن است.
در پرونده پرداخت، نمونه آزمایش را طوری انتخاب کنید که به ایجاد تراکنش مالی واقعی نیاز نداشته باشد. یک مسیر خواندنی با همان سیاست ورودی و همان ServiceAccount می‌تواند تغییر هویت را آشکار کند. نتیجه را برای هر دو نسخه سرویس که هنگام انتشار همزمان فعال‌اند ثبت کنید. اگر فقط نمونه‌های تازه شکست می‌خورند، تفاوت توکن، زمان آغاز و دریافت نخستین گواهی سرنخ‌های مشخصی به دست می‌دهد. اگر فقط نمونه‌های قدیمی مشکل دارند، وضعیت تمدید و تغییر زنجیره اعتماد ارزش بررسی دارد. این تفکیک زمانی، خطای هویت سرویس را از ایرادی که به یک نسل خاص از Podها محدود است جدا می‌کند.
