Buildpacks giúp doanh nghiệp mở rộng kiểm soát bảo mật container bằng cách chuẩn hóa đầu vào dựng ảnh và áp dụng các thiết lập an toàn mặc định. Công nghệ này còn tạo SBOM và đưa bản vá qua một đường dẫn chung. Buildpacks không thay thế việc kiểm thử, giám sát triển khai hoặc quản lý ngoại lệ. Công nghệ này giảm sự khác biệt giữa các nhóm và làm rõ trách nhiệm vận hành.
Theo bài phân tích của The New Stack, nhiều chương trình bảo mật container thất bại không phải vì thiếu tiêu chuẩn hoặc công cụ quét. Vấn đề thường nằm ở việc mỗi dịch vụ dùng một Dockerfile và một quy trình dựng ảnh khác nhau. Buildpacks tạo một điểm kiểm soát chung cho ảnh dùng khi chạy, danh mục thành phần phần mềm, siêu dữ liệu sản phẩm tạo tác và quy trình cập nhật.
Cloud Native Buildpacks chuyển mã nguồn ứng dụng thành ảnh container theo chuẩn OCI mà không cần Dockerfile. Cách làm này đưa nhiều quyết định bảo mật lặp lại về một nơi chung để doanh nghiệp áp dụng và theo dõi nhất quán.
Bản vá không đến được môi trường vận hành
Bản vá có thể đã xuất hiện trong ảnh nền được phê duyệt nhưng chưa đến mọi khối lượng công việc đang chạy. Dockerfile không đồng nhất và nhịp dựng lại khác nhau làm chậm quá trình này. Dữ liệu kiểm kê thiếu tập trung cũng khiến doanh nghiệp khó xác định dịch vụ chịu ảnh hưởng và mức độ triển khai của bản vá.
Trong tình huống được The New Stack mô tả, quy trình lý tưởng sẽ phát hiện ảnh nền đã vá, dựng lại, kiểm thử, phát hành rồi tự động đưa ảnh mới tới mọi ứng dụng bị ảnh hưởng. Trên thực tế, sau một tuần, một số khối lượng công việc trong môi trường vận hành vẫn có thể chạy trên ảnh nền chứa lỗ hổng.
nội dung kiểm soát và điểm nghẽn triển khai
Một nguyên nhân là sự khác biệt giữa các Dockerfile. Các kho mã có thể dùng thẻ ảnh nền, phiên bản Linux và phiên bản môi trường chạy khác nhau. Một ảnh ứng dụng cũng có thể bắt đầu từ ảnh nền đã vá nhưng cài lại phần phụ thuộc có lỗ hổng do lập trình viên tự thêm gói.
Nhịp dựng lại ảnh cũng không giống nhau giữa các nhóm. Có nhóm dựng thường xuyên, trong khi nhóm khác chỉ thực hiện khi mã ứng dụng thay đổi. Một dịch vụ không có tính năng mới vì thế có thể tiếp tục dùng ảnh cũ trong nhiều tháng.
Nếu thiếu kho kiểm kê tập trung, SBOM, siêu dữ liệu ảnh hoặc dữ liệu theo dõi triển khai, đội bảo mật khó biết ứng dụng nào vẫn dễ bị tấn công và bản vá đã lan tới đâu. Một biện pháp kiểm soát chỉ có giá trị khi được áp dụng nhất quán, quan sát được trong môi trường đang chạy và duy trì được khi ảnh, phần phụ thuộc hoặc lỗ hổng thay đổi.
Quy định mọi dịch vụ phải dùng ảnh nền đã vá chưa đủ để tạo ra kết quả. Doanh nghiệp còn cần một cơ chế vận hành quy định đó trên toàn bộ hệ thống.
Vì sao kiểm soát bảo mật dễ lệch khỏi tiêu chuẩn
Kiểm soát bảo mật dễ lệch khỏi tiêu chuẩn khi mỗi kho mã giao toàn bộ quyết định dựng ảnh cho đội ứng dụng. Dockerfile vẫn có thể tạo ra ảnh nhỏ và được gia cố tốt, nhưng việc lặp lại cùng một quyết định trên hàng trăm kho mã làm tăng khác biệt và kéo dài thời gian đưa bản vá vào vận hành.
Mỗi nhóm phải tự chọn ảnh nền, gói cần cài, tài khoản chạy ứng dụng, kích thước ảnh, cách theo dõi bản vá và chính sách áp dụng trong quy trình tích hợp, phân phối liên tục. Khi số dịch vụ tăng và thành viên thay đổi, các lựa chọn này dần phân kỳ. Khái niệm thế nào là an toàn cũng có thể được hiểu khác nhau giữa các nhóm.
Sự phân tán còn làm chậm quá trình đưa bản vá vào hệ thống. Đội nền tảng có thể phát hành ảnh nền mới, nhưng từng đội ứng dụng vẫn phải nhận ra thay đổi, sửa Dockerfile, dựng lại, kiểm thử và triển khai. Có nhóm xử lý ngay, có nhóm thực hiện muộn và có nhóm bỏ sót. Đây là dạng khó khăn vận hành thường xuất hiện khi một hạ tầng kỹ thuật phải phục vụ nhiều đội và nhiều quy trình.
Từ bản dựng riêng lẻ đến nền tảng có quản trị
Buildpacks chuyển việc tạo ảnh từ một chuỗi quyết định riêng lẻ thành một chức năng nền tảng có quản trị. Đội nền tảng có thể kiểm soát bộ dựng, ảnh nền, buildpack và siêu dữ liệu dùng chung, trong khi đội ứng dụng tiếp tục chịu trách nhiệm về mã, phần phụ thuộc và hành vi của dịch vụ.
Buildpacks phát hiện loại ứng dụng, chọn thành phần dựng phù hợp, cung cấp môi trường chạy cùng các phần phụ thuộc cần thiết rồi tạo ảnh có thể thực thi. Với bảo mật container, lợi ích chính không chỉ là bỏ Dockerfile. Giá trị lớn hơn là hình thành một cách dựng ảnh thống nhất cho những ngăn xếp ứng dụng phổ biến.
Đội nền tảng và đội bảo mật nhờ đó có một điểm chung để thực thi chính sách. Doanh nghiệp không còn phải yêu cầu từng nhóm tự chọn ảnh nền, cấu hình môi trường chạy và quản lý các lớp ảnh. Phần lớn công việc tạo siêu dữ liệu và theo dõi cập nhật có thể được mã hóa trong các bộ dựng và buildpack dùng chung. Việc tạo ảnh đáp ứng quy định trở thành trách nhiệm của nền tảng.
Cloud Native Buildpacks là một dự án đã tốt nghiệp CNCF. Theo The New Stack, đặc tả và bản triển khai tham chiếu của dự án được cộng đồng đánh giá và duy trì dài hạn, phù hợp để làm nền móng cho biện pháp kiểm soát trong doanh nghiệp.
Bốn biện pháp kiểm soát dễ vận hành hơn
Buildpacks giúp doanh nghiệp vận hành bốn nhóm kiểm soát qua một quy trình chung: chuẩn hóa đầu vào dựng ảnh, áp dụng thiết lập bảo mật mặc định, tạo SBOM trong lúc dựng và phân phối bản vá qua bộ dựng, buildpack hoặc ảnh chạy dùng chung.
Chuẩn hóa đầu vào của quá trình dựng ảnh
Bộ dựng là điểm kiểm soát chính trong Cloud Native Buildpacks. Nó đóng gói buildpack, vòng đời xử lý, ảnh nền dùng khi dựng và ảnh nền dùng khi chạy, qua đó xác định cách doanh nghiệp tạo ảnh ứng dụng.
Lập trình viên không tự chọn một ảnh nền bất kỳ trên Docker Hub cho từng ứng dụng. Hệ sinh thái Buildpacks xác định tập ảnh dùng khi dựng và khi chạy. Lập trình viên không thể thay lớp hệ điều hành nền trong một bộ dựng chỉ bằng một dòng mã vì khả năng tương thích không được bảo đảm. Tuy nhiên, họ có thể đổi sang bộ dựng khác bằng một dòng mã mà vẫn nhận được ảnh tương thích và hoạt động được.
Đội phát triển vẫn sử dụng ngôn ngữ và khung phần mềm quen thuộc, còn đội nền tảng tạo ảnh từ một tập bộ dựng đã được phê duyệt. Khi kiểm soát bộ dựng, doanh nghiệp đồng thời kiểm soát buildpack, họ ảnh dùng khi chạy, phiên bản vòng đời và đường dẫn dựng được phép trong quy trình tích hợp, phân phối liên tục. Chính sách được thiết lập ở cấp nền tảng rồi áp dụng cho nhiều dịch vụ.
Áp dụng mặc định các thực hành bảo mật container
Cloud Native Buildpacks áp dụng một số thực hành bảo mật trong quy trình dựng thay vì yêu cầu từng đội cấu hình lại. Mã buildpack chạy bằng tài khoản không có quyền quản trị, môi trường dựng được tách khỏi môi trường chạy và các thay đổi ở cấp hệ điều hành đi qua đầu vào do nền tảng kiểm soát.
Các nền tảng như pack cũng tạo ảnh để ứng dụng chạy bằng tài khoản không có quyền quản trị do ảnh chạy quy định. Thiết lập này làm giảm phạm vi thiệt hại nếu hệ thống bị xâm nhập. Việc thoát khỏi container, sửa hệ thống tệp hoặc lợi dụng quá trình dựng ảnh cũng trở nên khó hơn.
Các lớp bảo vệ trong ảnh
- Buildpacks tách môi trường dựng khỏi môi trường chạy bằng cách đánh dấu lớp chỉ dùng khi dựng và lớp cần khi khởi chạy. Chỉ lớp khởi chạy đi vào ảnh cuối cùng, nên trình biên dịch, công cụ npm và bộ nhớ đệm dựng không xuất hiện trong môi trường vận hành.
- Buildpack hạn chế thay đổi ảnh nền vì không chạy với quyền quản trị. Nó không thể tùy ý cài gói hệ điều hành hoặc sửa hệ thống tệp nền. Thay đổi ở cấp hệ điều hành phải đi qua ảnh dựng, ảnh chạy hoặc phần mở rộng đã được kiểm soát.
- Các giai đoạn vòng đời nhạy cảm có thể chạy tách biệt khỏi giai đoạn thực thi mã khi doanh nghiệp dùng bộ dựng không đáng tin cậy. Buildpack không đáng tin vì thế không nhận được thông tin đăng nhập kho ảnh hoặc quyền truy cập trình nền container.
Một số nhà cung cấp bổ sung lớp bảo vệ riêng. Paketo buildpacks dành cho Spring Boot có ảnh nền không chứa trình bao lệnh. BellSoft cung cấp bộ dựng được gia cố cho Paketo buildpacks dựa trên BellSoft Hardened Images. Những mặc định này giảm công việc thủ công và đưa bảo mật vào quy trình tạo ảnh thông thường.
Tạo danh mục thành phần phần mềm ngay khi dựng
Cloud Native Buildpacks tạo SBOM cho các phần phụ thuộc mà buildpack cung cấp. Dữ liệu kiểm kê được sinh ra trong quá trình dựng, giúp đội nền tảng và bảo mật theo dõi thành phần ảnh mà không phụ thuộc vào một hồ sơ được cập nhật thủ công.
SBOM liệt kê các thành phần có trong ứng dụng hoặc ảnh. Dữ liệu này phục vụ theo dõi lỗ hổng, rà soát giấy phép và kiểm toán. Nhiều quy định cũng yêu cầu doanh nghiệp duy trì SBOM.
Nếu mỗi nhóm thêm bước tạo SBOM riêng vào quy trình tích hợp liên tục, họ có thể dùng công cụ, định dạng, quy tắc lưu trữ và cách phân công trách nhiệm khác nhau. Độ bao phủ vì thế không đồng đều khi số kho mã tăng.
Cloud Native Buildpacks phát SBOM ở các định dạng như CycloneDX, SPDX hoặc Syft JSON. Với một dịch vụ Java điển hình, SBOM có thể ghi phiên bản JRE, phiên bản Spring Boot và các thư viện chính được đưa vào lúc dựng. Với dịch vụ Node.js, danh mục có thể bao gồm phiên bản môi trường chạy Node.js và những phần phụ thuộc npm quan trọng.
Nội dung cụ thể thay đổi theo ứng dụng, nhưng dữ liệu luôn xuất phát từ quá trình dựng. Đội nền tảng và bảo mật nhờ đó nhận được dữ liệu kiểm kê ảnh theo một cách nhất quán hơn.
Đưa bản vá đến nhiều dịch vụ theo đường dẫn chung
Buildpacks tập trung đường đi của bản vá qua bộ dựng, buildpack và ảnh chạy dùng chung. Đội nền tảng cập nhật đầu vào chung, sau đó đổi nền hoặc dựng lại các ảnh bị ảnh hưởng thay vì chờ từng đội ứng dụng lặp lại cùng một thay đổi.
Đổi nền là một khả năng quan trọng trong quy trình này. Khi có bản sửa lỗi ở cấp hệ điều hành, doanh nghiệp có thể thay các lớp nền dùng khi chạy bằng lớp từ ảnh chạy mới hơn mà không phải dựng lại ứng dụng từ mã nguồn. Các công cụ Kubernetes như kpack có thể theo dõi tài nguyên ảnh và kích hoạt dựng lại khi mã nguồn, bộ dựng, buildpack hoặc ngăn xếp thay đổi.
Đổi nền chỉ cập nhật những lớp thuộc ảnh chạy. Phần phụ thuộc do buildpack thêm vào, chẳng hạn JRE hoặc môi trường chạy Node.js, thường cần được dựng lại bằng buildpack hoặc phiên bản phần phụ thuộc mới. Với dịch vụ Node.js, quá trình dựng lại có thể lấy phiên bản môi trường chạy mới cùng các gói npm đã cập nhật, chứ không chỉ thay ảnh hệ điều hành.
Đây không phải cơ chế vá tự động không cần giám sát. Doanh nghiệp vẫn phải kiểm thử, triển khai theo từng giai đoạn và xử lý ngoại lệ. Buildpacks tạo một đường truyền bản vá tập trung hơn và có thể lặp lại trên toàn bộ tập ảnh.
Đường đi mới của bản vá sau khi dùng Buildpacks
Sau khi triển khai Buildpacks, quá trình khắc phục bắt đầu từ đầu vào dựng dùng chung. Đội nền tảng cập nhật ảnh chạy, bộ dựng hoặc buildpack đã được phê duyệt; ảnh sau đó được đổi nền hoặc dựng lại tùy theo thành phần chứa lỗ hổng.
Nếu lỗi nằm trong các lớp hệ điều hành của ảnh chạy, doanh nghiệp có thể đổi nền. Nếu thành phần chịu ảnh hưởng là JRE, môi trường chạy Node.js hoặc phần phụ thuộc của ứng dụng, ảnh thường phải được dựng lại.
Buildpacks không loại bỏ yêu cầu kiểm thử và kiểm soát triển khai. Đội ứng dụng vẫn quản lý mã, phần phụ thuộc và kiểm thử tương thích. Đội vận hành độ tin cậy tiếp tục đưa ảnh qua các môi trường, triển khai, giám sát và quay lui khi cần. Việc xác định rõ quyền hạn cũng quan trọng như trong các hệ thống nơi doanh nghiệp phải quyết định một thành phần tự động nên được trao bao nhiêu quyền.
Phân công trách nhiệm trên đường đi của bản vá
| Bộ phận | Trách nhiệm |
|---|---|
| Nền tảng | Bộ dựng, ảnh chạy, buildpack và tự động hóa dựng lại |
| Bảo mật | Chính sách lỗ hổng và quy tắc ngoại lệ |
| Đội ứng dụng | Mã, phần phụ thuộc và kiểm thử tương thích |
| Vận hành độ tin cậy | Đưa ảnh qua môi trường, triển khai, giám sát và quay lui |
| Tuân thủ | Bằng chứng kiểm toán và thời hạn lưu giữ |
Sự thay đổi quan trọng nhất nằm ở quyền sở hữu đường đi của bản vá. Đội nền tảng duy trì đầu vào dựng và tự động hóa. Đội bảo mật đặt chính sách quét cùng quy tắc ngoại lệ. Bộ phận tuân thủ xác định bằng chứng phải được giữ lại. Cách phân công này giúp yêu cầu bảo mật xuất hiện sớm hơn trong vòng đời phát triển thay vì chỉ được kiểm tra trước khi triển khai.
Buildpacks không buộc doanh nghiệp bỏ Dockerfile
Buildpacks và Dockerfile có thể cùng tồn tại trong một chiến lược ảnh có quản trị. Buildpacks phù hợp với các ngăn xếp có thể chuẩn hóa, còn Dockerfile hoặc buildpack riêng vẫn phục vụ những khối lượng công việc cần ảnh tùy chỉnh.
Khi cần, đội nền tảng có thể tạo buildpack riêng và mở rộng ảnh nền dùng khi dựng bằng Dockerfile. Mục tiêu là quản lý ngoại lệ qua một quy trình rõ ràng, không phải áp dụng một mô hình cứng nhắc chỉ cho phép Buildpacks.
Buildpacks cung cấp một cách dựng ảnh container chung thay vì để mỗi kho mã tự định nghĩa toàn bộ quy trình. Ảnh được phê duyệt, thiết lập an toàn mặc định, SBOM và quy trình vá nhờ đó dễ áp dụng trên nhiều dịch vụ hơn. Doanh nghiệp vẫn cần kiểm thử, theo dõi triển khai và xử lý ngoại lệ, nhưng độ lệch giữa các nhóm giảm xuống và trách nhiệm trở nên rõ ràng hơn.
Doanh nghiệp có thể bắt đầu đánh giá Buildpacks trên một dịch vụ phù hợp, sau đó so sánh quy trình dựng, kiểm thử và đưa bản vá với cách dùng Dockerfile hiện tại.
