การแยกส่วนแบบคอนเทนเนอร์กับ microVM: เปรียบเทียบ 4 ระดับ ตั้งแต่ซับโปรเซสถึง VM เต็มรูปแบบ

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

การเปรียบเทียบนี้สมมติว่าโค้ดไม่น่าไว้ใจจริง ๆ: เขียนโดยโมเดลภาษา ส่งมาโดยผู้ใช้ หรือมาใน pull request จากคนที่คุณไม่รู้จัก โค้ดที่คุณเขียนเองมีความต้องการต่างออกไป

อะไรผิดพลาดได้บ้าง

ก่อนเปรียบเทียบขอบเขต ควรระบุก่อนว่ามันมีไว้เพื่ออะไร โค้ดที่ไม่น่าไว้ใจสามารถ:

1. อ่านสิ่งที่ไม่ควรอ่าน: ตัวแปรสภาพแวดล้อม คีย์ SSH ไฟล์ในโฮมไดเรกทอรี endpoint ของ metadata บนคลาวด์
2. ใช้ทรัพยากรจนหมด: วนลูปไม่รู้จบ fork จนเครื่องค้าง เขียนดิสก์จนเต็ม
3. ใช้เครือข่ายในทางที่ผิด: สแกนโฮสต์อื่น ส่งสแปม ขุดคริปโต เรียกบริการภายในของคุณ
4. ฝังตัวอยู่ต่อ: ติดตั้ง cron job หรือบริการที่อยู่ต่อหลังงานจบ
5. หลบหนี: ใช้บั๊กในชั้นข้างล่างเพื่อรันโค้ดบนโฮสต์เอง

แต่ละระดับด้านล่างจัดการได้บางข้อ แต่ไม่ได้ทุกข้อ

ระดับ 1: โปรเซส

แซนด์บ็อกซ์ที่ง่ายที่สุดคือโปรเซสลูก: subprocess.run พร้อม timeout อาจรันภายใต้ผู้ใช้แยก และถ้าละเอียดก็มีการจำกัดทรัพยากรและตัวกรอง seccomp

หยุดได้: เวลาที่เกินควบคุม (timeout) การใช้ทรัพยากรจนหมดบางส่วน (การจำกัด) system call อันตรายบางตัว (seccomp) หยุดไม่ได้: การอ่านทุกอย่างที่ผู้ใช้นั้นอ่านได้ การเข้าถึงเครือข่าย การฝังตัวผ่านที่ใดก็ตามที่ผู้ใช้เขียนได้ และบั๊กใด ๆ ในเคอร์เนล ความล้มเหลวที่พบบ่อย: โค้ดอ่านไฟล์ที่คุณลืมไปว่าอ่านได้ หรือตัวแปลภาษาที่ “ถูกจำกัด” กลับมีช่องให้หลุดออกมา ประวัติศาสตร์เต็มไปด้วยแซนด์บ็อกซ์ในตัวภาษาที่ป้องกันไม่อยู่

เวลาเริ่มทำงานแทบเป็นศูนย์ ใช้ได้ดีกับโค้ดที่คุณเขียนเอง แต่ไม่ใช่ขอบเขตสำหรับโค้ดที่คุณไม่ได้เขียน

ระดับ 2: คอนเทนเนอร์

namespaces ทำให้โค้ดมีมุมมองของไฟล์ โปรเซส และเครือข่ายเป็นของตัวเอง cgroups จำกัด CPU และหน่วยความจำ ส่วน capabilities ที่ถูกตัดออกและ seccomp จำกัดสิ่งที่มันขอจากเคอร์เนลได้

หยุดได้: การอ่านไฟล์ของโฮสต์ (เว้นแต่ถูก mount เข้ามา) การมองเห็นโปรเซสอื่น การใช้ทรัพยากรไม่จำกัด และปัญหาการฝังตัวส่วนใหญ่หากคอนเทนเนอร์ถูกทิ้งหลังใช้งาน หยุดไม่ได้: บั๊กในเคอร์เนลของโฮสต์ที่ใช้ร่วมกัน คอนเทนเนอร์ทุกตัวบนเครื่องคุยกับเคอร์เนลเดียวกัน ช่องโหว่ในเคอร์เนลที่เข้าถึงได้จึงเป็นทางออก ความล้มเหลวที่พบบ่อย: การตั้งค่า ไม่ใช่ exploit แปลกประหลาด คอนเทนเนอร์แบบ privileged ซ็อกเก็ตของ container runtime ที่ mount ไว้ข้างใน เครือข่ายของโฮสต์ที่เปิด “แค่ไว้ดีบัก” แต่ละอย่างลบขอบเขตทิ้งอย่างเงียบ ๆ

เวลาเริ่มทำงานเป็นมิลลิวินาที มีรุ่นที่เสริมความแข็งแกร่งด้วย รวมถึงเคอร์เนลใน user space ที่ดักจับ system call ก่อนถึงโฮสต์ โดยแลกกับความเร็วและความเข้ากันได้บางส่วน สำหรับโค้ดจากคนที่คุณไว้ใจ คอนเทนเนอร์ที่ตั้งค่าดีเป็นค่าเริ่มต้นที่สมเหตุสมผล

ระดับ 3: microVM

microVM รันเคอร์เนลของตัวเองภายใต้ไฮเปอร์ไวเซอร์ เหมือน VM เต็มรูปแบบ แต่ฮาร์ดแวร์ที่จำลองถูกตัดออกเกือบทั้งหมด Firecracker เป็นตัวอย่างที่รู้จักกันดีที่สุด

หยุดได้: ทุกอย่างที่คอนเทนเนอร์หยุดได้ บวกปัญหาเคอร์เนลที่ใช้ร่วมกัน การจะไปถึงโฮสต์ โค้ดต้องเจาะไฮเปอร์ไวเซอร์หรืออุปกรณ์เสมือนไม่กี่ชิ้น ซึ่งเป็นพื้นผิวที่เล็กกว่าอินเทอร์เฟซ system call ของเคอร์เนลมาก หยุดไม่ได้: การใช้สิ่งที่คุณมอบให้ในทางที่ผิด ทราฟฟิกขาออกที่เปิดอยู่ยังถูกใช้ในทางที่ผิดได้ ความลับที่คุณใส่เข้าไปยังรั่วได้ ความล้มเหลวที่พบบ่อย: นโยบาย ไม่ใช่การแยกส่วน มีคนส่งโทเค็นโปรดักชันเข้าไป “เพื่อให้เทสต์ผ่าน” หรือปล่อยทราฟฟิกขาออกไม่จำกัดในเวิร์กโหลดที่ไม่จำเป็นต้องใช้

เวลาเริ่มทำงานตั้งแต่เสี้ยววินาทีถึงราวหนึ่งวินาที พร้อมโอเวอร์เฮดไม่กี่เมกะไบต์ เร็วพอที่จะสร้างหนึ่งตัวต่องานแล้วลบทิ้ง ซึ่งแก้ปัญหาการฝังตัวไปด้วย: ไม่เหลืออะไรให้กลับมา

ระดับ 4: เครื่องเสมือนเต็มรูปแบบ

VM ทั่วไป หรือ VPS มีขอบเขตแบบเดียวกับ microVM: การจำลองเสมือนระดับฮาร์ดแวร์และไฮเปอร์ไวเซอร์ ความต่างอยู่ที่ทุกสิ่งรอบ ๆ: โมเดลอุปกรณ์เต็มรูปแบบ ระบบปฏิบัติการครบชุด IP สาธารณะหากต้องการ และวงจรชีวิตที่วัดเป็นวันหรือเดือน

หยุดได้: ปัญหาประเภทเดียวกับ microVM โดยมีพื้นผิวการโจมตีใหญ่กว่าเล็กน้อยเพราะจำลองฮาร์ดแวร์มากกว่า หยุดไม่ได้: การใช้ตัวตนเครือข่ายของมันเองในทางที่ผิด VM ที่มี IP สาธารณะและรันโค้ดที่เป็นอันตรายจะทำให้ IP ของมันเอง ติดบล็อกลิสต์ ซึ่งสำคัญมากหาก IP เดียวกันนั้นใช้ส่งอีเมลของคุณด้วย (ถ้าเกิดขึ้นแล้ว ดูควรทำอย่างไรเมื่อ IP ของคุณติดบล็อกลิสต์) ความล้มเหลวที่พบบ่อย: มันอยู่นานเกินไป VM ที่สร้างไว้สำหรับการทดลองครั้งเดียวสะสมข้อมูลรับรองและสถานะ แล้วค่อย ๆ กลายเป็นเครื่องที่ไว้ใจได้ซึ่งมันควรจะปกป้อง

เวลาเริ่มทำงานตั้งแต่หลายสิบวินาทีถึงหลายนาที และการคิดเงินมักเป็นรายเดือน นี่คือรูปแบบที่เหมาะกับบริการที่รันนานและต้องการพอร์ตขาเข้า และไม่เหมาะกับการรันโค้ด 20 วินาที

การเปรียบเทียบ

การเลือก

• โค้ดที่คุณหรือทีมเขียน: โปรเซสหรือคอนเทนเนอร์ก็พอ
• CI สำหรับ branch ของคุณเอง: คอนเทนเนอร์บน runner ของคุณ
• โค้ดที่เอเจนต์สร้าง สิ่งที่ผู้ใช้ส่งมา pull request จากภายนอก: microVM หนึ่งตัวต่องาน แล้วลบทิ้ง
• บริการที่ไม่น่าไว้ใจซึ่งต้องรับการเชื่อมต่อหรือรันเป็นสัปดาห์: VM แยกที่มี IP ของตัวเอง อยู่ห่างจากทุกสิ่งที่เก็บข้อมูลรับรองของคุณหรือส่งอีเมลของคุณ

ไม่ว่าจะเลือกแบบไหน มีกฎสองข้อที่ใช้ซ้อนอยู่เสมอ: อย่าใส่สิ่งที่คุณจะไม่ยื่นให้ผู้เขียนโค้ดไว้ข้างใน และตัดสินใจอย่างตั้งใจว่าเครือข่ายทำอะไรได้บ้าง

ผลิตภัณฑ์ของเราอยู่ตรงไหน

สำหรับระดับ 3 เราให้บริการแซนด์บ็อกซ์สำหรับโค้ด: Firecracker microVM ที่เริ่มทำงานในราวหนึ่งวินาที มีอินเทอร์เน็ตขาออก ไม่มีพอร์ตขาเข้า และคิดเงินรายวินาที ออกแบบมาเพื่อข้อสามข้างต้นโดยตรง หน้ามาตรการป้องกันของ MCP อธิบายวิธีจำกัดสิ่งที่เอเจนต์ทำกับมันได้ สำหรับระดับ 4 VPS อย่างแพ็กเกจ AI agent ให้เครื่องทั้งเครื่องแบบรายเดือน ตัวอย่างในแซนด์บ็อกซ์สำหรับ AI agent แสดงรูปแบบ microVM ตั้งแต่ต้นจนจบ และ สิ่งที่ AI agent ต้องการจากโครงสร้างพื้นฐาน มองการแยกส่วนเป็นหนึ่งในข้อกำหนดหลายข้อ