การโฮสต์แบบหลายผู้เช่า

โมเดลความปลอดภัยเริ่มต้นของ OpenClaw กำหนดขอบเขตผู้ดำเนินการที่เชื่อถือได้หนึ่งขอบเขตต่อ Gateway ไม่ใช่การแยกผู้เช่าหลายรายที่ไม่ไว้วางใจกันภายใน Gateway ที่ใช้ร่วมกันเพียงตัวเดียว ดังนั้น การโฮสต์ผู้ใช้หรือองค์กรที่ไม่ได้อยู่ในขอบเขตความไว้วางใจเดียวกันจึงต้องเรียกใช้อินสแตนซ์ OpenClaw ที่สมบูรณ์แยกกันสำหรับผู้เช่าแต่ละราย

openclaw fleet เรียกอินสแตนซ์ที่แยกแต่ละรายการว่า เซลล์ เซลล์คือ Gateway แบบเต็มที่ทำงานในคอนเทนเนอร์ที่เสริมความปลอดภัย พร้อมสถานะ ข้อมูลประจำตัว พื้นที่ทำงาน บัญชีช่องทาง โทเค็น และพอร์ตโฮสต์ที่รับฟังเฉพาะลูปแบ็กเป็นของตนเอง

Fleet ยังอยู่ในขั้น ทดลอง: คำสั่ง แฟล็ก และโปรไฟล์คอนเทนเนอร์อาจเปลี่ยนแปลงระหว่างรุ่นได้โดยไม่มีช่วงเวลาแจ้งเลิกใช้ล่วงหน้า

Fleet ผ่านการทดสอบบนโฮสต์ Linux และ macOS แล้ว ปัจจุบันยังไม่ได้ทดสอบโฮสต์ Windows

เหตุใดผู้เช่าแต่ละรายจึงต้องมีเซลล์

ผู้ดำเนินการที่ผ่านการยืนยันตัวตนภายใน Gateway หนึ่งตัวมีบทบาทในระนาบควบคุมที่เชื่อถือได้ รหัสเซสชันใช้เลือกการกำหนดเส้นทาง แต่ไม่ได้อนุญาตสิทธิ์ให้ผู้เช่ารายหนึ่งเข้าถึงหรือกระทำต่อผู้เช่าอีกราย การแซนด์บ็อกซ์เอเจนต์สามารถลดผลกระทบจากเนื้อหาที่ไม่น่าเชื่อถือและการเรียกใช้เครื่องมือได้ แต่ไม่ได้เปลี่ยน Gateway ที่ใช้ร่วมกันหนึ่งตัวให้เป็นขอบเขตการอนุญาตสิทธิ์ระหว่างผู้เช่า

ใช้หนึ่งเซลล์ต่อผู้เช่า เพื่อให้แต่ละโดเมนความไว้วางใจมีกระบวนการ Gateway คอนเทนเนอร์ โครงสร้างสถานะถาวร และข้อมูลประจำตัว Gateway แยกจากกัน ซึ่งเป็นไปตามโมเดลความปลอดภัยของ Gateway: อย่าวางผู้ใช้ที่ไม่ไว้วางใจกันไว้ร่วมกันในกระบวนการ OpenClaw เดียวหรือภายใต้ผู้ใช้ระบบปฏิบัติการเดียวกัน

สถาปัตยกรรม

Fleet CLI เป็นตัวควบคุมวงจรชีวิตที่ทำงานฝั่งโฮสต์ โดยบันทึกเซลล์ไว้ในฐานข้อมูลสถานะของ OpenClaw และสั่งให้รันไทม์ Docker หรือ Podman ภายในเครื่องสร้าง ตรวจสอบ เริ่ม หยุด แทนที่ และนำคอนเทนเนอร์ออก ไม่รองรับปลายทางรันไทม์ระยะไกล เนื่องจากพาธที่ผูกเมานต์และ URL ลูปแบ็กของ 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 หรือเครือข่ายส่วนตัวที่ได้รับอนุมัติไว้หน้าปลายทางลูปแบ็กนั้นเมื่อจำเป็นต้องเข้าถึงจากระยะไกล

สถานะถาวรของ 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 แบบ rootful ใช้ข้อมูลประจำตัวที่ไม่ใช่รูทของผู้เรียกใช้ และ Docker แบบ rootless แมปรูทของคอนเทนเนอร์ไปยังผู้ใช้เดมอนที่ไม่มีสิทธิ์พิเศษ Docker และ Podman ใช้การติดป้ายกำกับใหม่แบบส่วนตัว :Z เมื่อ SELinux ของโฮสต์ทำงานอยู่ โปรไฟล์คอนเทนเนอร์หลีกเลี่ยงคุณสมบัติโฮสต์ที่มีสิทธิ์พิเศษและรองรับการทำงานแบบ rootless ได้ดี แต่การทำงานแบบ rootless เป็นตัวเลือกและข้อกำหนดเบื้องต้นของรันไทม์บนโฮสต์ ไม่ใช่สิ่งที่ Fleet เปิดใช้งานให้อัตโนมัติ

ขอบเขตความไว้วางใจ

การทำงานแบบหลายผู้เช่าปกป้องผู้เช่าจากกันและกัน ผู้เช่าทุกรายไว้วางใจผู้ดำเนินการ Fleet และโฮสต์ การต้านทานโฮสต์ที่ถูกเจาะระบบไม่ใช่เป้าหมายของระบบนี้

ซึ่งหมายความว่าผู้ดูแลโฮสต์สามารถตรวจสอบการกำหนดค่าและสภาพแวดล้อมของคอนเทนเนอร์ อ่านข้อมูลเซลล์ที่เมานต์ไว้ แทนที่อิมเมจ หรือเข้าสู่คอนเทนเนอร์ได้ ผู้ดูแลสามารถมองเห็นโทเค็น Gateway และค่าที่ส่งผ่าน --env ได้จากการตรวจสอบ Docker หรือ Podman ดังนั้นจึงควรใช้มาตรการควบคุมโฮสต์ นโยบายการเข้าถึงระดับผู้ดูแล การเฝ้าติดตาม การสำรองข้อมูล และตัวจัดการข้อมูลลับที่ได้รับอนุมัติอย่างเหมาะสม

ค่าพื้นฐานนี้ป้องกันการเปิดเผยเครือข่ายด้วยไวลด์การ์ดโดยไม่ตั้งใจและนำกลไกทั่วไปที่ใช้ยกระดับสิทธิ์จากคอนเทนเนอร์ออก แต่ไม่ได้ทำให้โฮสต์ที่ไม่น่าเชื่อถือมีความปลอดภัย

ลำดับขั้นการแยก

เลือกขอบเขตที่เหมาะกับผู้เช่าที่โฮสต์:

1. ค่าพื้นฐานของคอนเทนเนอร์ที่เสริมความปลอดภัย Fleet ยกเลิกความสามารถทั้งหมดของ Linux เปิดใช้ no-new-privileges กำหนดขีดจำกัด PID หน่วยความจำ CPU และขนาดดิสก์ของเลเยอร์ที่เขียนได้ซึ่งเป็นตัวเลือก ใช้จุดเมานต์ถาวรและเครือข่ายแยกสำหรับแต่ละเซลล์ และเผยแพร่เฉพาะไปยังลูปแบ็กของโฮสต์ เครือข่ายบริดจ์ไม่จำกัดการรับส่งข้อมูลขาออก ให้ใช้ --network internal ของ Podman หรือนโยบายไฟร์วอลล์ของโฮสต์ Docker เมื่อเซลล์ต้องไม่เริ่มการเชื่อมต่อขาออก นี่คือโปรไฟล์เริ่มต้นสำหรับผู้เช่าที่ไว้วางใจผู้ดำเนินการและโฮสต์
2. การแยกด้วยคอนเทนเนอร์หรือ VM ที่แข็งแกร่งกว่า สำหรับเวิร์กโหลดที่มีความเสี่ยงสูงกว่า ให้กำหนดค่า Docker หรือ Podman ให้ใช้รันไทม์การแยก OCI ที่แข็งแกร่งกว่า เช่น gVisor หรือ Kata Containers หรือวางเซลล์ใน microVM การดำเนินการนี้เป็นการกำหนดค่ารันไทม์หรือโครงสร้างพื้นฐาน ตัวเลือก --runtime docker|podman ของ Fleet ใช้เลือก CLI ของคอนเทนเนอร์ ไม่ใช่แบ็กเอนด์การแยก OCI โปรดดูรันไทม์คอนเทนเนอร์ทางเลือกของ Docker และคู่มือรันไทม์ Docker VM
3. เครื่องแยกสำหรับผู้เช่าที่ไม่ไว้วางใจกัน อย่าวางผู้เช่าที่ไม่ไว้วางใจกันไว้ร่วมกันในกระบวนการ OpenClaw เดียวหรือภายใต้ผู้ใช้ระบบปฏิบัติการเดียวกัน เมื่อผู้เช่าไม่ไว้วางใจผู้ดำเนินการโฮสต์รายเดียวกันหรือต้องการขอบเขตการดูแลระบบที่แข็งแกร่งกว่า ให้ใช้ VM หรือโฮสต์จริงแยกกันพร้อมการดูแลรันไทม์แยกกัน

ไม่มีขั้นใดในลำดับนี้ที่เปลี่ยนโมเดลความไว้วางใจของแอปพลิเคชัน 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 ไม่สามารถย้อนกลับได้ และจะตรวจสอบว่าพาธที่แก้ไขสมบูรณ์แล้วยังคงอยู่ภายในขอบเขตก่อนลบสิ่งใด:

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

โปรดดูเอกสารอ้างอิง CLI ของ openclaw fleetสำหรับคำสั่งและตัวเลือกทั้งหมด

ขอบเขตปัจจุบัน

Fleet ไม่มีความสามารถต่อไปนี้:

• บัญชีช่องทางที่ใช้ร่วมกันหรือตัวกำหนดเส้นทางขาเข้าแบบใช้ร่วมกัน
• กระบวนการโฮสต์แบบลดขนาดสำหรับผู้เช่าแต่ละรายแทนอินสแตนซ์ OpenClaw ที่สมบูรณ์
• โฮสต์เซลล์ระยะไกลที่จัดการโดยตัวควบคุมเดียว
• พอร์ทัลบริการตนเองสำหรับผู้เช่า ระนาบการเรียกเก็บเงิน หรือ UI การดูแลระบบแบบมอบหมายสิทธิ์

ความสามารถเหล่านี้จำเป็นต้องมีสัญญาที่ชัดเจนสำหรับข้อมูลประจำตัว การกำหนดเส้นทาง การอนุญาตสิทธิ์ และโดเมนความล้มเหลว อย่าจำลองความสามารถเหล่านี้ด้วยการใช้ Gateway หนึ่งตัวหรือข้อมูลประจำตัวของ Gateway ร่วมกันระหว่างผู้เช่า Fleet เป็นตัวควบคุมวงจรชีวิตสำหรับโฮสต์เดียว ส่วนฟลีตหลายเครื่องที่อยู่ภายใต้การกำกับดูแลด้านข้อมูลประจำตัวต้องมีชั้นระนาบควบคุมแยกต่างหาก

เนื้อหาที่เกี่ยวข้อง

• openclaw fleet
• ความปลอดภัยของ Gateway
• Gateway หลายตัว
• Docker
• Podman