以非 root 用戶身份運行的 docker 容器進程無法寫入 docker 卷

Question

TLDR

• 每個人都建議容器內的進程永遠不要以 root 身份運行
• （除了kubernetes ）似乎沒有一個好的 devops/configuration-as-code 方法來在 docker 卷上設置正確的所有者/權限，因此（非 root）用戶無法寫入卷

當以non-root用戶身份運行容器進程並且我想寫入（cloudstor，aws-ebs）docker 卷時，什么是好的做法。

---

很長的故事

在（和外部）docker 容器中以 root 身份運行進程被認為是不好的做法（參見例如ref1 ，ref2 ，...）。 這可能具有安全隱患。

但是當我們開始使用 docker 卷並且非 root 用戶嘗試寫入卷時，麻煩就開始了。 我找不到一個干凈的解決方案，可以在沒有人工干預的情況下在雲基礎設施上運行。 我發現的所有工作解決方案似乎都在某些方面存在不足（安全性、可維護性……）。

作為旁注，我們正在使用cloudstor在docker-swarm上部署aws-ebs卷。 我們希望有朝一日遷移到 kubernetes，但我們還沒有 kubernetes，因此我們嘗試為我們的設置尋找替代解決方案。

考慮的解決方案/變通方法

1. 在 docker 鏡像中預先創建卷

作為建議在這里，如果docker-compose創建新卷，對圖像內的目錄的權限將被傳播。

缺點：

• 如果該卷之前存在，或者它是磁盤上的文件夾，這將不起作用
• 如果使用cloudstor配置卷，這可能也不起作用，因為它不會通過docker-compose配置卷（未測試）

2. 使用volumes-provisioner

hasat 創建了一個volumes-provisioner映像，它可以在真正的容器啟動之前設置正確的文件夾權限。

缺點：

• 需要在 docker 堆棧中添加額外的服務。 該服務幾乎立即終止（設置權限后）。
• 真正的容器需要依賴於volumes_provisioner。 重新部署同一個堆棧時（配置更改后），執行順序無法保證
• ebs卷只能掛載在單個 docker 容器上，這導致了很多部署問題

3. 使用docker run修正文件權限

一旦真正的容器在安裝了卷的情況下運行（但仍然具有錯誤的權限），我們調用

docker run --rm -u root -v ${MOUNT}:${TARGET} { real_image } chown -R user:group ${TARGET}

缺點：

• ebs卷只能掛載在一個容器中，所以這會產生沖突
• 此命令只能在 docker-stack 部署后運行（否則尚未配置卷），因此在真正的容器啟動和正確的權限之間會有延遲。 這意味着在啟動時，真正的容器會發現具有錯誤權限的卷，因此只有在服務不斷檢查權限是否已更正時，這才會起作用。

4. 啟動容器時更改所有權

這意味着：

• 以root用戶身份啟動進程（否則我們無權更改目錄所有者/權限）
• 更改所有權/權限
• 切換到non-root用戶

缺點：

• 當容器進程以 root 身份運行時，還有一個（次要的？）時間段（安全隱患？）
• 需要破解入口點，覆蓋用戶，...官方圖像才能使其正常工作

5. 以 root 身份運行

這是最簡單的解決方案，但是安全性呢？ 每個人都建議不要這樣做？

6. 使用 Kubernetes

正如這里所建議的，使用 kubernetes，我們可以為卷分配一個組 ID。 這似乎在pods的kubernetes 文檔中得到證實。

缺點：

• （遺憾的是）我們還沒有使用kubernetes 。
• （未測試。）

7.在文件系統上創建具有正確權限的文件夾

確保文件系統上存在具有正確所有者/權限的目錄。

缺點

• 這不是雲存儲……如果容器切換到另一個節點怎么辦？ 或者如果服務器崩潰？ （這就是我們使用cloudstor ，它甚至允許我們切換可用區）
• 看起來不是很“配置即代碼”

Answer 1

我投票支持解決方案 4，以 root 身份更改權限然后以非 root 身份啟動應用程序沒有安全問題。 如果您的應用程序中存在安全漏洞，則無論在啟動之前發生什么，該應用程序仍不會以 root 身份運行。 您可以在入口點的腳本中執行此操作。