Làm thế nào để quản lý các bí mật trong môi trường Microservice/Container/Cloud?

Question

Microservices và Cloud là một điều. Mọi người đều nói và viết về. Cá nhân tôi đang suy nghĩ rất nhiều về chủ đề này: Làm thế nào điều này có thể được sử dụng để được hưởng lợi từ? Thách thức có thể là gì? Làm cách nào để tăng tốc độ phát triển hàng ngày này? Và làm thế nào để quản lý tất cả mọi thứ? Một câu hỏi làm tôi bực mình sau vài ngày là "Cách quản lý bí mật trong môi trường Microservice/Cloud?".

Hãy tưởng tượng một công ty có 150 kỹ sư phần mềm và nhiều nhóm khác nhau với nhiều sản phẩm khác nhau. Mỗi đội đều tạo ra một phần mềm và mọi dịch vụ đều cần một lượng bí mật khác nhau (API-Keys, Passwords, SSH-Keys, bất cứ điều gì). Cách "thời trang cũ" là tạo một vài tệp cấu hình theo định dạng ini/yaml/txt và đọc nó. 12 ứng dụng máy tính nói: Làm điều đó cho mỗi vv env.

Env vars có thể được đặt cho mỗi máy và các tệp cấu hình cũng có thể được đặt ở đó. Điều này có tác dụng nếu bạn có một bàn tay đầy đủ các máy và việc triển khai được thực hiện bởi một vài quản trị viên hệ thống. Một trong những quy tắc chung nói: "Đừng lưu trữ bí mật trong một repo Git."

Giờ đây, thế giới mới xuất hiện. Đội ngũ bao giờ chịu trách nhiệm về ứng dụng mà họ tự sản xuất. Chúng phải được triển khai và điều hành bởi nhóm. Vì vậy, công ty chúng tôi đang chuyển sang vùng chứa và cách tự phục vụ (ví dụ: Mesos và Marathon hoặc Kubernetes).

Tất nhiên, Dockerfiles cũng có thể đặt v.v. Và có, bạn có thể ADD tập tin cấu hình của bạn vào container Docker trong xây dựng. Nhưng với điều này, mọi người đều có thể truy cập các bí mật (ví dụ: từ các nhóm khác). Và không ai biết ai sử dụng bí mật này và làm điều gì đó nguy hiểm.

Bạn cũng muốn phiên bản hóa Dockerfiles của mình. Và các ứng dụng bạn muốn chạy trên Marathon cũng phải được phiên bản hóa (Git hoặc bất kỳ thứ gì) cũng như (và được áp dụng bởi REST API). Vậy, nơi lưu trữ và quản lý tất cả bí mật cho vùng chứa/ứng dụng này? Vì với các khung công tác lên lịch như Swarm và Machine (cho Docker), Mesos và Marathon (có thể sử dụng cho Docker) hoặc Kubernetes bạn không biết ứng dụng của bạn sẽ chạy ở đâu. Điều này sẽ được lên lịch trên một số máy. Và hầu hết các công cụ này không có xác thực (theo mặc định, tất nhiên điều này có thể được thêm bởi một proxy Nginx hoặc một cái gì đó).

Một ý tưởng để quản lý bí mật là sử dụng công cụ như Vault. Nhưng tôi chưa bao giờ thấy hỗ trợ "gốc" trong ứng dụng. Điều tương tự cũng áp dụng cho Blackbox. Và tôi không biết cách quản lý cấu hình có thể giải quyết vấn đề này như thế nào. Tôi biết rằng Chef hỗ trợ các thẻ dữ liệu được mã hóa, nhưng không thể sử dụng Chef để thiết lập/xây dựng các thùng chứa Docker.

Làm thế nào để bạn quản lý bí mật trong một nhóm đa env với một số kỹ sư trong môi trường Microservice/Container/Cloud?

Answer 1

Có một số giải pháp.

Trước tiên, KHÔNG đặt bí mật của bạn vào hình ảnh. Đó chỉ là một ý tưởng tồi, như bạn đã nhận ra. Nếu bạn không thêm bí mật của bạn tại thời gian xây dựng, bạn phải làm điều đó tại thời gian chạy. Điều này khiến chúng tôi có một vài tùy chọn:

• Sử dụng biến môi trường theo đề xuất của 12 Factor App. Sau đó, bạn sẽ cần phải viết một tập lệnh sẽ điền các tệp cấu hình với các giá trị của các biến này khi vùng chứa bắt đầu.Điều này làm việc, nhưng tôi không thực sự thích nó, vì các biến môi trường dễ bị rò rỉ (chúng có thể được nhìn thấy trong các thùng chứa được liên kết và docker inspect và thường được bao gồm trong các báo cáo lỗi). Xem thêm Summon.

• Sử dụng tập. Chỉ cần gắn tập tin cấu hình với những bí mật tại thời gian chạy. Điều này làm việc, nhưng có nghĩa là bạn có một tập tin với những bí mật nằm trên máy chủ. Điều này trở nên phức tạp hơn khi bạn không biết máy chủ lưu trữ của bạn sẽ chạy như thế nào, chẳng hạn như khi sử dụng các khung như Swarm và Mesos.

• Sử dụng cửa hàng k/v an toàn như Vault/Keywhiz. Khi bạn chỉ ra, bạn sẽ cần phải làm một số kịch bản để có được các giá trị vào ứng dụng (như với env vars). Bạn cũng cần phải xác thực với cửa hàng k/v bằng cách nào đó (bạn có thể muốn xem các trình điều khiển âm lượng cho Keywhiz và Vault hoặc sử dụng mã thông báo một lần được chuyển qua một biến env).

Kubernetes đã có fairly advanced support for secrets và tôi hy vọng sẽ thấy các khung công tác khác áp dụng các giải pháp của riêng họ.