gVisor ของ Google ซึ่งเป็น container runtime sandbox ที่สัญญาว่าจะเพิ่มความปลอดภัยผ่านการจำลอง kernel กำลังประสบปัญหาในการได้รับการยอมรับอย่างกว้างขวาง แม้จะมีแนวทางที่เป็นนวัตกรรมในการแยก container ก็ตาม เทคโนโลยีนี้ซึ่งทำหน้าที่เป็น kernel ของระบบปฏิบัติการตัวกลางระหว่าง container และระบบโฮสต์ ได้เห็นผลลัพธ์ที่หลากหลายในการนำไปใช้งานจริง
การเปรียบเทียบความปลอดภัยระหว่าง gVisor กับ Traditional Containers:
- Traditional Docker: ใช้ host kernel ร่วมกันโดยตรง เสี่ยงต่อการถูกโจมตีผ่าน kernel exploits เช่น CVE-2019-5736
- gVisor: สกัดกั้น system calls ผ่านส่วนประกอบ "Sentry" ช่วยลดการเปิดรับ host kernel
- Attack Surface: gVisor ใช้งาน subset ของ Linux system calls ในภาษา Go ที่ปลอดภัยต่อหน่วยความจำ
- Isolation: การหลุดออกจาก gVisor ต้องทำลายทั้งชั้น application และ Sentry
 |
|---|
| เซสชันเทอร์มินัลนี้แสดงให้เห็นการปฏิสัมพันธ์ระหว่าง Docker containers และระบบปฏิบัติการโฮสต์ สะท้อนถึงความซับซ้อนของ container runtimes อย่าง gVisor |
บริการ Cloud หลักๆ ย้ายออกจาก gVisor
บริการ Google Cloud หลายรายการที่มีชื่อเสียงได้ถอยออกจากการใช้งาน gVisor Google Cloud Functions และ Cloud Run ทั้งคู่เริ่มต้นด้วย gVisor sandbox แต่ได้ย้ายไปใช้ gen2 runtime ที่บูต virtual machine เต็มรูปแบบแทน สาเหตุหลักของการย้ายครั้งนี้คือประสิทธิภาพ input/output ที่แย่และ system call ที่หายไปซึ่งทำให้พฤติกรรมของแอปพลิเคชันไม่สามารถคาดเดาได้ก่อนการ deploy
รูปแบบนี้ขยายไปเกินกว่าบริการของ Google เอง การเปลี่ยนแปลงนี้สะท้อนแนวทางของ Microsoft กับ Windows Subsystem for Linux ซึ่งย้ายจากแนวทาง translation layer ของ WSL 1 ไปสู่โมเดล full virtualization ของ WSL 2 ธีมที่เกิดขึ้นซ้ำแล้วซ้ำเล่าแสดงให้เห็นความท้าทายพื้นฐานในการจำลองฟังก์ชันการทำงานของ Linux kernel ที่สมบูรณ์ผ่านการจำลอง
การย้ายบริการหลักออกจาก gVisor :
- Google Cloud Run: ย้ายจาก gVisor ไปใช้ gen2 VM-based runtime
- Google Cloud Functions: เปลี่ยนจาก gVisor sandboxes ไปใช้ virtual machines แบบเต็มรูปแบบ
- Windows WSL: รูปแบบที่คล้ายกัน - WSL 1 (translation layer) ไป WSL 2 (full VM)
- เหตุผล: ปัญหาประสิทธิภาพ I/O และพฤติกรรมของแอปพลิเคชันที่คาดเดาไม่ได้เนื่องจาก syscalls ที่ขาดหายไป
การแลกเปลี่ยนประสิทธิภาพจำกัดกรณีการใช้งานจริง
การอพิพากษาของชุมชนเผยให้เห็นว่าประโยชน์ด้านความปลอดภัยของ gVisor มาพร้อมกับต้นทุนประสิทธิภาพที่สำคัญ แอปพลิเคชันที่ทำการดำเนินการไฟล์บ่อยครั้งหรืองาน input/output ที่เข้มข้นจะประสบกับการชะลอตัวที่เห็นได้ชัดเนื่องจากชั้น abstraction เพิ่มเติม system call ทุกตัวต้องผ่าน Sentry component ของ gVisor ก่อนที่จะไปถึง host kernel ซึ่งสร้าง overhead ที่ workload การผลิตหลายรายการไม่สามารถทนได้
ประสิทธิภาพ I/O ที่แย่และ syscall ที่หายไปสองสามตัวทำให้ยากที่จะคาดเดาว่าแอปของคุณจะทำงานอย่างไรก่อนที่คุณจะ deploy
แม้จะมีข้อจำกัดเหล่านี้ gVisor ก็ประสบความสำเร็จในช่องทางเฉพาะ Kythe semantic indexer ภายในของ Google ใช้ gVisor สำหรับการประมวลผลภาษาโปรแกรมหลายภาษา และเทคโนโลยีนี้ได้พิสูจน์แล้วว่ามีค่าสำหรับระบบ multi-tenant ที่ความปลอดภัยมีความสำคัญมากกว่าประสิทธิภาพดิบ
 |
|---|
| ผลลัพธ์ terminal นี้แสดงให้เห็น container ของ gVisor ที่กำลังรันแอปพลิเคชันง่าย ๆ เพื่อเน้นย้ำถึงความท้าทายด้านประสิทธิภาพในการใช้งานจริง |
ข้อจำกัดทางเทคนิคเมื่อเปรียบเทียบกับ Virtual Machine
ไม่เหมือนกับ virtual machine แบบดั้งเดิม gVisor ทำงานเป็น system call proxy มากกว่าที่จะเป็นกลไก virtualization ที่แท้จริง ตัวเลือกทางสถาปัตยกรรมนี้สร้างข้อจำกัดหลายประการที่จำกัดการใช้งาน เทคโนโลยีนี้ไม่สามารถรองรับคุณสมบัติ confidential computing เช่น memory encryption และกรณีขอบบางกรณีในการจัดการ system call ยังคงมีปัญหา
อย่างไรก็ตาม gVisor มีข้อได้เปรียบที่เป็นเอกลักษณ์ในสถานการณ์เฉพาะ สามารถบล็อกช่องโหว่ kernel บางตัวที่จะส่งผลกระทบต่อ virtual machine และการออกแบบแบบโมดูลาร์ได้เปิดใช้งานโปรเจกต์อื่นๆ ในการดึงส่วนประกอบที่มีประโยชน์ โดยเฉพาะ userspace networking stack
องค์ประกอบสถาปัตยกรรม gVisor :
- Sentry: องค์ประกอบหลักที่ดักจับและจัดการ system calls
- Runtime: ใช้ seccomp-bpf เพื่อนโยบายความปลอดภัยที่เข้มงวดกว่า kernel ทั่วไป
- Language: เขียนด้วย Go เพื่อความปลอดภัยของหน่วยความจำ หลีกเลี่ยงช่องโหว่ของ kernel ที่ใช้ C
- Networking: มี networking stack แบบ userspace ที่สมบูรณ์พร้อมใช้เป็นองค์ประกอบแยกต่างหาก
บทสรุป
ในขณะที่ gVisor แสดงถึงแนวทางที่เป็นนวัตกรรมสำหรับความปลอดภัยของ container การยอมรับของมันถูกขัดขวางโดยปัญหาประสิทธิภาพและการครอบคลุม system call ที่ไม่สมบูรณ์ เทคโนโลยีนี้ดูเหมือนจะเหมาะสมที่สุดสำหรับกรณีการใช้งานเฉพาะทางที่ความต้องการด้านความปลอดภัยมีน้ำหนักมากกว่าข้อกังวลด้านประสิทธิภาพ มากกว่าที่จะเป็นการทดแทน container runtime ที่ใช้งานทั่วไป เมื่อผู้ให้บริการ cloud หลักๆ ยังคงให้ความสำคัญกับโซลูชัน full virtualization อนาคตของ gVisor อาจอยู่ในแอปพลิเคชันเฉพาะทางมากกว่า container orchestration กระแสหลัก
อ้างอิง: What is gVisor?