ในโลกแห่ง AI agents และการรันโค้ดที่ไม่น่าเชื่อถือที่กำลังพัฒนาอย่างรวดเร็ว โครงการโอเพนซอร์สใหม่ที่มีชื่อว่า Katakube K7 ได้ปรากฏตัวขึ้น โดยสัญญาว่าจะให้ VM sandboxes แบบน้ำหนักเบาสำหรับการรันโค้ดที่อาจเป็นอันตรายในระดับขนาดใหญ่ สร้างขึ้นจากเทคโนโลยีที่ผ่านการทดสอบมาแล้วอย่าง Kata Containers และ Firecracker โดย K7 มีเป้าหมายที่จะทำให้การสร้าง sandbox ที่ปลอดภัยเป็นเรื่องง่ายดายเหมือนกับการรัน containers ทว่าการอภิปรายในชุมชนล่าสุดได้เผยให้เห็นข้อกังวลด้านความปลอดภัยที่สำคัญ ซึ่งเน้นย้ำถึงความท้าทายในการสร้างสภาพแวดล้อมการทำงานที่ถูกแยกออกมาอย่างแท้จริง
ส่วนประกอบของ Technical Stack ของ Katakube K7:
- Kata Containers: ให้การแยกระบบในระดับฮาร์ดแวร์ผ่าน lightweight VMs
- Firecracker: Virtual Machine Manager สำหรับการบูตที่รวดเร็วและพื้นที่โจมตีที่น้อยที่สุด
- Kubernetes (K3s): ชั้น Orchestration สำหรับการจัดการ sandboxes ในระดับขนาดใหญ่
- Device-mapper: Snapshotter พร้อม thin-pool provisioning เพื่อการใช้ดิสก์ที่มีประสิทธิภาพ
- Jailer: ชั้นความปลอดภัยเพิ่มเติมโดยใช้การแยกระบบแบบ chroot
ช่องโหว่การส่งข้อมูลออกผ่าน DNS ที่ดึงความสนใจของทุกคน
การอภิปรายที่ร้อนแรงที่สุดรอบๆ Katakube K7 เกี่ยวข้องกับตัวอย่างการตั้งค่าที่ดูเหมือนไม่สำคัญ แต่สามารถทำให้ผู้ใช้เสี่ยงต่อการถูกขโมยข้อมูล สมาชิกในชุมชนระบุอย่างรวดเร็วว่าในขณะที่ K7 บล็อกการเข้าถึงเครือข่ายโดยตรง แต่มันยังคงอนุญาตให้แก้ไข DNS ไปยังผู้ให้บริการรายใหญ่เช่น Cloudflare และ Google DNS สิ่งนี้สร้างช่องโหว่ที่เป็นไปได้สำหรับการส่งข้อมูลออกโดยที่โค้ดที่เป็นอันตรายสามารถเข้ารหัสข้อมูลลับไว้ในคำขอชื่อโดเมนได้
นี่Basicallyคือนโยบายเครือข่ายที่เปิดกว้างในแง่ของการส่งข้อมูลออก โค้ดที่เป็นอันตรายเพียงแค่ต้องแก้ไข [secret].evil.com และ Google/CF จะส่งต่อคำขอนั้นไปยังตัวแก้ไข evil
ข้อกังวลนี้ถูกใจหลายคนเพราะมันบ่อนทำลายจุดประสงค์หลักของ sandbox ที่มุ่งเน้นความปลอดภัย ผู้ดูแลโครงการยอมรับปัญหาดังกล่าวและได้ย้ายข้อจำกัดการแก้ไข DNS ไปยังอันดับต้นๆ ของแผนพัฒนาทันที โดยสัญญาว่าจะบล็อก DNS ทั้งหมดโดยค่าเริ่มต้น จนกว่าการระบุโดเมนที่อนุญาตผ่านการรวม Cilium จะถูกนำมาใช้
ฟีเจอร์ด้านความปลอดภัย vs. ข้อกังวลในปัจจุบัน:
| ฟีเจอร์ด้านความปลอดภัย | สถานะปัจจุบัน | ข้อกังวลของชุมชน |
|---|---|---|
| VM Isolation | ใช้งานผ่าน Kata/Firecracker | มีรากฐานที่แข็งแกร่ง |
| Network Policies | การควบคุม egress แบบ CIDR | มีความเป็นไปได้ที่จะเกิด DNS exfiltration |
| DNS Filtering | วางแผนจะผสานรวมกับ Cilium | ปัจจุบันอนุญาตให้ใช้ DNS providers รายใหญ่ได้ |
| Non-root Execution | สามารถตั้งค่าได้ | ไม่ได้เปิดใช้งานโดยค่าเริ่มต้น |
| Capability Dropping | ยกเลิก capabilities ทั้งหมดโดยค่าเริ่มต้น | เป็นการป้องกันแบบ defense-in-depth ที่ดี |
ระบบนิเวศที่กำลังเติบโตของโซลูชันการสร้าง Sandbox
ในขณะที่นักพัฒนากำลังต่อสู้กับความท้าทายในการรันโค้ดที่สร้างโดย AI ที่ไม่น่าเชื่อถือ แนวทางการสร้าง sandbox หลายแบบได้ปรากฏขึ้น การอภิปรายในชุมชนเปิดเผยทางเลือกหลายทาง ซึ่งแต่ละทางมีการแลกเปลี่ยนระหว่างความปลอดภัย ประสิทธิภาพ และความง่ายในการใช้ที่แตกต่างกัน Anthropic เพิ่งปล่อยเครื่องมือสร้าง sandbox ที่อิงจาก bubblewrap สำหรับ Linux และ sandbox-exec สำหรับ macOS ในขณะที่นักพัฒนาคนอื่นๆ กล่าวถึงโซลูชันเช่น gVisor, nsjails และแนวทางต่างๆ ที่อิงตาม container
สิ่งที่ทำให้ Katakube K7 เด่นในพื้นที่ที่คับคั่งนี้คือการรวมกันของ virtualization ระดับฮาร์ดแวร์ผ่าน Kata Containers กับการจัดระเบียบโดย Kubernetes ซึ่งแตกต่างจาก sandbox แบบซอฟต์แวร์ล้วนๆ K7 ใช้ virtual machines จริงผ่าน Firecracker ทำให้มีการแยกที่แข็งแกร่งกว่าวิธีการที่อิงตาม container ในขณะที่ยังคงรักษาเวลาเริ่มต้นที่ค่อนข้างเร็ว แนวทางแบบ Python-first ของโครงการยังทำให้มันน่าสนใจเป็นพิเศษสำหรับนักพัฒนา AI ที่ชอบทำงานในระบบนิเวศ Python มากกว่าการจัดการกับข้อกังวลด้านโครงสร้างพื้นฐานระดับล่าง
โซลูชันแซนด์บ็อกซ์ทางเลือกที่กล่าวถึง:
- Anthropic Sandbox: ใช้ Bubblewrap (Linux) และ sandbox-exec (macOS) เป็นพื้นฐาน
- gVisor: เคอร์เนลในพื้นที่ผู้ใช้สำหรับการสกัดกั้นการเรียกระบบ
- nsjails: การแยกส่วนที่ใช้ Linux namespace และ cgroup เป็นพื้นฐาน
- Apple Containers: เครื่องเสมือนขนาดเล็กสำหรับแพลตฟอร์ม Apple ARM
- coderunner: โซลูชันแบบ local-first ที่ใช้ Apple containers
- rstrict.cloud: Rust CLI ที่ใช้ Landlock API
 |
|---|
| ตัวอย่างของ repository โอเพนซอร์สบน GitHub ที่แสดงโปรเจกต์ที่เกี่ยวข้องกับ VM sandboxing ซึ่งเป็นตัวแทนของความพยายามของชุมชนในการพัฒนาโซลูชันสำหรับการรันโค้ดที่ไม่น่าเชื่อถือ |
ความปลอดภัยเทียบกับความสะดวกใช้ได้ในการออกแบบ Sandbox
การอภิปรายเกี่ยวกับการส่งข้อมูลออกผ่าน DNS เน้นให้เห็นถึงความตึงเครียดพื้นฐานในการออกแบบเครื่องมือความปลอดภัย: วิธีสร้างสมดุลระหว่างความปลอดภัยกับความสะดวกใช้ได้ในทางปฏิบัติ สมาชิกในชุมชนแสดงความกังวลว่าการต้องกำหนดค่าตัวเลือกความปลอดภัยหลายอย่าง ขัดกับจุดประสงค์ของเครื่องมือที่ควรจะให้ค่าตั้งต้นที่ปลอดภัย ดังที่ผู้แสดงความคิดเห็นหนึ่งคนระบุ การแนะนำเครื่องมือความปลอดภัยในขณะที่เตือนผู้ใช้เกี่ยวกับข้อกำหนดการกำหนดค่าหลายอย่าง สถานการณ์ที่อันตรายที่หลายคนอาจติดตั้งมันโดยไม่มีการเสริมความแข็งแกร่งที่เหมาะสม
Katakube K7 พยายามแก้ไขปัญหานี้ผ่านชั้นความปลอดภัยหลายชั้น รวมถึงการแยก VM, การยกเลิกความสามารถของ Unix, การรันแบบไม่ใช้สิทธิ์ root และนโยบายเครือข่าย อย่างไรก็ตาม ข้อติชมจากชุมชนชี้ให้เห็นว่าเครื่องมือความปลอดภัยจำเป็นต้องปลอดภัยโดยค่าเริ่มต้น ไม่ใช่เพียงแค่สามารถกำหนดค่าให้ปลอดภัยได้ เหตุการณ์นี้เป็นบทเรียนที่มีค่าสำหรับโครงการทั้งหมดที่มุ่งเน้นความปลอดภัย เกี่ยวกับความสำคัญของการพิจารณาสถานการณ์การใช้งานในโลกจริงและวิธีการของผู้โจมตีระหว่างการออกแบบ
คำถามเกี่ยวกับโมเดลธุรกิจและความยั่งยืนของโอเพนซอร์ส
อีกหัวข้อที่น่าสนใจในการอภิปรายเกี่ยวข้องกับความยั่งยืนระยะยาวของโครงการ เมื่อถูกสอบถามเกี่ยวกับโมเดลธุรกิจ ผู้ดูแลโครงการระบุว่าไม่มีแผนการที่จะสร้างรายได้ในทันที โดยมุ่งเน้นที่การได้รับการยอมรับในวงกว้างแทน สิ่งนี้ทำให้สมาชิกในชุมชนกังวล ผู้ซึ่งเคยเห็นโครงการที่คล้ายกัน最終นำเสนอคุณสมบัติแบบเสียเงินหรือเปลี่ยนโมเดลลิขสิทธิ์ในที่สุด
ผู้ดูแลโครงการแนะนำเส้นทางในอนาคตที่อาจเป็นไปได้ซึ่งคล้ายกับโมเดลของ Docker โดยที่ส่วน核心ยังคงเป็นโอเพนซอร์ส ในขณะที่คุณสมบัติสำหรับองค์กร เช่น การรับรองการปฏิบัติตามข้อกำหนดและการสนับสนุนหลายคลาวด์ อาจกลายเป็นบริการแบบเสียเงิน แนวทางนี้พิสูจน์แล้วว่าประสบความสำเร็จสำหรับโครงการโครงสร้างพื้นฐานหลายแห่ง แต่ชุมชนยังคงระมัดระวังกับโครงการที่ไม่มีแผนความยั่งยืนที่ชัดเจน เนื่องจากมีหลายโครงการที่เปลี่ยนไปจากโมเดลโอเพนซอร์สล้วนๆ ภายใต้แรงกดดันทางการเงิน
ประสิทธิภาพและข้อพิจารณาในทางปฏิบัติ
นอกเหนือจากความปลอดภัยแล้ว สมาชิกในชุมชนได้ตั้งคำถามในทางปฏิบัติเกี่ยวกับลักษณะประสิทธิภาพ โดยเฉพาะสำหรับ workloads ของ AI ผู้ดูแลโครงการระบุว่าการใช้งานปัจจุบันที่อิงจาก Firecracker ไม่สามารถรองรับ GPU passthrough ได้ แต่มีการวางแผนรองรับ QEMU ซึ่งจะเปิดใช้งาน workloads ที่ใช้ GPU สำหรับงานที่ใช้ CPU อย่างเข้มข้น โครงการอ้างว่าสามารถรัน VM pods มากกว่า 50 ตัว พร้อมกับขีดจำกัด vCPU แบบเศษส่วนบนเครื่อง 20 cores โดยมีเวลาเริ่มต้นตั้งแต่หนึ่งวินาทีถึงหลายวินาที ขึ้นอยู่กับภาพฐาน
ความสามารถของคลัสเตอร์หลายโหนดที่กล่าวถึงในแผนพัฒนาจะแก้ข้อจำกัดในปัจจุบันของการติดตั้งบนเครื่องเดียว ทำให้ K7 เหมาะสมมากขึ้นสำหรับ workloads ของ AI แบบกระจาย ตัว device-mapper snapshotter พร้อมกับการจัดเตรียม thin-pool ยังแก้ไขข้อกังวลเกี่ยวกับประสิทธิภาพการจัดเก็บข้อมูล ซึ่งมักสร้างปัญหาให้กับโซลูชันที่อิงตาม VM
ในขณะที่ AI agents มีความสามารถมากขึ้นในการสร้างและรันโค้ด ความต้องการโซลูชันการสร้าง sandbox ที่เชื่อถือได้จะเพิ่มขึ้นเท่านั้น การอภิปรายในชุมชนเกี่ยวกับ Katakube K7 แสดงให้เห็นทั้งความตื่นเต้นเกี่ยวกับแนวทางใหม่ๆ และความสำคัญอย่างยิ่งของการทบทวนความปลอดภัยอย่างละเอียด การตอบสนองของโครงการต่อข้อติชมจากชุมชน โดยเฉพาะอย่างยิ่งรอบๆ ช่องโหว่ DNS บ่งชี้ถึงกระบวนการพัฒนาที่ดี แต่ก็เป็นเครื่องเตือนใจว่าความปลอดภัยเป็นการเดินทางที่ต่อเนื่อง ไม่ใช่จุดหมายปลายทาง
อ้างอิง: katakube / k7