Bạn có thể chạy Docker trong sản xuất trong nhiều tháng mà không gặp vấn đề gì rõ ràng. Vùng chứa bắt đầu, ứng dụng phản hồi, không có gì bị hỏng. Sau đó, một cổng bị lộ hoặc một quyền bị định cấu hình sai sẽ tạo ra chỗ đứng mà kẻ tấn công không cần phải giành được. Hầu hết các lỗi bảo mật của Docker không giống như lỗi cho đến khi có sự cố xảy ra.
Bài viết này đề cập đến các cấu hình cụ thể khiến môi trường vùng chứa gặp rủi ro, mỗi cấu hình kích hoạt những gì cho kẻ tấn công và kết thúc bằng danh sách kiểm tra mà bạn có thể chạy theo thiết lập của riêng mình ngay hôm nay.
Tại sao bảo mật Docker lại khó hơn vẻ ngoài của nó
Container cảm thấy bị cô lập. Bạn khởi động một cái, nó chạy không gian xử lý riêng và từ bên trong nó, vùng chứa tiếp theo không tồn tại. Bạn sẽ bị cô lập, nhưng đó chỉ là một phần. Các bộ chứa chia sẻ hạt nhân của máy chủ, có nghĩa là một tiến trình bên trong bộ chứa có thể, trong những điều kiện cụ thể, tiếp cận toàn bộ hệ thống máy chủ.
Tàu Docker được cấu hình để thuận tiện cho nhà phát triển chứ không phải tăng cường sản xuất. Truy cập root được bật. Tất cả các cổng đều có thể liên kết với tất cả các giao diện. Không có giám sát thời gian chạy. Hầu hết các nhà phát triển đều chấp nhận các cài đặt đó, gửi vùng chứa và tiếp tục. Đó là một cách tiếp cận hợp lý để bắt đầu; nó không phải là một tư thế bảo mật hoàn chỉnh.
Theo Báo cáo về tình trạng bảo mật Kubernetes năm 2024 của Red Hat, 67% tổ chức đã trì hoãn hoặc làm chậm quá trình triển khai ứng dụng do lo ngại về bảo mật vùng chứa hoặc Kubernetes. Sự xích mích đó thường không phải từ các cuộc tấn công. Đó là do các nhóm phát hiện ra rằng thiết lập vùng chứa của họ cần được tăng cường mà họ chưa tích hợp sẵn.
Chúng tôi thường thấy các container đang chạy trong phiên bản chính thức có cùng cấu hình như trên máy cục bộ của nhà phát triển. Đó là nơi các lỗi bảo mật của Docker có xu hướng diễn ra một cách âm thầm, không có triệu chứng rõ ràng nào cho đến khi một cái gì đó được kiểm tra hoặc bị lỗi.
Những sai lầm tạo ra những khoảng trống đó là cụ thể, có thể dự đoán được và hầu hết có thể tránh được, bắt đầu từ cấp độ cấu hình.
Các lỗi cấu hình Docker phổ biến
Hầu hết các vi phạm vùng chứa không bắt đầu bằng việc khai thác zero-day. Họ bắt đầu với việc thiết lập cấu hình vào ngày đầu tiên mà không cần suy nghĩ nhiều về khả năng hiển thị mạng hoặc phạm vi đặc quyền.
Cài đặt Docker mặc định được xây dựng để hoạt động. Khoảng cách giữa chức năng và bảo mật là nơi tích lũy rủi ro bảo mật vùng chứa Docker, đặc biệt là trong các thiết lập tự lưu trữ được triển khai và không bao giờ được xem lại.
Chúng tôi thường thấy mô hình này: các vùng chứa trên máy chủ IP công cộng có liên kết cổng, cài đặt người dùng và cấu hình mạng chính xác như lúc triển khai ban đầu.
Chạy container dưới dạng root
Khi bạn khởi động vùng chứa Docker mà không chỉ định người dùng, nó sẽ chạy dưới quyền root. Điều đó có nghĩa là bất kỳ quy trình nào bên trong vùng chứa, bao gồm cả ứng dụng của bạn, đều có các đặc quyền cấp gốc trong không gian tên của vùng chứa.
Root bên trong vùng chứa không giống như root trên máy chủ nhưng sự phân tách không tuyệt đối. Các hoạt động khai thác leo thang đặc quyền nhắm mục tiêu vào thời gian chạy, chẳng hạn như runc CVE-2019-5736 được ghi chép đầy đủ và các lỗi thời gian chạy tương tự, thường yêu cầu quy trình vùng chứa gốc để thành công.
Các bộ chứa không phải gốc loại bỏ yêu cầu của quy trình gốc mà các hoạt động khai thác đó phụ thuộc vào, thu hẹp đáng kể bề mặt tấn công đối với loại lỗ hổng đó, mặc dù chúng không loại bỏ hoàn toàn nguy cơ thoát khỏi vùng chứa.
Việc thêm lệnh USER vào Dockerfile của bạn sẽ giải quyết vấn đề này. Một số hình ảnh chính thức được gửi kèm theo người dùng không có đặc quyền mà bạn có thể kích hoạt bằng lệnh USER, nhưng nhiều hình ảnh vẫn mặc định là root mà không có người dùng ứng dụng làm sẵn. Trong những trường hợp đó, bạn tạo người dùng trong Dockerfile trước khi chuyển sang nó. Đối với hầu hết các thiết lập tự lưu trữ, thay đổi duy nhất này sẽ loại bỏ toàn bộ danh mục rủi ro leo thang.
Hiển thị quá nhiều cổng cho Internet công cộng
Khi bạn xuất bản một cổng bằng Docker, Docker sẽ viết trực tiếp các quy tắc iptables của riêng nó. Các quy tắc đó chạy trước các quy tắc tường lửa cấp máy chủ. Đây là một hành vi nổi tiếng được cộng đồng báo cáo Và được ghi lại trong hướng dẫn lọc gói của Docker, không phải là cấu hình sai và điều đó có nghĩa là UFW và các công cụ tương tự không chặn những gì Docker đã mở.
Docker ghi trực tiếp vào iptables, bỏ qua các mặc định UFW và tường lửa trên nhiều máy chủ Linux. Điều đó có nghĩa là một cổng được liên kết với 0.0.0.0 có thể được truy cập công khai ngay cả khi tường lửa của bạn được định cấu hình. Các nhóm bảo mật đám mây và quy tắc chuỗi DOCKER-USER vẫn có thể chặn lưu lượng truy cập đó, do đó mức độ phơi nhiễm thực tế phụ thuộc vào thiết lập mạng cụ thể của bạn.
Liên kết các dịch vụ với 127.0.0.1 nếu có thể, định tuyến lưu lượng truy cập công khai thông qua proxy ngược và chỉ xuất bản những gì thực sự yêu cầu quyền truy cập bên ngoài. Proxy ngược là cách đáng tin cậy nhất để kiểm soát những gì được hiển thị từ bên ngoài máy chủ.
Bỏ qua sự cô lập mạng giữa các container
Bất kỳ vùng chứa nào trên mạng đó đều có thể tiếp cận bất kỳ vùng chứa nào khác trên đó mà không bị hạn chế. Cầu mặc định không áp dụng tính năng lọc lưu lượng giữa các vùng chứa chia sẻ nó và hầu hết các thiết lập không bao giờ thay đổi cấu hình đó.
Nếu một vùng chứa bị xâm phạm, giao tiếp mở đó sẽ trở thành đường di chuyển ngang. Vùng chứa giao diện người dùng có thể tiếp cận cơ sở dữ liệu, API nội bộ hoặc bất kỳ thứ gì khác trên cùng một mạng cầu nối mặc định, ngay cả khi quyền truy cập đó không bao giờ được dự định.
Mạng do người dùng xác định cung cấp cho bạn quyền kiểm soát rõ ràng về những vùng chứa nào có thể giao tiếp, nhưng một mạng tùy chỉnh duy nhất được chia sẻ bởi tất cả các dịch vụ của bạn vẫn cho phép lưu lượng truy cập giữa các vùng chứa miễn phí. Sự cô lập thực sự đòi hỏi phải đặt các dịch vụ không nên giao tiếp với nhau trên các mạng riêng biệt. Tắt cầu mặc định là điểm xuất phát chứ không phải là điểm kết thúc.
Nhìn ra Docker Socket
Docker socket tại /var/run/docker.sock là giao diện điều khiển cho toàn bộ Docker engine. Việc gắn nó vào một vùng chứa sẽ cấp cho API đó quyền truy cập trực tiếp vào daemon đang chạy trên máy chủ.
Với quyền truy cập đó, một container có thể khởi động các container mới, gắn kết các thư mục máy chủ, kiểm tra và sửa đổi các container đang chạy cũng như kiểm soát hiệu quả máy chủ. Bề mặt tấn công tương đương với root trên máy chủ, đó là lý do tại sao bất kỳ công cụ nào yêu cầu truy cập socket đều đáng được đánh giá cẩn thận.
Đối với hầu hết các trường hợp sử dụng, có những lựa chọn thay thế an toàn hơn: API có phạm vi hoặc Công cụ quản lý Docker không yêu cầu quyền truy cập vào ổ cắm. Docker-in-Docker có những đánh đổi về bảo mật và vận hành riêng và không phải là sự thay thế đơn giản.
Lỗi cấu hình tạo ra sự tiếp xúc ban đầu. Các lựa chọn về hình ảnh và phần phụ thuộc sẽ xác định mức độ hiển thị đó sẽ kết hợp như thế nào theo thời gian.
Hình ảnh và những sai lầm bí mật tồn tại lâu hơn container
Khi bạn dừng một vùng chứa, các lỗi cấu hình bên trong vùng chứa đó cũng sẽ dừng lại. Khi bạn xây dựng lại từ một hình ảnh có lỗ hổng hoặc thông tin xác thực được mã hóa cứng, sự cố sẽ khởi động lại với vùng chứa. Lỗi cấp độ hình ảnh không được đặt lại giữa các lần triển khai.
Họ di chuyển cùng hình ảnh đến mọi môi trường kéo nó, mọi sổ đăng ký lưu trữ nó và mọi thành viên trong nhóm điều hành nó. Sự kiên trì đó khiến việc quản lý hình ảnh và bí mật trở thành một loại rủi ro riêng biệt, đáng được kiểm tra riêng biệt với cấu hình.
Chúng tôi thường thấy mô hình này: một hình ảnh được chọn cẩn thận khi bắt đầu dự án và không bao giờ được xây dựng lại kể từ đó, dần dần trôi khỏi đường cơ sở bảo mật mà nó thể hiện ban đầu.
Sử dụng hình ảnh không đáng tin cậy hoặc lỗi thời
Cơ quan đăng ký công cộng được mở cho bất kỳ ai. Các hình ảnh độc hại đã được phân phối thông qua Docker Hub mang theo các công cụ khai thác tiền điện tử và các cửa hậu được nhúng trong lịch sử lớp vẫn tồn tại trong suốt quá trình khởi động lại vùng chứa. Việc xác minh trước khi kéo là vấn đề quan trọng, đặc biệt đối với hình ảnh từ các nhà xuất bản không chính thức hoặc không xác định.
Vấn đề riêng biệt là sự cũ kỹ. Một hình ảnh chính thức mà bạn lấy sáu tháng trước và chưa bao giờ được xây dựng lại kể từ đó đã tích lũy các lỗ hổng Docker chưa được vá với mỗi CVE được tiết lộ đối với các gói của nó. Hình ảnh không bị hỏng. Nó chỉ không còn hiện tại nữa.
Báo cáo Trạng thái Chuỗi Cung ứng Phần mềm năm 2024 của Sonatype nhận thấy rằng 95% thành phần dễ bị tấn công được sử dụng, phiên bản sửa lỗi đã có sẵn và 80% phần phụ thuộc của ứng dụng vẫn chưa được nâng cấp trong hơn một năm. Mẫu đó cũng liên quan đến hình ảnh cơ sở của Docker vì chúng dựa trên cùng các gói nguồn mở.
Sử dụng hình ảnh chính thức từ các nhà xuất bản đã được xác minh và ghim thẻ phiên bản cụ thể thay vì dựa vào “mới nhất”. Xây dựng nhịp độ xây dựng lại thường xuyên để giữ cho hình ảnh của bạn luôn cập nhật.
Bí mật mã hóa cứng trong Dockerfiles và Compose Files
Thông tin xác thực được ghi vào lệnh Dockerfile ENV hoặc ARG, được mã hóa cứng vào khối môi trường Compose, được chuyển dưới dạng đối số bản dựng hoặc được lưu trữ trong tệp .env được cam kết kiểm soát phiên bản sẽ không biến mất khi bạn dừng vùng chứa. Chúng nằm trong lịch sử lớp hình ảnh hoặc kiểm soát nguồn, có thể truy cập được đối với bất kỳ ai có thể truy cập.
Đây là một trong những lỗi bảo mật Docker bị bỏ qua nhiều nhất vì nó không gây ra vấn đề rõ ràng trong quá trình phát triển. Khóa API trong lệnh ENV hoạt động chính xác. Nó cũng nằm trong kho lưu trữ của bạn, được đưa vào hình ảnh của bạn và được phân phối đến bất cứ nơi nào hình ảnh đó di chuyển.
Docker Compose hiện đại hỗ trợ cơ chế bí mật gốc gắn kết thông tin xác thực trong thời gian chạy mà không cần đưa chúng vào hình ảnh. API bí mật của Docker và trình quản lý bí mật bên ngoài đều tuân theo nguyên tắc tương tự. Đây là các tùy chọn giúp loại bỏ hoàn toàn thông tin xác thực khỏi các tạo phẩm xây dựng và các tệp đã cam kết.
Các biến môi trường thời gian chạy là một cải tiến so với thông tin xác thực được mã hóa cứng, nhưng chúng vẫn được hiển thị thông qua kết quả kiểm tra Docker, nhật ký và kết xuất sự cố. Chúng là một bước tiến từ những bí mật đã có sẵn, không phải là một giải pháp hoàn chỉnh.
Không cập nhật hình ảnh vùng chứa thường xuyên
Chạy cùng một hình ảnh trong nhiều tháng là một thói quen phổ biến. Mỗi ngày trôi qua sau khi một lỗ hổng mới được phát hiện, nhưng trước khi bạn xây dựng lại, vùng chứa của bạn sẽ có một cửa sổ hiển thị mở rộng mà không có bất kỳ thay đổi rõ ràng nào.
Xây dựng một lịch trình xây dựng lại nhất quán. Tự động hóa quy trình đó nếu có thể và chạy trình quét lỗ hổng định kỳ đối với các hình ảnh hiện tại của bạn. Mục tiêu không phải là sự hoàn hảo. Nó đang thu hẹp khoảng thời gian từ lúc phát hành bản vá đến lúc triển khai.
Kiểm soát và giám sát truy cập có thể bị loại bỏ khi triển khai nhanh. Chúng cũng là những hạng mục mà sự cố không bị phát hiện lâu nhất.
Khoảng cách kiểm soát truy cập và khả năng hiển thị
Sau khi một vùng chứa đang chạy với cấu hình ổn định và hình ảnh hiện tại, vẫn còn hai loại lỗi. Về bản chất, cả hai đều vô hình: bạn sẽ không nhận thấy vấn đề kiểm soát truy cập yếu cho đến khi ai đó sử dụng nó và bạn sẽ không nhận thấy khoảng trống giám sát cho đến khi bạn cần điều tra hoạt động chưa từng được ghi lại.
Giống nhau Nghiên cứu của Red Hat 2024 nhận thấy rằng 42% nhóm thiếu khả năng đủ để giải quyết vấn đề bảo mật vùng chứa và các mối đe dọa liên quan.
Chúng tôi nhận thấy rằng những khoảng trống trong việc giám sát thường xuất hiện trong quá trình điều tra sự cố chứ không phải trước đó. Vào thời điểm khả năng hiển thị trở thành ưu tiên, nó thường phản ứng với điều gì đó hơn là ngăn chặn điều đó.
Bảng điều khiển quản lý và xác thực yếu
Bảng thông tin quản lý vùng chứa trên IP công cộng không có xác thực không yêu cầu kẻ tấn công tinh vi. Nó đòi hỏi họ phải biết địa chỉ. Đó là mức thấp hơn hầu hết các đội nhận ra.
Các công cụ quản lý và giám sát tự lưu trữ thường đi kèm với giao diện web có thể truy cập được trên tất cả các giao diện mạng. Để những thứ đó trên IP công cộng mà không có xác thực trước mặt chúng tương đương với việc mở khóa bảng quản trị.
Xác thực, proxy ngược và vị trí mạng riêng là cơ sở. Kiểm soát quyền truy cập là một bước cấu hình mà bạn thêm vào bất kỳ giao diện quản lý nào, không phải thứ gì đó được kích hoạt.
Nguyên tắc tương tự áp dụng cho Docker CLI và quản lý GUI; Quyền truy cập cấp quản trị viên vào daemon có cùng rủi ro bất kể giao diện.
Không theo dõi những gì vùng chứa của bạn đang làm
Nếu vùng chứa bị xâm phạm, hoạt động của kẻ tấn công sẽ tạo ra dấu vết: thay đổi hành vi xử lý, kết nối mạng bất thường và sửa đổi tệp không mong muốn. Nếu không có bộ sưu tập nhật ký tại chỗ, dấu vết đó sẽ không tồn tại ở dạng mà bạn có thể hành động.
Các công cụ thu thập nhật ký tập trung, ghi nhật ký kiểm tra vùng chứa và giám sát thời gian chạy cung cấp cho bạn dữ liệu để phát hiện hoạt động bất thường trước khi nó kết hợp. Mục tiêu không phải là phân tích từng dòng. Nó có sẵn dữ liệu khi bạn cần điều tra.
Thiết lập vùng chứa chạy âm thầm trong quá trình sản xuất mà không có quy trình ghi nhật ký và không có cảnh báo không phải là mức bảo trì thấp. Họ không được kiểm tra. Đó là hai trạng thái hoạt động khác nhau.
Tại sao môi trường cơ sở hạ tầng cũng có vấn đề
Bảo mật vùng chứa bắt đầu bằng cấu hình, nhưng cấu hình chạy trên cơ sở hạ tầng. Máy chủ có mạng bị định cấu hình sai, tài nguyên được chia sẻ hoặc không có tính năng lọc cấp độ mạng sẽ tạo ra các điều kiện ảnh hưởng đến mọi vùng chứa phía trên nó. Việc thiết lập đúng vùng chứa và đúng cấu hình máy chủ là hai nhiệm vụ riêng biệt.
Nhiều lỗ hổng bảo mật của Docker được khuếch đại bởi các điều kiện mà chính các container kế thừa:
- Máy chủ thuê chung không có sự cách ly phần cứng giữa những người thuê
- Hạt nhân máy chủ đang chạy chưa được vá
- Máy chủ không có tính năng lọc cấp độ mạng tích hợp
Điều này không loại bỏ sự cần thiết của các bước cấu hình ở trên, vì việc tăng cường độ cứng vùng chứa thích hợp là vấn đề bất kể lớp cơ sở hạ tầng. Bắt đầu trên cơ sở hạ tầng biệt lập sẽ loại bỏ một lớp lo ngại khỏi phương trình.
Tại Cloudzy, chúng tôi cung cấp hai đường dẫn tùy thuộc vào yêu cầu thiết lập của bạn:
- VPS Linux: một môi trường sạch sẽ để tự triển khai Docker và áp dụng các bước củng cố trong bài viết này
- VPS của nhà cung cấp dịch vụ: tùy chọn một cú nhấp chuột được cài đặt sẵn Portainer; máy chủ khởi động và bạn đã ở trong bảng điều khiển
Cả hai tùy chọn đều chạy trên cùng một cơ sở hạ tầng: ảo hóa KVM, CPU AMD Ryzen 9 với xung nhịp tăng lên tới 5,7 GHz, bộ nhớ DDR5, bộ lưu trữ SSD NVMe, mạng lên tới 40 Gbps và bảo vệ DDoS miễn phí thông qua bộ lọc BuyVM, trên 12 địa điểm trên toàn cầu với SLA thời gian hoạt động 99,95%.
Để có cái nhìn sâu hơn về việc chạy Portainer trên VPS, chúng tôi sẽ trình bày nó trong một bài viết riêng.
Danh sách kiểm tra bảo mật thực tế cho việc triển khai Docker
Các lỗi bảo mật Docker ở trên hầu hết xuất phát từ các quyết định cấu hình đơn lẻ được thực hiện một lần và không bao giờ xem lại. Việc chạy danh sách kiểm tra này dựa trên thiết lập hiện có sẽ phát hiện được những khoảng trống đó. Nó hoạt động như một bản kiểm tra chứ không phải một hướng dẫn triển khai.
Các phương pháp hay nhất về bảo mật Docker này đề cập đến cách bảo mật các bộ chứa Docker trước các lỗi cấu hình phổ biến nhất được mô tả ở trên.
Tham khảo nhanh: Tất cả 9 sai lầm
| Sai lầm | Loại | Sửa lỗi một dòng |
| Chạy bằng root | Cấu hình | Thêm vào NGƯỜI DÙNG chỉ thị tới Dockerfile của bạn |
| Các cổng được liên kết với 0.0.0.0 | Cấu hình | Liên kết với 127.0.0.1 và định tuyến qua proxy ngược |
| Không cách ly mạng | Cấu hình | Phân chia dịch vụ trên các mạng riêng biệt do người dùng xác định dựa trên nhu cầu truy cập. |
| Ổ cắm Docker được gắn | Cấu hình | Tháo giá đỡ; sử dụng các API hoặc giải pháp thay thế có phạm vi |
| Hình ảnh không đáng tin cậy hoặc lỗi thời | Hình ảnh | Sử dụng hình ảnh chính thức với thẻ phiên bản được ghim |
| Bí mật được mã hóa cứng | Hình ảnh | Di chuyển thông tin xác thực sang các vars env thời gian chạy hoặc trình quản lý bí mật |
| Không có lịch xây dựng lại hình ảnh | Hình ảnh | Đặt nhịp xây dựng lại hàng tháng; tự động hóa nếu có thể |
| Trang tổng quan không được xác thực | Truy cập | Thêm xác thực và di chuyển giao diện người dùng quản lý sang mạng riêng |
| Không có bộ sưu tập nhật ký vùng chứa | Truy cập | Thiết lập giám sát ghi nhật ký và thời gian chạy tập trung |
Trước tiên, chúng tôi khuyên bạn nên chạy nó với các thiết lập hiện có vì đó là nơi có nhiều khả năng xuất hiện các lỗ hổng nhất.
Các container chạy không phải root: Kiểm tra Dockerfiles của bạn để biết chỉ thị USER. Nếu không tồn tại, container sẽ chạy dưới quyền root.
Ràng buộc cổng giới hạn ở localhost hoặc proxy: Chạy docker ps và xem lại các ràng buộc cổng. Mục 0.0.0.0:PORT có thể được truy cập công khai trên các máy chủ mà không có nhóm bảo mật ngược dòng, tường lửa bên ngoài hoặc quy tắc chuỗi DOCKER-USER nào chặn nó.
Mạng cầu tùy chỉnh đang được sử dụng: Các container trên cầu nối mặc định của Docker có thể tiếp cận nhau một cách tự do. Các bộ chứa trên cùng một cây cầu do người dùng xác định vẫn có thể liên lạc với nhau, do đó, hãy phân chia các dịch vụ trên các mạng riêng biệt theo ranh giới tin cậy để cách ly thực tế.
Ổ cắm Docker không được gắn trong vùng chứa: Kiểm tra Soạn tệp và chạy đối số. Nếu /var/run/docker.sock xuất hiện dưới dạng một tập, hãy xác nhận rằng đó là điều bắt buộc và có chủ ý.
Hình ảnh cơ sở từ các nhà xuất bản đã được xác minh với các phiên bản được ghim: A FROM ubuntu:latest kéo một phiên bản không xác định, có khả năng lỗi thời. Ghim vào một bản phát hành cụ thể.
Không có bí mật nào trong Dockerfiles, Compose file hoặc build đối số: Lịch sử lớp hình ảnh vẫn giữ nguyên thông tin xác thực sau khi xóa vùng chứa. Sử dụng các bí mật của Compose, các bí mật của Swarm, xây dựng thú cưỡi bí mật hoặc trình quản lý bí mật bên ngoài. Các biến môi trường thời gian chạy tốt hơn các giá trị được mã hóa cứng nhưng vẫn xuất hiện trong đầu ra và nhật ký kiểm tra.
Lịch trình xây dựng lại hình ảnh được xác định: Hình ảnh cũ tích lũy lỗ hổng. Nhịp xây dựng lại hàng tháng giúp quản lý cửa sổ hiển thị trong hầu hết các thiết lập.
Giao diện quản lý đằng sau xác thực: Bất kỳ trang tổng quan nào trên IP công cộng không có xác thực đều là điểm vào mở. Vị trí mạng riêng là thích hợp hơn nếu có thể.
Nhật ký vùng chứa đang được thu thập: Nếu không có đường dẫn nhật ký, việc phát hiện sự cố sẽ phụ thuộc vào tác động có thể nhìn thấy được của hệ thống. Đó là một tín hiệu muộn để hành động.
Phần kết luận
Cấu hình mặc định của Docker được xây dựng để thuận tiện chứ không phải để bảo mật. Hầu hết các lỗi được đề cập trong bài viết này đều bắt nguồn từ các cài đặt không bao giờ được thay đổi sau lần triển khai đầu tiên, chứ không phải do các cuộc tấn công phức tạp.
Các bản sửa lỗi chủ yếu là các quyết định cấu hình một lần: chỉ thị NGƯỜI DÙNG, thay đổi ràng buộc cổng, mạng tùy chỉnh, lịch xây dựng lại. Không ai trong số họ yêu cầu công cụ mới cho hầu hết các thiết lập.
Việc cấu hình vùng chứa đúng là nhiệm vụ đầu tiên. Cơ sở hạ tầng mà nó chạy trên đó là cơ sở hạ tầng thứ hai. Cả hai đều quan trọng và không thay thế cho cái kia.
