Chef: túi dữ liệu được mã hóa, bảo vệ khóa mã hóa


8

Khi bạn đang sử dụng tính năng túi dữ liệu được mã hóa cho Chef, bạn sẽ triển khai khóa cho nhiều máy chủ như thế nào? Nếu bạn đặt nó vào một công thức, bất kỳ ai có quyền truy cập vào bất kỳ máy chủ hoặc máy khách đầu bếp nào cũng có thể rút khóa và có khả năng giải mã bất kỳ dữ liệu nào.

Làm thế nào để bạn đi về việc đảm bảo rằng chìa khóa là trên các máy cần nó, nhưng cũng an toàn từ bất cứ ai rình mò xung quanh?

Câu trả lời:


8

Thật không may, thực sự không có nhiều thứ bạn có thể làm vì chìa khóa cần phải ở đâu đó trên nút Chef ở dạng văn bản thuần túy. Nếu ai đó có vỏ hoặc quyền truy cập cục bộ vào hộp thì họ có thể đọc (các) khóa.

Để giảm thiểu mọi thứ một chút, tôi thêm phần sau vào basenode của mình (tức là một số công thức hoặc vai trò chung cho tất cả các nút):

directory "/etc/chef/keys" do
  mode 0700
  owner "root"
  group "root"
end

và bất kỳ cơ chế phân phối khóa nào bạn có đặt khóa ở vị trí đó. Các quyền và quyền sở hữu ngăn việc đọc các khóa nếu ai đó quên đặt các quyền chính xác trên một tệp chính.

Như tôi thấy, các túi dữ liệu được mã hóa là để bảo vệ tài liệu chính không bị đọc trong hệ thống kiểm soát nguồn và ít hơn là một tính năng bảo mật trên các nút Chef.


3

EDB của tôi được phân tách bằng:

  • Môi trường
  • vai trò

Chúng tôi tải lên tất cả các khóa có hậu tố đặc biệt cho mọi phiên bản EC2 mới khi chúng tôi khởi động nó và sau đó xóa tất cả các khóa chưa được sử dụng bởi bất kỳ công thức nấu ăn nào trong run_list vào cuối lần chạy đầu tiên của khách hàng (sẽ là ngay khi ví dụ bắt đầu.)

Tất cả các tệp được tải lên dưới dạng chủ sở hữu và nhóm "root" và chỉ có quyền đọc.

Mỗi công thức sử dụng EDB, tạo tên EDB và tên tệp khóa trong thời gian chạy công thức bằng cách ghép 'edb_' + môi trường nút + tên công thức / mục cụ thể + '.key' và sau đó tìm khóa theo tên này . (Nếu nó không tồn tại, điều này sẽ ném một ngoại lệ theo mặc định.)

Do đó, đối với máy chủ couchdb của chúng tôi, chạy một vai trò gọi là 'couch', để có được thông tin đăng nhập mà chúng tôi đang sử dụng cho người dùng quản trị viên trong môi trường dev, công thức tìm kiếm một khóa có tên 'edb_dev_couch.key'

Sau đó, nó tìm kiếm một túi dữ liệu có tên 'edb_dev' cho một mục có tên 'couch_credentials'.

Để quản lý khóa, tôi hiện đang sử dụng phương pháp đơn giản của:

  • tải lên tất cả các khóa EDB thông qua tập lệnh bootstrap và nối '_x' vào tên khóa
  • Có mỗi công thức sử dụng giao diện EDB trong thư mục khóa cho khóa mà nó cần.
  • nếu khóa tồn tại với hậu tố '_x', hãy đổi tên khóa để xóa hậu tố '_x'.
  • thêm một công thức vào cuối mỗi run_list xóa tất cả các khóa bằng hậu tố '_x'

Hy vọng rằng, điều này giới hạn thời gian mà các khóa bên ngoài phạm vi của một nút đơn có thể bị ảnh hưởng cho đến khi máy đã được khởi động và có lần chạy đầu tiên của Chef_client.

Đây là vòng thử nghiệm đầu tiên của chúng tôi về cách bảo mật các khóa, nhưng cho đến nay nó đáp ứng nhu cầu hiện tại của chúng tôi vì nó ngăn một máy chủ dev gốc có thể truy cập ngay lập tức bất kỳ thông tin đăng nhập máy chủ nào khác được lưu trữ trong EDB.

Để duy trì việc có một công thức ở cuối mỗi danh sách chạy, tôi sử dụng công cụ thực thi dao để đảm bảo công thức xóa_keys này chính xác là công thức cuối cùng trên mỗi nút.


0

Các khóa của tôi được đưa vào các AMI mà chúng ta sử dụng hoặc các hình ảnh chúng ta sử dụng. Tôi không làm điều đó như một phần của bootstrap vì dữ liệu đó không an toàn. Bạn thường có thể thấy dữ liệu trong nhật ký và như vậy nếu bạn không cẩn thận.

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.