Docker安全性最佳實踐

您可以在Internet上找到的大多數Dockerfile都以root身份構建和運行軟件！這必須嚇唬大家，對吧？ ...但似乎並非如此...Docker安全性最佳實踐

因此，pb是運行一個服務器作爲根，即使在一個容器中，是危險的，因爲容器內的根與根相當在容器外面。

其中一個解決方案是通過使用「USER」指令（如this example for a tor relay）正確構建Dockerfile。

另一種解決方案是使用「linux用戶名空間」將容器內的UID/GID「映射」到容器外部的UID/GID。例如，在一個容器內的根（uid = 0）可以映射到主機內的個人用戶帳戶，因此在共享卷中創建的文件具有良好的權限。

所以我的問題是：當涉及到Docker的安全性時，最佳實踐是什麼？以非根的方式運行代碼（即Dockerfile中的USER指令）？或通過使用「用戶名稱空間」？或者最終（或另外）使用selinux和/或AppArmor？

謝謝:)

來源

2014-12-02 kondor

我也想補充一點，它通常是不希望運行的應用程序（例如像Web服務器）作爲根 – kondor 2014-12-09 14:24:55

這個文件看起來有趣： [泊塢窗安全部署指南] （https://github.com/GDSSecurity/Docker-Secure-Deployment-Guidelines） – kondor 2015-01-23 12:32:58

報價Solomon Hykes

大家好，我是碼頭工人的維護者。正如其他人已經表明，這不適用於1.0。但它可能有。

請記住，在這個時候，我們並沒有聲稱Docker立即可用於包含具有root權限的不受信任的程序。所以如果你想「我們升級到1.0或者我們敬酒的好東西」，你現在需要改變你的底層配置。添加apparmor或selinux遏制，將信任組映射到單獨的機器，或理想情況下不授予對應用程序的根訪問權限。

因此，就最佳實踐而言，如果您對安全性有嚴肅認識，那麼命名空間和apparmor或selinux是肯定的。話雖如此，但很多人並不在乎去追加額外的麻煩（無論好壞），所以你看到很多人不會去麻煩。爲容器內的文件（特別是裝載爲卷的文件）的用戶設置權限有時會變得棘手，這就是很多人跳過額外的開銷。

來源

2014-12-24 16:34:05