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

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

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

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

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

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

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

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

معماری

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

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

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

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

مرز اعتماد

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

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

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

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

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

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

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

شروع سریع

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

openclaw fleet create acme

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

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

openclaw fleet status acme

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

openclaw fleet upgrade acme

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

openclaw fleet rm acme --force

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

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

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

دامنه فعلی

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

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

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

مرتبط

• openclaw fleet
• امنیت Gateway
• چند Gateway
• Docker
• Podman