Gateway

میزبانی چندمستاجری

میزبانی چندمستاجری

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

openclaw fleet هر نمونه جداشده را یک سلول می‌نامد. سلول یک Gateway کامل در کانتینری سخت‌سازی‌شده است که وضعیت، اعتبارنامه‌ها، فضای کاری، حساب‌های کانال، توکن و پورت میزبان مختص خود را دارد که فقط روی رابط حلقه‌بازگشت در دسترس است.

Fleet آزمایشی است: فرمان‌ها، پرچم‌ها و پروفایل کانتینر آن ممکن است بین انتشارها بدون دوره منسوخ‌سازی تغییر کنند.

Fleet روی میزبان‌های Linux و macOS آزمایش شده است. میزبان‌های Windows در حال حاضر آزمایش نشده‌اند.

چرا هر مستاجر به یک سلول نیاز دارد

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

برای هر مستاجر یک سلول استفاده کنید تا هر دامنه اعتماد، فرایند Gateway، کانتینر، درخت وضعیت پایدار و اعتبارنامه Gateway جداگانه‌ای داشته باشد. این رویکرد از مدل امنیتی Gateway پیروی می‌کند: کاربران متقابلاً نامطمئن را در یک فرایند OpenClaw یا زیر یک کاربر سیستم‌عامل در کنار هم قرار ندهید.

معماری

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

هر سلول، تصویر رسمی ghcr.io/openclaw/openclaw را روی شبکه پل تعریف‌شده توسط کاربر و مختص خود اجرا می‌کند. پل‌های جداگانه از ترافیک مستقیم IP کانتینر میان سلول‌ها جلوگیری می‌کنند و در عین حال دسترسی خروجی NAT را برای ارائه‌دهندگان و کانال‌ها حفظ می‌کنند. خروج داده به‌طور پیش‌فرض بدون محدودیت است. سلول‌های Podman می‌توانند از --network internal برای مسدودکردن خروج داده، با حفظ پورت منتشرشده حلقه‌بازگشت Gateway، استفاده کنند. شبکه‌های داخلی Docker آن پورت منتشرشده را از کار می‌اندازند، بنابراین Fleet این ترکیب را رد می‌کند؛ در عوض، سیاست خروج داده Docker را با قواعد دیواره آتش میزبان مانند زنجیره DOCKER-USER اعمال کنید. Gateway سلول درون کانتینر روی پورت 18789 گوش می‌دهد، در حالی که زمان‌اجرا آن را فقط روی 127.0.0.1:<allocated-port> میزبان منتشر می‌کند. هنگامی که دسترسی راه‌دور لازم است، اپراتور می‌تواند یک پراکسی معکوس تأییدشده، تونل SSH یا شبکه Tailscale را در مقابل آن نقطه پایانی حلقه‌بازگشت قرار دهد.

وضعیت پایدار Gateway از <state-dir>/fleet/cells/<tenant>/ تأمین و در /home/node/.openclaw سوار می‌شود. کلیدهای رمزنگاری پروفایل احراز هویت از مسیر میزبان جداگانه <state-dir>/fleet/auth-profile-secrets/<tenant>/ تأمین و در /home/node/.config/openclaw سوار می‌شوند که با چیدمان پایداری Docker رسمی مطابقت دارد. کلید زیر محل اتصال معمول وضعیت تودرتو نیست. حساب‌های کانال هر مستاجر درون سلولی خاتمه می‌یابند که مالک آن‌هاست؛ Fleet حساب کانال مشترک یا مسیریاب پیام ورودی فراهم نمی‌کند.

تصویر رسمی به‌طور پیش‌فرض از کاربر غیرریشه node با UID 1000 استفاده می‌کند. Fleet از نگاشت‌های کاربری سازگار با میزبان استفاده می‌کند تا محل‌های اتصال خصوصی قابل نوشتن باقی بمانند: Podman از keep-id استفاده می‌کند، Docker دارای دسترسی ریشه از هویت غیرریشه فراخواننده استفاده می‌کند و Docker بدون ریشه، ریشه کانتینر را به کاربر بدون امتیاز دیمن نگاشت می‌کند. هنگامی که SELinux میزبان فعال است، Docker و Podman بازبرچسب‌گذاری خصوصی :Z را اعمال می‌کنند. پروفایل کانتینر از قابلیت‌های ممتاز میزبان اجتناب می‌کند و با اجرای بدون ریشه سازگار است، اما اجرای بدون ریشه انتخاب و پیش‌نیاز زمان‌اجرای میزبان است، نه قابلیتی که Fleet به‌طور خودکار فعال کند.

مرز اعتماد

چندمستاجری مستاجران را از یکدیگر محافظت می‌کند. همه مستاجران به اپراتور Fleet و میزبان اعتماد دارند. مقاومت در برابر میزبان به‌خطر‌افتاده جزو اهداف نیست.

این یعنی مدیر میزبان می‌تواند پیکربندی و محیط کانتینر را بازرسی کند، داده‌های سوارشده سلول را بخواند، تصاویر را جایگزین کند یا وارد کانتینرها شود. توکن‌های Gateway و مقادیری که با --env ارسال می‌شوند، از طریق بازرسی Docker یا Podman برای مدیر قابل‌مشاهده‌اند. بر این اساس، از کنترل‌های میزبان، سیاست دسترسی مدیریتی، نظارت، پشتیبان‌گیری و مدیر اسرار تأییدشده استفاده کنید.

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

نردبان جداسازی

مرزی را انتخاب کنید که با مستاجران میزبانی‌شده مطابقت دارد:

  1. خط مبنای کانتینر سخت‌سازی‌شده. Fleet همه قابلیت‌های Linux را حذف می‌کند، no-new-privileges را فعال می‌کند، محدودیت‌های PID، حافظه، CPU و محدودیت اختیاری دیسک لایه قابل‌نوشتن را اعمال می‌کند، از محل‌های اتصال پایدار جداگانه و شبکه‌های مختص هر سلول استفاده می‌کند و فقط روی حلقه‌بازگشت میزبان منتشر می‌کند. شبکه پل، خروج داده را بدون محدودیت باقی می‌گذارد؛ هنگامی که یک سلول نباید اتصال خروجی برقرار کند، از --network internal در Podman یا سیاست دیواره آتش میزبان برای Docker استفاده کنید. این پروفایل پیش‌فرض برای مستاجرانی است که به اپراتور و میزبان اعتماد دارند.
  2. جداسازی قوی‌تر کانتینر یا ماشین مجازی. برای بارهای کاری پرخطرتر، Docker یا Podman را برای استفاده از زمان‌اجرای جداسازی OCI قوی‌تری مانند gVisor یا Kata Containers پیکربندی کنید، یا سلول‌ها را در ریزماشین‌های مجازی قرار دهید. این پیکربندی زمان‌اجرا یا زیرساخت است؛ گزینه --runtime docker|podman در Fleet، CLI کانتینر را انتخاب می‌کند، نه سامانه پشتیبان جداسازی OCI را. به زمان‌های‌اجرای جایگزین کانتینر در Docker و راهنمای زمان‌اجرای ماشین مجازی Docker مراجعه کنید.
  3. ماشین‌های جداگانه برای مستاجران متخاصم. مستاجران متخاصم را در یک فرایند OpenClaw یا زیر یک کاربر سیستم‌عامل در کنار هم قرار ندهید. هنگامی که مستاجران به یک اپراتور میزبان اعتماد ندارند یا به مرز مدیریتی قوی‌تری نیاز دارند، از ماشین‌های مجازی یا میزبان‌های فیزیکی جداگانه با مدیریت زمان‌اجرای مستقل استفاده کنید.

هیچ پله‌ای در این نردبان مدل اعتماد برنامه OpenClaw را تغییر نمی‌دهد: یک Gateway همچنان یک دامنه اپراتور مورداعتماد است.

شروع سریع

یک سلول ایجاد کنید. این فرمان توکن تولیدشده Gateway را فقط یک‌بار چاپ می‌کند، بنابراین فوراً آن را ذخیره کنید:

bash
openclaw fleet create acme

نشانی http://127.0.0.1:<port> گزارش‌شده را روی میزبان Fleet باز کنید، با توکن آن مستاجر احراز هویت کنید و اعتبارنامه‌های ارائه‌دهنده و حساب‌های کانال را درون سلول پیکربندی کنید.

وضعیت کانتینر و زنده‌بودن Gateway را بررسی کنید:

bash
openclaw fleet status acme

ارتقا را با حفظ پورت میزبان، داده‌های سوارشده، پروفایل منابع، محیط ارائه‌شده توسط کاربر و توکن Gateway انجام دهید:

bash
openclaw fleet upgrade acme

کانتینر و ردیف رجیستری را با حفظ داده‌های مستاجر حذف کنید:

bash
openclaw fleet rm acme --force

برای حذف داده‌های پایدار مستاجر نیز --purge-data را اضافه کنید. پاک‌سازی به --force نیاز دارد، برگشت‌ناپذیر است و پیش از حذف هر چیزی، بررسی محصوربودن مسیر حل‌شده را انجام می‌دهد:

bash
openclaw fleet rm acme --purge-data --force

برای همه فرمان‌ها و گزینه‌ها، به مرجع CLI ‏openclaw fleet مراجعه کنید.

دامنه کنونی

Fleet این قابلیت‌ها را فراهم نمی‌کند:

  • حساب‌های کانال مشترک یا مسیریاب ورودی مشترک
  • فرایندهای میزبان سبک‌سازی‌شده برای هر مستاجر به‌جای نمونه‌های کامل OpenClaw
  • میزبان‌های راه‌دور سلول که یک ناظر آن‌ها را مدیریت کند
  • پرتال سلف‌سرویس مستاجر، صفحه صورت‌حساب یا رابط کاربری مدیریت تفویض‌شده

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

مرتبط

Was this useful?
On this page

On this page