Làm thế nào để xử lý các cập nhật bảo mật trong các container Docker?

Khi triển khai các ứng dụng lên các máy chủ, thường có sự tách biệt giữa những gì ứng dụng đi kèm với chính nó và những gì nó mong đợi từ nền tảng (hệ điều hành và các gói đã cài đặt) để cung cấp. Một điểm của điều này là nền tảng có thể được cập nhật độc lập với ứng dụng. Điều này hữu ích, ví dụ khi các cập nhật bảo mật cần được áp dụng khẩn cấp cho các gói được cung cấp bởi nền tảng mà không cần xây dựng lại toàn bộ ứng dụng.

Các cập nhật bảo mật truyền thống đã được áp dụng đơn giản bằng cách thực hiện lệnh quản lý gói để cài đặt các phiên bản cập nhật của gói trên hệ điều hành (ví dụ: "cập nhật yum" trên RHEL). Nhưng với sự ra đời của công nghệ container như Docker trong đó hình ảnh container về cơ bản gói cả ứng dụng và nền tảng, cách thức chính tắc để giữ một hệ thống với các container được cập nhật là gì? Cả máy chủ và bộ chứa đều có các gói riêng, độc lập, cần cập nhật và cập nhật trên máy chủ sẽ không cập nhật bất kỳ gói nào bên trong các thùng chứa. Với việc phát hành RHEL 7 trong đó các container Docker được đặc biệt chú ý, sẽ rất thú vị khi nghe cách khuyến nghị của Redhat để xử lý các cập nhật bảo mật của các container.

Suy nghĩ về một vài lựa chọn:

• Để các gói cập nhật trình quản lý gói trên máy chủ sẽ không cập nhật các gói bên trong các thùng chứa.
• Phải tạo lại tất cả các hình ảnh chứa để áp dụng các bản cập nhật dường như phá vỡ sự tách biệt giữa ứng dụng và nền tảng (cập nhật nền tảng yêu cầu quyền truy cập vào quá trình xây dựng ứng dụng tạo ra hình ảnh Docker).
• Chạy các lệnh thủ công bên trong mỗi container đang chạy có vẻ cồng kềnh và các thay đổi có nguy cơ bị ghi đè trong lần chứa tiếp theo được cập nhật từ các tạo phẩm phát hành ứng dụng.

Vì vậy, không có cách tiếp cận nào có vẻ thỏa đáng.

Một ứng dụng gói hình ảnh Docker và "nền tảng", điều đó là chính xác. Nhưng thông thường hình ảnh bao gồm một hình ảnh cơ sở và ứng dụng thực tế.

Vì vậy, cách chuẩn để xử lý các cập nhật bảo mật là cập nhật hình ảnh cơ sở, sau đó xây dựng lại hình ảnh ứng dụng của bạn.

Các container được cho là nhẹ và có thể thay thế cho nhau. Nếu container của bạn có vấn đề về bảo mật, bạn xây dựng lại một phiên bản của container đã được vá và triển khai container mới. (nhiều container sử dụng hình ảnh cơ sở tiêu chuẩn sử dụng các công cụ quản lý gói tiêu chuẩn như apt-get để cài đặt các phụ thuộc của chúng, việc xây dựng lại sẽ lấy các bản cập nhật từ kho lưu trữ)

Mặc dù bạn có thể vá bên trong các thùng chứa, nhưng điều đó sẽ không có quy mô tốt.

Điều này được xử lý tự động trong SUSE Enterprise Linux bằng cách sử dụng zypper-docker (1)

SUSE / zypper-docker

Docker Bắt đầu nhanh

Trước hết, nhiều bản cập nhật mà bạn thường chạy trong quá khứ sẽ không nằm trong chính container. Container phải là một tập hợp con khá nhẹ và nhỏ của hệ thống tập tin đầy đủ mà bạn quen nhìn thấy trong quá khứ. Các gói bạn cần cập nhật sẽ là những gói là một phần của DockerFile của bạn và vì bạn có DockerFile, bạn sẽ có thể theo dõi các gói và ID container cần cập nhật. Giao diện người dùng của Cloudstein sẽ sớm được phát hành sẽ theo dõi các thành phần DockerFile này cho bạn để người ta có thể xây dựng sơ đồ cập nhật phù hợp nhất cho các thùng chứa của họ. Hi vọng điêu nay co ich

nó thường thậm chí còn tồi tệ hơn ba lựa chọn bạn cung cấp. Hầu hết các hình ảnh docker không được xây dựng với trình quản lý gói, do đó bạn không thể chỉ vào hình ảnh docker và đưa ra bản cập nhật. Bạn sẽ cần phải xây dựng lại hoặc lấy lại hình ảnh docker.

Việc bạn cần xây dựng lại hoặc đang chú ý đến người khác để xây dựng lại cho các bản vá bảo mật có vẻ không hợp lý trong hầu hết các trường hợp.

Tôi đã xem xét việc triển khai sonarr và radarr trong các container docker nhưng biết rằng chúng sẽ không nhận được các bản cập nhật bảo mật thường xuyên mà container của tôi nhận được là một công cụ thỏa thuận. Quản lý cập nhật bảo mật cho container của tôi là đủ rắc rối mà không phải đối phó với việc bằng cách nào đó phải áp dụng thủ công các cập nhật bảo mật cho từng hình ảnh docker riêng lẻ.