Thực hành tốt nhất và toàn diện để xem xét khi chạy docker trong sản xuất là gì?

Cuối cùng, bạn rất yêu thích Docker đến mức bạn muốn chuyển các hệ thống sản xuất quan trọng trong kinh doanh trực tuyến của mình với dữ liệu khách hàng nhạy cảm sang Docker Swarm. Một số thậm chí có thể đã làm như vậy. Tổ chức khác không thể đủ khả năng cho nó bằng chính sách cấm các quy trình sản xuất chạy ở chế độ gốc.

Điều gì có thể là một danh sách kiểm tra các khối xây dựng để xem xét cho môi trường sản xuất Docker? Một người không cần tất cả trong số họ, nhưng tất cả chúng đều quan trọng để được đánh giá.

Tuyên bố miễn trừ trách nhiệm: Tôi biết có chính sách SE để tránh "danh sách lớn vô tận" nhưng tôi nghĩ rằng danh sách kiểm tra này có thể rất lớn ... và vô tận.

Vậy - những khối nhà này là gì?

1. Nếu chưa được triển khai, hãy xem xét việc chạy một hệ thống máy chủ Linux với các cài đặt bảo mật nâng cao - kernel cứng, SELinux, v.v.
2. Cân nhắc sử dụng một hình ảnh cơ sở Docker nhỏ, như alpine, busybox hoặc thậm chí là cào, ví dụ bắt đầu với một hình ảnh cơ sở trống
3. Sử dụng cài đặt USER khác với root
4. Đánh giá cẩn thận để giảm hơn nữa bộ khả năng đã bị thu hẹp được cấp cho bộ chứa
5. Xem xét chỉ có một nhị phân thực thi trên mỗi container để khởi chạy quy trình của bạn, lý tưởng nhất là liên kết tĩnh
6. Những người muốn phá vỡ hệ thống của bạn để có quyền truy cập shell có thể tự hỏi liệu họ có phát hiện ra container của bạn đã tắt tất cả shell không
7. Gắn kết các tập chỉ đọc khi có thể

Câu hỏi: còn gì nữa không?

Máy chủ lưu trữ các container đang chạy

Chạy băng ghế bảo mật docker trên mọi nút chạy container docker https://github.com/docker/docker-bench-securance

Chạy lệnh sau trên một nút chạy container docker:

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

trả về một danh sách kiểm tra:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

Trích dẫn từ kho README:

Docker Bench for Security là một kịch bản kiểm tra hàng tá các thực tiễn tốt nhất phổ biến xung quanh việc triển khai các container Docker trong sản xuất. Các thử nghiệm đều được tự động hóa và được lấy cảm hứng từ CIS Docker Community Edition Benchmark v1.1.0 .

Một số vấn đề được báo cáo bởi băng ghế an ninh có thể được giải quyết bằng cách đọc bài viết bảo mật docker chính thức và so sánh nó với các viên đạn được xác định trong câu hỏi, những điều sau đây cũng rất quan trọng:

• bảo vệ ổ cắm docker daemon bằng cách thực hiện ssl
• nội dung tin cậy bằng cách sử dụng công chứng và DOCKER_CONTENT_TRUSTbiến

Docker vẫn đang được phát triển.

Như mọi lỗi phần mềm khác sẽ xảy ra, các tính năng không an toàn có thể được thêm vào, có thể có các lỗi kiến ​​trúc dẫn đến vi phạm bảo mật. Đừng đánh giá thấp điều này! Hệ thống của bạn có thể hoàn toàn an toàn ngày hôm nay, nhưng với bản vá từ tuần tới, ai đó sẽ tìm thấy một lỗi, viết một khai thác và đột nhiên hệ thống của bạn đang mở rộng.

Trừ khi bạn phải, đừng cập nhật lên phiên bản mới nhất. Sử dụng phiên bản thử nghiệm mới nhất thay thế.

Docker không ảo hóa

Nếu ai đó trốn thoát khỏi một Docker container, kẻ tấn công đó đang ở trên máy thật ngay lập tức. Không có cổng thứ hai như ảo hóa sẽ ngăn chặn vi phạm.

Đối xử với một Docker container như bất kỳ chương trình khác. Chạy với quyền người dùng thấp nhất có thể, chặn tất cả lưu lượng truy cập mạng không bắt buộc, ảo hóa toàn bộ máy chủ Docker nếu hiệu suất cho phép.

Docker là không bảo vệ

Bất cứ mã nào được chạy bên trong các container Docker đều được chạy mà không có câu hỏi nào từ Docker. Bất kỳ kẻ tấn công nào cũng có thể chỉ cần cài đặt phần mềm của mình bên trong container và Docker sẽ chạy như bất kỳ mã nào khác.

Ngoài những điều bạn đã đề cập trong câu hỏi, hãy xem xét sử dụng các số liệu và cảnh báo để được thông báo nếu có bất kỳ hình ảnh Docker nào đang làm những điều kỳ lạ. Có đột biến, CPU tăng đột biến? Là chương trình đột nhiên quét các cổng mạng? Có truy cập đĩa đáng ngờ? Bạn sẽ nhận được một thông báo nếu bất kỳ điều đó xảy ra. Có nhiều công cụ có sẵn để đo lường những điều này, bạn nên sử dụng chúng.

Docker hình ảnh chính nó

Một tùy chọn bổ sung là sử dụng Clair .

Clair là một dự án nguồn mở để phân tích tĩnh các lỗ hổng trong các thùng chứa ứng dụng (hiện bao gồm appc và docker).

Trong các khoảng thời gian đều đặn, Clair nhập siêu dữ liệu lỗ hổng từ một bộ nguồn được định cấu hình và lưu trữ nó trong cơ sở dữ liệu.

Khách hàng sử dụng API Clair để lập chỉ mục hình ảnh chứa của họ; điều này tạo ra một danh sách các tính năng có trong hình ảnh và lưu trữ chúng trong cơ sở dữ liệu.

Khách hàng sử dụng API Clair để truy vấn cơ sở dữ liệu về các lỗ hổng của một hình ảnh cụ thể; các lỗ hổng và tính năng tương quan được thực hiện cho từng yêu cầu, tránh phải quét lại hình ảnh.

Khi cập nhật siêu dữ liệu lỗ hổng xảy ra, một thông báo có thể được gửi đến các hệ thống cảnh báo rằng đã có thay đổi.

Mục tiêu của chúng tôi là cho phép một cái nhìn minh bạch hơn về bảo mật của cơ sở hạ tầng dựa trên container. Do đó, dự án được đặt tên là Clair theo thuật ngữ tiếng Pháp có nghĩa là rõ ràng, tươi sáng, minh bạch.

Ngoài các điểm trong chủ đề này; Sau đây sẽ là đề xuất của tôi:

• Kiểm soát Docker PID1 với dumb-init
  • ref: Vấn đề gặt hái của PID1 và Zombie
• Không chạy docker trong sản xuất mà không có hệ thống điều phối container
  • Hãy chọn từ Kubernetes, Mesos, Swarm, v.v.
• Sử dụng gosu để kiểm soát người dùng bên trong hình ảnh docker
• Thực hiện theo mô hình ứng dụng 12 yếu tố, nếu bạn đang chạy các ứng dụng trạng thái trong các thùng chứa, hãy thay đổi nó.
  • Nếu bạn thực sự cần chạy các ứng dụng trạng thái (mysql, zookeeper, elaticsearch ) trong các thùng chứa, hãy tận dụng các mô hình của dàn nhạc như Kubernetes Statefulsets
• Thực hiện quản lý bí mật / cấu hình mạnh mẽ với các công cụ như hashicorp vault / consul
• Vận chuyển cùng một container được xây dựng bởi các nhà phát triển để sản xuất thông qua một đường ống CI đưa nó qua quá trình dàn dựng, kiểm tra tích hợp kỹ lưỡng.
• Tạo thông báo xung quanh CVE và các bản vá, kích hoạt các bản dựng trên thông báo bản vá
• Có đăng nhập rộng rãi để hiểu rõ hơn về container đang chạy, bạn không muốn cấp cho nhà phát triển SSH quyền truy cập vào máy chủ hoặc vùng chứa
  • đề nghị: thông thạo
• Có cả số liệu về container và máy chủ
  • đề xuất: prometheus + nút xuất khẩu

Nếu bạn đang điền vào điểm nhập docker của bạn bằng sedcác lệnh, hãy xem xét thực hành này:

• Sử dụng một công cụ như confd để quản lý các tệp cấu hình hình ảnh docker của bạn và giữ cho chúng được cập nhật

Confd sẽ đọc dữ liệu từ nhiều cửa hàng khóa-giá trị được hỗ trợ và hiển thị các mẫu cấu hình một cách linh hoạt.

Người ta có thể sử dụng A2D để nướng ứng dụng vào hình ảnh docker trong khi tính đến một số thứ nhất định, ví dụ như không phải root, quyền, vị trí của ứng dụng:

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

trả về:

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]