سندباکس ایجنت پیش از آنکه پرسشی درباره کانتینر باشد، پرسشی درباره توانمندی است

کانتینرها شعاع انفجار را محدود می‌کنند، نه رفتار را

وقتی تیم‌ها نخستین بار ایجنت را در سندباکس قرار می‌دهند، گفتگو معمولاً با فناوری جداسازی آغاز می‌شود. میکروVM‌های Firecracker، gVisor، پروفایل‌های seccomp، محدودیت‌های cgroup، فایل‌سیستم‌های ریشه فقط-خواندنی. این‌ها واقعی و مفیدند، اما به پرسشی باریک‌تر از آنچه بیشتر مردم گمان می‌کنند پاسخ می‌دهند. آن‌ها محدود می‌کنند که آسیب کجا می‌تواند فرود بیاید. آن‌ها محدود نمی‌کنند که ایجنت مجاز است چه چیزی را بیازماید.

سندباکسی که فضای نام شبکه میزبان را به اشتراک می‌گذارد، پیشاپیش بخش جالب مسئله را واگذار کرده است. ایجنت همچنان می‌تواند به سرویس فراداده داخلی، رجیستری بسته، ارائه‌دهنده مدل، ویکی شرکت، و هر سرویسی که به IP میزبان اعتماد دارد دسترسی پیدا کند. جداسازی فایل‌سیستم، ایجنتی را که سطح توانمندی واقعی‌اش HTTP خروجی به‌همراه مجموعه‌ای از اعتبارنامه‌های API است، محدود نمی‌کند. می‌توانید فایل‌سیستم ریشه را فقط-خواندنی سوار کنید و همچنان ببینید که ایجنت یک پایگاه داده را از مسیر خروجی مجاز بیرون می‌کشد، چون توانمندی‌ای که اهمیت داشت هرگز توصیف‌گر فایل نبود. توکن بود.

به همین دلیل چارچوب‌بندی کانتینر-محور معمولاً سندباکس‌هایی تولید می‌کند که سختگیرانه به نظر می‌رسند و سهل‌گیرانه رفتار می‌کنند. واحد تحلیل اشتباه است. واحد مفید، مجموعه توانمندی در هر گام است، و آن مجموعه با پیشرفت اجرا تغییر می‌کند.

بودجه توانمندی به‌عنوان عنصر اصلی طراحی

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

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

{
  "step": "fetch_invoice_pdf",
  "capabilities": [
    {"type": "http", "host": "billing.internal", "methods": ["GET"], "paths": ["/invoices/*/pdf"]},
    {"type": "fs", "mount": "/tmp/run-7f3a", "mode": "write"}
  ],
  "ttl_seconds": 30
}

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

تشدید، مورد جالب است. وقتی گامی چیزی بیرون از بودجه فعلی نیاز دارد، باید یک درخواست تشدید صریح ثبت کند. آن درخواست خودش رویدادی ثبت‌شده با یک تصمیم سیاستی پیوست است: چه کسی یا چه چیزی آن را تأیید کرد، تحت کدام قاعده، با چه انقضایی. این، خزش امتیاز را از یک لغزش خاموش به یک توالی قابل حسابرسی تبدیل می‌کند. همچنین تاریخچه توانمندی اجرا را به یک مصنوع درجه‌یک بدل می‌کند، که همان چیزی است که واقعاً وقتی در گام چهلم چیزی اشتباه می‌شود می‌خواهید.

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

این بده‌بستان واقعی است و ارزش دارد صریح گفته شود. اعتبارنامه‌های محدود به گام تعداد تبادل توکن را چند برابر می‌کنند، یک کارگزار به مسیر بحرانی می‌افزایند، و تأخیر و حالت‌های شکستی را معرفی می‌کنند که یک توکن دیرپای واحد ندارد. هر گام اکنون به در دسترس بودن کارگزار و درست بودن موتور سیاست وابسته است. تیم‌هایی که این الگو را برمی‌گزینند، بهایش را در پیچیدگی عملیاتی می‌پردازند، و باید آگاهانه تصمیم بگیرند که آیا پروفایل ریسک وظیفه چنین بهایی را توجیه می‌کند. برای یک ایجنت خلاصه‌ساز فقط-خواندنی روی داده‌های عمومی، اغلب توجیه نمی‌کند. برای ایجنتی که دسترسی نوشتن به سیستم‌های تولیدی دارد، معمولاً توجیه می‌کند.

ایجنت‌های مرورگر و دسکتاپ

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

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

ایجنت‌های فیزیکی و رباتیک

ایجنت‌های فیزیکی بُعد دومی به بودجه می‌افزایند که سندباکس‌های نرم‌افزاری ندارند: پوش حرکت و محدودیت‌های نیرو. مجموعه توانمندی یک بازوی رباتیک نه‌تنها شامل اینکه کدام API را می‌تواند فراخوانی کند، بلکه اینکه کجا می‌تواند حرکت کند، با چه سرعتی، و با چه مقدار نیرو است. این محدودیت‌ها توسط کنترلر اعمال می‌شوند، و باید به همان شیوه برای هر گام محدود شوند. گامی که «برداشتن شیء از سبد A» را اعلام می‌کند باید پوش حرکتی‌ای حمل کند که سبد B را حذف می‌کند و سقف نیرویی متناسب با رده شیء. تشدید به پوشی گسترده‌تر یک تصمیم سیاستی ثبت‌شده است، دقیقاً همانند توانمندی‌های شبکه.

دلیل اهمیت این موضوع آن است که حالت‌های شکست برگشت‌پذیر نیستند. یک توکن HTTP لغوشده یک نشت داده را متوقف می‌کند. یک پوش حرکت لغوشده یک بازو را در میانه مسیر متوقف می‌کند، که مسئله مهندسی متفاوتی است شامل پروفایل‌های کاهش سرعت و حالت‌های ایمن. مدل توانمندی همان است؛ معناشناسی لغو نیست.

هارنس‌های ارزیابی

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

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

این چه چیزی را تغییر می‌دهد

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

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