یک سرور آزمایشگاه، سه نقش اعتماد، یک دامنه خرابی

همه چیز کار می‌کند تا وقتی اجراکننده ساخت به همان سوکت میزبان نیاز پیدا می‌کند که مهمان VPN استفاده می‌کند، و آن وقت هیچ‌کس نمی‌تواند توضیح دهد چرا یک کار می‌تواند کلیدهای دروازه را بخواند. همه چیز روی یک ماشین نصب شد چون جا می‌شد، و به هر مهمان دسترسی گسترده داده شد چون این سریع‌ترین راه کار کردن آن بود. نتیجه میزبانی است که مرز اعتمادش کابل برق است. جدا کردن نقش‌ها کاری کمتر از آن چیزی است که به نظر می‌رسد، و با نام گذاشتن روی آن‌ها شروع می‌شود.

سه نقشی که اکنون همه چیز را شریک‌اند

ورودی VPN، مجموعه‌ای از سرویس‌های خصوصی و یک اجراکننده ساخت چیزهای متفاوتی می‌خواهند. اولی به یک پورت عمومی و شبکه‌ای باریک در سمت خصوصی نیاز دارد. دومی به ذخیره‌سازی پایدار و رازهای برنامه نیاز دارد. سومی کدی را اجرا می‌کند که شخص دیگری نوشته است.

دادن همان دسترسی به هر سه چیز همان است که علامت را گیج‌کننده می‌کند، چون آن وقت هر یک از آن‌ها می‌تواند روی دیگران اثر بگذارد. کار ساختی که به سوکت هایپروایزر می‌رسد کاری است که می‌تواند VPN را متوقف کند. مهمان سرویسی که مسیری به شبکه مدیریت دارد می‌تواند پیکربندی سوئیچ را تغییر دهد. اختیارات مشکل است، و فهرست پردازه‌ها فقط جایی است که خود را نشان می‌دهد. نامیدن نقش‌ها در ابتدا به هر اختیار جایی برای زندگی می‌دهد.

طرح زیر نقطه شروعی برای این تفکیک است، نه وعده دسترس‌پذیری بالا. آن را فرضیه‌ای برای بررسی بدانید، نه طراحی نهایی.

سه نقش را جدا کنید، نه سه پردازه

سه مهمان روی یک میزبان سه مجموعه اختیار و سه موقعیت شبکه می‌دهند. آن‌ها سه دامنه خرابی نمی‌دهند، و طراحی باید این را بلند بگوید.

تفکیک تنها وقتی کمک می‌کند که نفوذ در یک مهمان به طور خودکار به دیگران اختیار ندهد، و این تنظیمی در هایپروایزر است نه یک قرارداد نام‌گذاری. نامیدن یک ماشین مجازی به‌عنوان دروازه مانع رسیدن مهمان دیگر به میزبان نمی‌شود. پیکربندی سوئیچ مجازی را بخوانید نه نام میزبان را، و سپس تأیید کنید که هر مهمان جایی است که فکر می‌کنید.

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

توپولوژی را بنویسید و سپس آن را با ابزارهایی که مالک آن‌اند بررسی کنید. مهمانی که روی پل اشتباه ظاهر می‌شود یک یافته است نه یک جزئیات. شبکه را پیش از تغییر هر پیکربندی سرویس درست کنید.

بگذارید مهمان VPN فقط درهایی را باز کند که مالک آن‌هاست

پورت تونل را روی مسیریاب منتشر کنید و هیچ چیز دیگر. پورت‌های مدیریت مهمان به مسیری مدیریتی تعلق دارند، نه به اینترنت، و رابط خود هایپروایزر هم به همان‌جا تعلق دارد.

شبکه سمت خصوصی باید به سرویس‌هایی برسد که کاربران دور نیاز دارند و همان‌جا بایستد. احراز هویت برنامه روشن می‌ماند، چون تونل انتقال است و نه ورود. جدول مسیریابی مهمان VPN را به اندازه‌ای کوچک نگه دارید که در یک جمله توصیف شود. اگر نمی‌توانید آن را این‌قدر ساده توصیف کنید، مرز پیش‌تر محو شده است.

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

هر چیزی که روی میزبان گوش می‌دهد و برای مدیریت لازم نیست نباید اصلاً گوش بدهد. این شامل API هایپروایزر است که نگه داشتن آن روی یک رابط عمومی آسان است.

کارهای ساخت به نوع دیگری از مرز نیاز دارند

کار CI فرمان‌هایی را اجرا می‌کند که مخزن کنترلشان می‌کند، پس اعتمادش به این بستگی دارد که چه کسی می‌تواند کد بفرستد. اجراکننده پوسته آن فرمان‌ها را به‌عنوان کاربر اجراکننده روی میزبان اجرا می‌کند، و این گسترده‌ترین مرز موجود است.

اجراکننده‌های کانتینر باریک‌ترند، و یک کانتینر ممتاز از باریک‌ها نیست. اجراکننده را در مهمان خودش با دامنه شبکه خودش نگه دارید، و تنها دسترسی مصنوعات و استقرار که کارها نیاز دارند به آن بدهید. کارگران یک‌بارمصرف وضعیت نگه‌داشته‌شده را کم می‌کنند، اما دسترس‌پذیری یا افشای رازها را کم نمی‌کنند. هر دو هنوز به محدودیت‌های صریح نیاز دارند.

مهمان سرویس‌ها مالک داده است، پس برنامه پشتیبانش همان است که باید کار کند. مخزن‌ها، بارگذاری‌ها و پایگاه داده را در یک زمان‌بندی نگه دارید. به‌جای خواندن وضعیت کار، یک بازیابی را آزمون کنید.

برای خرابی‌ای که هر سه شریک‌اند برنامه بریزید

یک میزبان یک دامنه خرابی است. راه‌اندازی دوباره تونل و هر سرویس خصوصی را در همان لحظه حذف می‌کند، و دقیقاً همان وقت است که یک راه به داخل بیشترین اهمیت را دارد.

دسترسی کنسولی را نگه دارید که به مهمان VPN وابسته نیست، چه کنسول فیزیکی، چه رابط مدیریت خارج از باند یا کنسول ارائه‌دهنده. عکسی که روی همان دیسک ذخیره شود نسخه مستقل نیست، و پشتیبانی که درون مهمانی که از آن محافظت می‌کند اجرا شود هم نیست. سپس راه‌اندازی سرد را به‌عنوان یک توالی بیازمایید نه یک چک‌لیست: میزبان، شبکه‌های مجازی، مسیر تونل و یک برنامه نام‌دار زیر یک حساب معمولی.

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

ترتیب شروع پردازه‌ها هیچ چیز درباره مسیرها و DNS ثابت نمی‌کند، پس مسیر را بیازمایید نه وضعیت واحدها را. مسیر همان چیزی است که کاربر دور واقعاً نیاز دارد.