gVisor của Google , một sandbox runtime container hứa hẹn tăng cường bảo mật thông qua mô phỏng kernel, đang gặp khó khăn trong việc đạt được sự chấp nhận rộng rãi bất chấp cách tiếp cận sáng tạo đối với việc cô lập container. Công nghệ này, hoạt động như một kernel hệ điều hành trung gian giữa các container và hệ thống host, đã thấy kết quả trái chiều trong các triển khai thực tế.
So sánh bảo mật giữa gVisor và Container truyền thống:
- Docker truyền thống: Chia sẻ trực tiếp kernel của host, dễ bị tổn thương trước các lỗ hổng kernel như CVE-2019-5736
- gVisor: Chặn các system call thông qua thành phần "Sentry", giảm thiểu việc tiếp xúc với kernel của host
- Bề mặt tấn công: gVisor triển khai một tập con các system call của Linux bằng ngôn ngữ Go an toàn về bộ nhớ
- Cách ly: Để thoát khỏi gVisor cần phải xâm phạm cả lớp ứng dụng và lớp Sentry
 |
|---|
| Phiên terminal này minh họa sự tương tác giữa các container Docker và hệ điều hành máy chủ, phản ánh sự phức tạp của các container runtime như gVisor |
Các Dịch Vụ Cloud Lớn Rời Bỏ gVisor
Một số dịch vụ Google Cloud nổi tiếng đã rút lui khỏi việc triển khai gVisor . Google Cloud Functions và Cloud Run đều bắt đầu với sandbox gVisor nhưng sau đó đã chuyển sang runtime gen2 khởi động máy ảo đầy đủ thay thế. Những thủ phạm chính đằng sau các cuộc di chuyển này là hiệu suất đầu vào/đầu ra kém và thiếu các system call khiến hành vi ứng dụng trở nên không thể dự đoán trước khi triển khai.
Mô hình này mở rộng ra ngoài các dịch vụ của chính Google . Sự chuyển đổi này phản ánh cách tiếp cận của Microsoft với Windows Subsystem for Linux , đã chuyển từ cách tiếp cận lớp dịch thuật của WSL 1 sang mô hình ảo hóa đầy đủ của WSL 2 . Chủ đề lặp lại gợi ý những thách thức cơ bản trong việc sao chép chức năng kernel Linux hoàn chỉnh thông qua mô phỏng.
Các Dịch Vụ Lớn Chuyển Đổi Khỏi gVisor:
- Google Cloud Run: Chuyển từ gVisor sang runtime dựa trên VM gen2
- Google Cloud Functions: Chuyển đổi từ sandbox gVisor sang máy ảo đầy đủ
- Windows WSL: Mô hình tương tự - WSL 1 (lớp dịch thuật) sang WSL 2 (VM đầy đủ)
- Lý do: Các vấn đề về hiệu suất I/O và hành vi ứng dụng không thể dự đoán do thiếu syscalls
Đánh Đổi Hiệu Suất Hạn Chế Các Trường Hợp Sử Dụng Thực Tế
Thảo luận cộng đồng tiết lộ rằng lợi ích bảo mật của gVisor đi kèm với chi phí hiệu suất đáng kể. Các ứng dụng thực hiện các thao tác file thường xuyên hoặc các tác vụ đầu vào/đầu ra chuyên sâu gặp phải sự chậm lại đáng chú ý do lớp trừu tượng bổ sung. Mỗi system call phải đi qua thành phần Sentry của gVisor trước khi đến kernel host, tạo ra overhead mà nhiều workload sản xuất không thể chịu đựng.
Hiệu suất I/O kém và một vài syscall bị thiếu khiến việc dự đoán cách ứng dụng của bạn sẽ hoạt động trước khi triển khai trở nên khó khăn.
Bất chấp những hạn chế này, gVisor đã tìm thấy thành công trong các lĩnh vực cụ thể. Kythe semantic indexer nội bộ của Google sử dụng gVisor để xử lý nhiều ngôn ngữ lập trình, và công nghệ này đã chứng minh giá trị cho các hệ thống multi-tenant nơi bảo mật được ưu tiên hơn hiệu suất thô.
 |
|---|
| Đầu ra terminal này minh họa một container gVisor đang thực thi một ứng dụng đơn giản, làm nổi bật những thách thức về hiệu suất trong các triển khai thực tế |
Hạn Chế Kỹ Thuật So Với Máy Ảo
Không giống như máy ảo truyền thống, gVisor hoạt động như một proxy system call thay vì cơ chế ảo hóa thực sự. Lựa chọn kiến trúc này tạo ra một số ràng buộc hạn chế khả năng ứng dụng của nó. Công nghệ này không thể hỗ trợ các tính năng confidential computing như mã hóa bộ nhớ, và một số trường hợp biên trong việc xử lý system call vẫn còn vấn đề.
Tuy nhiên, gVisor cung cấp những lợi thế độc đáo trong các tình huống cụ thể. Nó có thể chặn một số lỗ hổng kernel sẽ ảnh hưởng đến máy ảo, và thiết kế modular của nó đã cho phép các dự án khác trích xuất các thành phần hữu ích, đặc biệt là networking stack userspace.
Các thành phần kiến trúc gVisor:
- Sentry: Thành phần cốt lõi chặn và xử lý các lệnh gọi hệ thống
- Runtime: Sử dụng seccomp-bpf để có các chính sách bảo mật chặt chẽ hơn so với các kernel thông thường
- Ngôn ngữ: Được viết bằng Go để đảm bảo an toàn bộ nhớ, tránh các lỗ hổng kernel dựa trên C
- Mạng: Ngăn xếp mạng hoàn chỉnh trong không gian người dùng có sẵn như một thành phần độc lập
Kết Luận
Trong khi gVisor đại diện cho một cách tiếp cận sáng tạo đối với bảo mật container, việc áp dụng nó đã bị cản trở bởi các vấn đề hiệu suất và coverage system call không đầy đủ. Công nghệ này có vẻ phù hợp nhất cho các trường hợp sử dụng chuyên biệt nơi yêu cầu bảo mật vượt trội hơn mối quan tâm về hiệu suất, thay vì như một sự thay thế container runtime đa mục đích. Khi các nhà cung cấp cloud lớn tiếp tục ưa chuộng các giải pháp ảo hóa đầy đủ, tương lai của gVisor có thể nằm trong các ứng dụng ngách thay vì điều phối container chính thống.
Tham khảo: What is gVisor?