Bottlerocket - Hệ điều hành Linux tối giản, bất biến với cơ chế khởi động đã xác minh
(bottlerocket.dev)- Bottlerocket là hệ điều hành dựa trên Linux được thiết kế cho việc host container, dùng làm hệ điều hành nền tảng cho các nút worker trong cụm do các orchestrator như Kubernetes quản lý
- Với cấu hình tối giản loại bỏ bớt các gói, công cụ và trình thông dịch của các bản phân phối đa dụng, Bottlerocket giảm gánh nặng vận hành và bề mặt tấn công, đồng thời chỉ cung cấp các tổ hợp cần thiết theo từng variant môi trường
- Không có shell hay trình quản lý gói; hệ thống được thao tác thông qua các host container có đặc quyền và API, còn cập nhật được áp dụng theo cách nguyên tử bằng ảnh và chuyển đổi phân vùng
- Cấu hình được quản lý dựa trên API, cho phép migration và rollback giữa các phiên bản; việc quản lý cập nhật có thể thực hiện thủ công hoặc bằng công cụ riêng cho từng orchestrator
- Hệ thống tệp gốc bất biến, dm-verity, SELinux hạn chế, cùng việc triển khai bằng Rust và một phần Golang giúp giảm nguy cơ sửa đổi hệ thống và các đường dẫn thực thi mã chưa được xác minh
Hệ điều hành nền tảng cho cụm container
- Bottlerocket là hệ điều hành dựa trên Linux được tối ưu hóa cho việc host container
- Đây là phần mềm mã nguồn mở miễn phí và được phát triển công khai trên GitHub
- Được cài làm hệ điều hành nền tảng trên máy hoặc instance nơi container chạy
- Được thiết kế để hoạt động cùng các container orchestrator như Kubernetes, hỗ trợ tự động hóa vòng đời container trong cụm
- Có thể chạy trên cloud và trong trung tâm dữ liệu
- Mục tiêu thiết kế được tóm gọn trong ba điểm: Minimal, Safe Updates, Security Focused
Cấu hình tối giản và variant theo từng môi trường
- Vì chỉ nhắm đến việc host container, Bottlerocket loại bỏ nhiều gói, công cụ, trình thông dịch và phụ thuộc thường được bao gồm mặc định trong các bản phân phối Linux đa dụng
- Khi phần mềm không cần thiết giảm đi, chi phí vận hành và chi phí bảo mật cũng giảm theo
- Các yêu cầu khác nhau về orchestrator, nền tảng và kiến trúc được quản lý bằng variant, tức các bản build theo từng tổ hợp tương thích
- variant là dạng lắp ghép các thành phần cần thiết để chạy trong một môi trường cụ thể
- Khi chọn variant phù hợp, không cần thêm thành phần bổ sung để join vào cụm
- Bản thân Bottlerocket không có shell
- Có thể truy cập hệ thống thông qua host container có đặc quyền và có shell
- Trong host container, có thể khám phá hệ điều hành nền tảng và thay đổi cấu hình hệ thống đang chạy thông qua API
Cập nhật an toàn dựa trên image
- Bottlerocket được thiết kế để có thể cập nhật, nhưng không bao gồm trình quản lý gói
- Cập nhật được phân phối dưới dạng image tải xuống một phân vùng cụ thể
- Khi cập nhật, orchestrator drain nút rồi chỉ thị Bottlerocket áp dụng cập nhật và khởi động lại
- Bottlerocket thay thế phân vùng và khởi động nguyên tử vào phiên bản mới
- Cấu hình hệ thống được quản lý qua API, cho phép Bottlerocket xử lý migration cấu hình giữa các phiên bản
- Nếu có sự cố trong quá trình cập nhật, có thể quay lại phiên bản từng hoạt động trước đó mà vẫn giữ nguyên cấu hình
- Có thể quản lý cập nhật thủ công hoặc dùng công cụ riêng cho từng orchestrator
Thiết kế tập trung vào bảo mật
- Cấu hình tối giản và phương thức cập nhật hỗ trợ cho thiết kế tập trung vào bảo mật của Bottlerocket
- Vì variant được phân phối dưới dạng image, không cần registry gói hay trình quản lý gói có thể làm thay đổi hệ thống và tạo ra vấn đề bảo mật
- Các tính năng riêng của Bottlerocket được viết bằng Rust và một phần Golang
- Cả hai đều là ngôn ngữ biên dịch và cung cấp cơ chế bảo vệ tích hợp trước các vấn đề an toàn bộ nhớ
- Toàn bộ mã được phân phối dưới dạng image đã biên dịch sẵn, nên không cần shell hay trình thông dịch, qua đó giảm các đường dẫn thực thi mã chưa được xác minh
- Hệ thống tệp gốc là bất biến
- dm-verity cung cấp kiểm tra tính toàn vẹn minh bạch cho hệ thống tệp gốc
- Nếu phát hiện thay đổi trên block device nền tảng, kernel sẽ khởi động lại
- Các hệ thống tệp có thể thay đổi luôn áp dụng chính sách SELinux hạn chế, được bật và thực thi bắt buộc
- Đây là chính sách giúp ngăn container thực hiện các thao tác nguy hiểm ngay cả khi container chạy với quyền root
1 bình luận
Các ý kiến trên Hacker News
Vẫn mang đậm tính chất một dự án của AWS/Amazon, và có vẻ chưa có lộ trình rõ ràng để trở thành một dự án độc lập
Ví dụ, nếu cần quét lỗ hổng OS thì dùng sản phẩm của Amazon là được, còn không thì cách làm khá mơ hồ https://bottlerocket.dev/en/faq/#4_2
Nếu chỉ định chạy Bottlerocket trên AWS thì ổn, nhưng nếu muốn trở thành một sản phẩm “chạy trên đám mây hoặc trong trung tâm dữ liệu” như website nói, thì cần giải quyết những điểm này
Nếu muốn biết đã được vá hay chưa, chỉ cần xem có đang chạy phiên bản mới nhất không; nếu là mới nhất thì mọi bản vá khả dụng đều đã được áp dụng
Tuy vậy, trong các ngành chịu quản lý, điều này có thể thành vấn đề vì phải điền mục “quản lý lỗ hổng” trong checklist tuân thủ
Lý do lớn khiến OS truyền thống cần quản lý lỗ hổng là không gian cấu hình rất rộng, cấu hình phần mềm bị trộn tùy ý từ nhiều nguồn và nhà cung cấp, và từng phiên bản lại dịch chuyển độc lập
Nhưng container OS không phải thứ được dùng theo cách đó
Việc tiếp tục tìm thêm lỗ hổng trong bản “latest” gần với công việc của nhà nghiên cứu bảo mật hơn là việc chủ sở hữu hệ thống áp dụng kịp thời các bản vá upstream
Đây là dự án còn lâu đời hơn Bottlerocket
Nếu có cách vào bằng SSM hoặc dùng admin container để chạy quét, thì chẳng phải có thể làm theo cùng kiểu sao? Đây chỉ là câu hỏi thuần túy
Đó là việc có thể làm trước khi triển khai image lên máy host
Khác với hầu hết các bản phân phối *nix cho doanh nghiệp, Bottlerocket không cung cấp chế độ FIPS
Nếu bạn đang dùng chương trình tuân thủ yêu cầu mã hóa được FIPS phê duyệt cho host OS phục vụ công việc, thì hãy tiết kiệm thời gian
Vì lý do này, Bottlerocket không phải lựa chọn với chúng tôi; issue liên quan đã mở và hoạt động hơn 2 năm, nhưng đội phát triển có vẻ không tin rằng nó quan trọng
Chúng tôi cũng đã nói chuyện với đội phát triển thông qua đầu mối phụ trách riêng của AWS, nhưng có vẻ họ không có ý định bổ sung
Thread đã mở hơn 2 năm ở đây: https://github.com/bottlerocket-os/bottlerocket/issues/1667
Hỗ trợ FIPS vẫn là yêu cầu số 1 áp đảo từ khách hàng
Tuy nhiên, đây là thời điểm không thuận lợi cho một bản phân phối mới chưa từng có lịch sử cung cấp FIPS
Các chứng nhận FIPS 140-2 mới không còn được cấp nữa, còn chứng nhận FIPS 140-3 mới thì cả ngành đang trong quá trình chuyển đổi nên phải qua hàng đợi dài
Nếu đây là việc đội phát triển có thể tự thúc đẩy để giải quyết thì nó đã xong rồi
Tôi xin lỗi nếu đã tạo ấn tượng rằng việc này không quan trọng; thực tế là nó quan trọng, nhưng trong trường hợp này điều đó không giúp được cho lịch trình
Nếu cần thì đành chịu, nhưng cá nhân tôi xem việc có chứng nhận này là một tín hiệu hơi xấu
Suy nghĩ này không chỉ riêng tôi; đội Microsoft Windows dường như cũng nhìn nhận tương tự: https://techcommunity.microsoft.com/t5/microsoft-security-ba...
Ngay cả khi bản thân FIPS không xấu, cũng cần nhớ rằng nó vận hành trong môi trường xấu và cùng những con người xấu https://threadreaderapp.com/thread/1433451378391883782.html
Trông rất thú vị, nhưng như các bình luận khác, đường dẫn để tự chạy trực tiếp có vẻ mờ nhạt
Trang GitHub cũng chỉ được đưa lên trang chính
Tôi tìm thấy hướng dẫn VMware ở đây: https://github.com/bottlerocket-os/bottlerocket/blob/develop...
Rất giống định hướng của CoreOS https://fedoraproject.org/coreos/
Không thấy cách chạy ở bất kỳ đâu trong “Get Started” hay FAQ
Đây là một dự án tốt, nhưng đã có từ năm 2020: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...
Tò mò không biết có ai dùng thành công thứ này bên ngoài AWS không
Có vẻ khá hữu ích cho các mục đích như AMD SEV-SNP
Vì để đảm bảo một hành vi cụ thể của máy, cần có các phép đo cho kernel + initrd + tham số
Lý tưởng là dùng nó như một container hypervisor, và có thể tạo ra attestation gắn với hash của container đang chạy
Tuy nhiên cần đảm bảo không có container escape, mà tôi không rõ hiện trạng mới nhất của lĩnh vực này bây giờ ra sao
Tôi thà dùng CoreOS hơn
Có thứ open source nào do họ phát hành được dùng rộng rãi bên ngoài AWS không?
Website nói rằng OS này không có shell
Tôi khó hình dung một Docker container hữu ích mà không có ít nhất một shell script
Vậy việc không có shell chẳng phải có nghĩa là Bottlerocket về cơ bản không dùng được, ngoại trừ vài kịch bản ngách hay sao?
Thứ không có shell là máy host, và nếu lấy một Docker container có shell rồi chạy nó với đặc quyền, bạn có thể dùng shell trên host
Việc cung cấp binary shell của máy host cho container đang chạy trên host không phải là cách làm phổ biến
Thay vào đó, trách nhiệm này được ủy quyền cho admin container, và việc kết nối thực tế sẽ vào đó qua SSM/SSH
Nếu cần root shell ở đây thì có thể dùng tiện ích
sheltieVí dụ có distroless
shells | containers | Bottlerocket | OS kernel