Truyền bí mật cho container Docker


26

Tôi có một hình ảnh docker cơ sở được sử dụng để chạy phần mềm phân tích hình ảnh. Đối với mỗi vùng chứa được tạo từ hình ảnh, có một bộ cài đặt cấu hình, một số trong đó là các bí mật (khóa mã hóa, thông tin khách hàng, v.v.) được phần mềm sử dụng để phân tích và phân phối hình ảnh được xử lý. Làm thế nào tôi có thể chuyển những bí mật này một cách an toàn đến một container?


Hầm Hashicorp
030

Câu trả lời:


23

Bạn có 3 phương pháp để lấy bí mật cho một ứng dụng bên trong thùng chứa docker. 2 đầu tiên liên quan đến cấu hình docker. Việc cuối cùng là để ứng dụng của bạn lấy trực tiếp các bí mật từ một cửa hàng bí mật.

1 - Biến môi trường

Theo hướng dẫn "Ứng dụng 12 yếu tố" , các bí mật chỉ là cấu hình và chúng phải luôn được đặt trong môi trường. Bạn có thể đặt bí mật của mình làm các biến môi trường trong quá trình chạy docker và ứng dụng của bạn truy cập chúng từ đó.

2 - Khối lượng gắn kết

Bạn có thể có tất cả các bí mật của mình trong một tệp cấu hình / bí mật cụ thể, sau đó gắn nó vào thể hiện của bạn dưới dạng một khối lượng được gắn kết .

3 - Lấy từ cửa hàng bí mật

Như @ 030 đã đề cập, bạn có thể sử dụng Hashicorp Vault (hoặc "Trình quản lý bí mật của Amazon" hoặc bất kỳ dịch vụ nào như vậy).
Ứng dụng của bạn hoặc ứng dụng sidecar có thể lấy trực tiếp các bí mật mà nó cần mà không phải xử lý bất kỳ cấu hình nào trên bộ chứa Docker. Phương pháp này sẽ cho phép bạn sử dụng các bí mật được tạo động (một tính năng rất hấp dẫn của các hệ thống như vậy) và không phải lo lắng về các bí mật có thể xem được từ hệ thống tệp hoặc kiểm tra các biến env của bộ chứa docker.

Ý kiến ​​cá nhân

Tôi tin rằng các biến env là con đường để đi. Việc quản lý dễ dàng hơn và bạn vẫn có thể lấy từ một cửa hàng bí mật như Hashicorp Vault, nếu bạn có hệ thống xây dựng CI, hãy lấy các bí mật trong quá trình xây dựng và thiết lập chúng khi bạn triển khai. Bạn có được điều tốt nhất của cả hai thế giới và lợi ích gia tăng của các nhà phát triển của bạn không cần phải viết mã ứng dụng để tìm nạp bí mật. Các nhà phát triển nên tập trung vào chức năng mã của họ và không xử lý các tác vụ quản trị viên như tìm nạp mật khẩu.

Mã ứng dụng của bạn nên tập trung vào chính chức năng ứng dụng của chính nó và không xử lý các tác vụ phụ trợ như tìm nạp mật khẩu. Giống như ứng dụng 12 yếu tố.

Chỉnh sửa: đã thay đổi câu cuối cùng để xóa hàm ý của Nhà phát triển so với SysAdmin silo-ing. Bản thân các nhiệm vụ nên tách biệt khỏi phối cảnh mã, nhưng DevOps là về cùng một người luôn ghi nhớ và không bị giới hạn.

Ý kiến ​​cá nhân (Cập nhật)

Nhận xét tuyệt vời của Per @ Dirk ( Truyền bí mật cho container Docker ), có một lập luận rất mạnh mẽ để ưu tiên một cửa hàng bí mật trên các lọ ENV, do không muốn rò rỉ chúng.


2
Điều này thúc đẩy silo. DevOps đang làm mọi thứ cùng nhau thay vì ném mọi thứ lên tường.
030

2
phải được tắt từ các thành phần cơ sở hạ tầng. Những người thực tế có thể mã hóa cả tự động hóa cơ sở hạ tầng và cơ sở mã ứng dụng, nhưng bản thân các tác vụ nên tách biệt. Tôi thấy câu cuối cùng của câu trả lời ban đầu của tôi là silo-ing off the devs, the people. Đó một sai lầm. Tôi sẽ chỉnh sửa nó để rõ ràng hơn.
BoomShadow

7
Đặt bí mật vào các biến môi trường cung cấp các khả năng khác nhau để chúng bị rò rỉ. Một vài ví dụ: Mọi người có quyền truy cập vào trình nền Docker trên máy đang chạy container có thể thấy họ bằng cách sử dụng các lệnh inspecthoặc exec. Các biến môi trường thường bị đổ vào stdouthoặc vào logfiles khi chạy trong một số chế độ gỡ lỗi. Tất cả các quá trình con sinh ra có thể đọc và phơi bày chúng có thể nằm ngoài tầm kiểm soát của bạn. Thêm thông tin, ví dụ tại đây: diogomonica.com/2017/03/27/ Lời
Dirk

1
Tôi cũng đang vật lộn với câu hỏi này. Điều tôi không hiểu là, ngay cả khi bạn sử dụng kho tiền thông tin để bảo mật bí mật của mình, bạn vẫn phải xác thực để có quyền truy cập vào kho tiền đó và có lẽ cần một số bí mật. Mối quan tâm tương tự áp dụng cho việc sử dụng tệp KeyStore được bảo vệ bằng mật khẩu. Có phải chúng ta luôn bị mắc kẹt với việc vượt qua ít nhất là "thông tin meta" trong môi trường?
Wheezil

1
@Wheezil một thông tin đăng nhập meta dễ bảo mật hơn nhiều thông tin xác thực cụ thể. bạn có thể thường xuyên và tự động xoay thông tin đăng nhập meta. thông tin đăng nhập meta có thể đi đến một kho tiền trên máy chủ được bảo mật và có thể có những thứ như danh sách trắng ip để nó chỉ chấp nhận các kết nối từ mạng con sản xuất của bạn. bạn cũng có thể đảm bảo rằng kho tiền sử dụng mã hóa khi nghỉ ngơi và mã hóa trong chuyến bay và ghim chứng chỉ lẫn nhau và ghim chứng chỉ và tất cả các thực tiễn tốt nhất khác giúp mọi thứ an toàn hơn.
simbo1905

1

Có một tùy chọn khác chỉ sử dụng đường ống:

docker run -d -i --name $n alpine sh -c 'read A; echo "[$A]"; exec some-server'
docker exec -i $n sh -c 'cat > /proc/1/fd/0' <<< _a_secret_

Đầu tiên, tạo daemon docker với -i, lệnh read Asẽ treo chờ đầu vào từ /proc/1/fd/0; Sau đó chạy lệnh docker thứ hai, đọc bí mật từ stdin và chuyển hướng đến quy trình treo cuối cùng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.