Làm cách nào để có đủ entropy vào bộ chứa Docker?

Bất cứ khi nào tôi mèo /proc/sys/kernel/random/entropy_avail bên trong bộ chứa Docker của tôi (dựa trên Linux 5.10), tôi nhận được kết quả có hai chữ số, thấp đến mức nực cười.Giả sử bất cứ thứ gì dưới 4 chữ số đều không tốt và giữ nó gần 4096 (tối đa) là lý tưởng.

Tôi đã đọc về một daemon thu thập entropy được gọi là có được, nhưng nó được cho là đã lỗi thời kể từ Linux kernel 5.6, vì vậy tôi không chắc đó là giải pháp phù hợp nữa.

Tại sao entropy của tôi quá thấp bên trong bộ chứa Docker chạy kernel 5.10 và tôi có thể làm gì để khắc phục?

Ban đầu, tôi phát hiện ra điều này khi một tập lệnh "trích dẫn trong ngày" của Python tiếp tục chọn một vài trích dẫn giống nhau. Tôi đã không tạo mô-đun Ngẫu nhiên tiêu chuẩn của Python theo cách thủ công, nhưng theo tài liệu và mã nguồn của nó, nó được cho là tự tạo từ entropy hệ thống (trực tiếp qua getentropy(3) hoặc nhận lấy ngẫu nhiên(2) nếu có, mà tôi cho rằng chúng sẽ ở trên môi trường Linux hiện đại điển hình hoặc thông qua /dev/ngẫu nhiên hoặc /dev/urandom mặt khác, hoặc quay lại sử dụng thời gian hệ thống và PID như là phương sách cuối cùng). Vì vậy, tôi đoán entropy của tôi thấp đến mức getentropy(3) đang trả lại entropy kém? Dù sao, việc gieo thủ công mô-đun Ngẫu nhiên của Python với thời gian hệ thống đã khắc phục được sự cố đó.

Tuy nhiên, bây giờ tôi lo lắng rằng các máy chủ web của tôi đang thực hiện TLS và các máy chủ xác thực của tôi, tất cả đều chạy trong các bộ chứa Docker tương tự, có thể không có đủ entropy để tạo khóa mạnh và miếng đệm dùng một lần cũng như các thử thách, v.v. Vì vậy, tôi muốn tìm hiểu sâu về cách đảm bảo rằng các bộ chứa Docker của tôi có đủ entropy để thực hiện tốt công việc của chúng.

Đây không phải là cơ sở hạ tầng quốc gia quan trọng hoặc thứ gì đó mà việc cài đặt mô-đun RNG phần cứng sẽ phù hợp. Đây chỉ là các bộ chứa Docker được lưu trữ trên đám mây, vì vậy tôi hy vọng có một giải pháp mà tôi có thể triển khai trong các bộ chứa/hình ảnh Docker của mình.

Vì bạn đang nói chuyện với kernel, nên nó hoàn toàn không liên quan đến docker:

$ mèo /proc/sys/kernel/random/entropy_avail
3771

$ docker run -it --rm busybox mèo /proc/sys/kernel/random/entropy_avail
3781

$ mèo /proc/sys/kernel/random/entropy_avail
3800

Nếu bạn nhận được nhiều entropy hơn trên máy chủ, thì bạn sẽ có nhiều entropy hơn trong vùng chứa.

Những giai thoại mà bạn đã thấy cùng một trích dẫn trong ngày gần đây không phải là bằng chứng cho thấy RNG của bạn có vấn đề.

Sử dụng Python's Random (không phải SystemRandom) cho mọi thứ thiếu mật mã quan trọng về bảo mật. Hạt giống theo mặc định. Lưu ý rằng bất kỳ số nguyên duy nhất hợp lý nào cũng sẽ hoạt động như hạt giống, đặc biệt không thể phát hiện ra chất lượng của RNG bằng cách tạo hạt giống khác.

Còn SystemRandom thì sao? Đây là API của Python để nhận các RNG dành riêng cho nền tảng không mang tính quyết định và do đó tốt hơn cho việc sử dụng mật mã.

Các bit ngẫu nhiên không phải là hiếm hoặc đặc biệt trên Linux, đó là một huyền thoại. CSPRNG của hạt nhân là tốt và sau khi được khởi chạy, có thể được sử dụng ở chế độ không chặn (/dev/urandom, getrandom với GRND_NONBLOCK) cho số lượng lớn bit ngẫu nhiên. Trên thực tế kể từ 5.6, đó là cách nó hoạt động, Linux không còn có nhóm chặn. /dev/random chỉ chặn khi khởi động trước khi khởi tạo kernel rng. Về lâu dài, đây là một giải pháp thực sự, hãy nâng cấp kernel và các chương trình có thể có bao nhiêu bit tùy thích.

Vấn đề là, mọi người vẫn nghĩ rằng các API chặn tốt hơn, mặc dù việc từ chối dịch vụ gây ra khi một nhóm chặn đã cạn kiệt. Python đã khắc phục sự cố làm cạn kiệt nhóm chặn trong tập lệnh khởi động sớm... bằng cách chặn os.urandom() trên Linux. Thở dài.