使用kubernetes使用敏感信息填充Docker容器

Question

我有一個運行容器的容器，需要訪問API密鑰和數據庫密碼等敏感信息。 現在，這些敏感值嵌入在控制器定義中，如下所示：

env:
- name: DB_PASSWORD
  value: password

然后在Docker容器中作為$DB_PASSWORD環境變量提供。 一切都相當容易。

但是，閱讀他們關於Secrets的文檔，他們明確表示將敏感配置值放入您的定義中會違反最佳實踐，並且可能是一個安全問題。 我能想到的唯一其他策略如下：

• 為每個用戶社區或命名空間創建一個OpenPGP密鑰
• 使用crypt將配置值設置為etcd（使用私鑰加密）
• 創建一個包含私鑰的kubernetes秘密， 就像這樣
• 將該秘密與容器相關聯（意味着私鑰可以作為卷安裝訪問）， 就像這樣
• 當容器啟動時，它將訪問私有密鑰的卷掛載內的文件，並使用它來解密從etcd返回的conf值
• 然后可以將其合並到confd中 ， confd根據模板定義（例如Apache或WordPress配置文件）填充本地文件

這似乎相當復雜，但更安全和靈活，因為值不再是靜態的並以明文形式存儲。

所以我的問題，我知道這不是一個完全客觀的問題，這是否完全是必要的？ 只有管​​理員才能首先查看和執行RC定義; 所以，如果有人違反了kubernetes大師，你還有其他問題需要擔心。 我看到的唯一好處是沒有明文提交到文件系統的秘密的危險......

有沒有其他方法以安全的方式使用秘密信息填充Docker容器？

Answer 1

除非你有很多兆字節的配置，否則這個系統聽起來不必要地復雜。 預期用途是讓您將每個配置放入一個秘密，並且需要配置的pod可以將該秘密作為卷安裝。

然后，您可以使用各種機制中的任何一種將該配置傳遞給您的任務，例如，如果它是環境變量source secret/config.sh; ./mybinary source secret/config.sh; ./mybinary是一種簡單的方法。

我認為通過將私鑰存儲為秘密，您不會獲得任何額外的安全性。

Answer 2

我個人決定使用遠程密鑰管理器，您的軟件可以通過HTTPS連接通過網絡訪問。 例如Keywhiz或Vault可能適合該法案。

我會將密鑰管理器托管在一個單獨的隔離子網上，並將防火牆配置為僅允許訪問我希望需要密鑰的IP地址。 KeyWhiz和Vault都帶有ACL機制，所以你可能根本不需要對防火牆做任何事情，但考慮它並沒有什么壞處 - 但是這里的關鍵是在一個單獨的網絡上托管密鑰管理器，甚至可能一個單獨的托管服務商

容器中的本地配置文件將僅包含密鑰服務的URL，並且可能是從密鑰管理器檢索密鑰的憑證 - 如果攻擊者與ACL / IP地址不匹配，則憑據對於攻擊者將是無用的。