您是如何保護您的加密密鑰，資料庫密碼，比特幣錢包私鑰等秘密資料的？本文嘗試探討這一領域並涵蓋KeyWhiz，Vault，Docker 1.13，DC / OS 1.8，Rancher 1.4和Kubernetes。

最佳實踐

下述是一個集中式機密信息管理和分發的最佳實踐列表：

• 永遠不要將機密信息以明文的形式存儲在磁碟上

• 永遠不要將機密信息以明文的形式通過網路傳輸

• 所有的機密信息生命周期和訪問事件都應記錄在不可破壞的審核日誌中

• 機密信息分發應由權威的委託人（如容器/服務調度程序）協調，或與調度程序保持密切的信任關係

• 操作者對機密信息的明文的訪問應該受到限制

• 與機密信息管理和分發相關的所有基礎設施組件應相互認證

• 選擇安全的系統配置而不是先進的可能導致不安全的配置

• 應提供豐富（可插拔）的訪問控制機制保護附加到服務或容器的機密信息 - 基於角色的訪問控制是額外需要的

• 盡一切可能減少機密信息泄露對系統的影響

很難有一種解決方案能符合上述所有的標準。

獨立的機密信息管理器

KeyWhiz by Square

KeyWhiz（Apache-2）是由Square開發和使用的機密信息管理器。KeyWhiz依賴於現有的公鑰基礎設施（PKI），並將使用您希望提供的任意資料庫後端。

KeyWhiz本身就是一個機密信息管理系統的核心。它擅長做一件事情：將機密信息數據封裝在加密/解密屏障中，並將數據交給受信任的收件人。

哦，只是PKI。那應該很簡單的對嗎？

建立PKI是困難的...不，PKI是典型的InfoSec最佳實踐的完美示例。他們是輝煌的工具，但對少數建立和使用他們的人來說是一個沉重負擔，甚至是那些倡導使用它們的人。

操作員通過LDAP進行身份驗證和授權（這是KeyWhiz代理而不是集成的另一件事情）。這對已經有LDAP目錄的組織可能有好處，但對那些沒有LDAP目錄的組織增加了依賴項。一旦經過身份驗證和授權，操作員可以添加，更新，列出和查看機密信息。

機密信息在到達網路進入資料庫之前加密，並在管理員檢索時對其進行解密。KeyWhiz的作者強烈建議您使用HSM進行加密和解密，但您可以配置KeyWhiz來使用解鎖Key對數據加密和解密。

機密信息解密後，通過網路發送給消費者。網路連接使用相互認證的TLS，這意味著您的工作人員可以信任經理，您的經理可以信任並授權您的工作人員訪問機密信息，並且這些機密信息在線上是安全的。

KeyWhiz提到了部署協調器集成，但是我對此產品有限的經驗，並沒有找到並且實現它。該產品的文檔描述可以說「簡陋」，但產品是完全開源的，可以查看源代碼。我看到過KeyWhiz與Docker集成的Volume插件，而且我與使用它們的人討論時，對方沒有任何抱怨。該插件使用KeyWhizFS，它使機密信息可以在FUSE文件系統上使用（利用底層相互認證的TLS）。

總體來說，KeyWhiz似乎提供了比表面看上去要多很多的功能。我沒有看到有關機密信息訪問或生命周期審核記錄的任何內容。KeyWhiz的受眾是特定的，它能滿足先進的和資金充足的採用者的需求，他們可以投資建立和維護公共密鑰基礎設施（他們建議從另一個Square項目certstrap開始），LDAP以及管理另一個資料庫。我相信機密信息的更新會反映在KeyWhizFS的實時更改中，所以我不知道他們如何建議對這些更改做出反應並協調服務更新。我對文檔的當前狀態有點失望。

Vault by HashiCorp

Vault比KeyWhiz的出現要晚一些，它是一個HashiCorp全面開放的開源（MPL-2）產品。Vault的文檔非常強大，整合方案非常豐富。Vault是目前機密信息管理和配置的黃金標準，但也不完美。

Vault的文檔，示例，設計與目的的特異性不僅有助於讀者了解如何使用該產品，還可幫助引導和告知讀者如何看待問題空間。如果您想了解更多請查看文檔的 Internals > Architecture和Internals > Security Model部分。

Vault比本文列表中的所有其他項目要好一些。首先，機密信息訪問和生命周期審計是一個頂級的關注點。其次，沒有單一資料庫依賴或單一機密信息類型。相反，它有幾個可插拔的存儲後端來保存可能會持續存在機密信息，並支持提供/旋轉/摧毀機密信息。

Vault具有審計，機密信息和認證三種類型的存儲後端。所有後端系統都具有有用的默認值，但可以輕鬆地插拔。

用戶使用與文件系統中找到的名稱相似的名稱來使用機密信息。該名稱前綴為正在使用的機密信息存儲後端的名稱。Vault在自身和不同的存儲後端之間提供「柵欄」，確保一個壞的或受損的操作實體不會影響其他後端的操作。在Vault和存儲後端之間流動的所有數據也會通過加密柵欄。任何明文都不會通過網路（安全或其他），並且永遠不會寫入磁碟。

如前所述，Vault與動態的機密信息存儲後端集成，可以即時提供，旋轉和銷毀機密信息。這是一個強大的設計，可以大大降低任何特定機密信息的價值。Vault支持AWS，MySQL，MSSQL，MongoDB，Postgres，Consul，Cassandra等動態機密信息存儲後端。甚至還有SSH密鑰和PKI的動態存儲後端，可以即時生成X.509證書/密鑰。

不是所有的機密信息都可以動態生成，但是您可以考慮採用這種做法。

Vault似乎所有操作都包含審計。 Vault的主要特點是與工作負載管理器集成。您將不得不為整合做一些工作，但有一些項目可以幫助。你可以看看用於Rancher的Rancher / secrets-bridge和一個Docker Volume插件：ehazlett / docker-volume-libsecret。我已經看到與Kubernetes集成的項目和問題，但是，呃。繼續閱讀。

小結

KeyWhiz的在特定範圍內非常棒。對於已經運行其許多依賴項目的團隊，採用它將是直接受益的。如果你陷入一個充滿靜態機密信息的世界，並且不需要太多的審計記錄方式，它將一定能夠適應現有的基礎架構。

另一方面，Vault是使您想要更改基礎架構的一種工具。有很多文章涵蓋了它，如果你可以使用它，而不會脫離你的產品的關鍵發展，我強烈推薦它。

集成的機密信息和工作負載管理

Docker and SwarmKit (1.13)

我想首先覆蓋Docker，因為這是一個新生，許多人可能不熟悉它的機密信息管理。 Docker在發布SwarmKit和Docker 1.12時發生了相當大的轉變。

1.13版的Docker已經推出了集成的機密信息管理。基於1.12和Swarm模式的基礎包括加密可識別節點，默認流量加密，以及相互驗證。

當您運行shell上面的「secret create」命令時，將明文數據輸入到docker命令中，而不需要向磁碟寫任何內容就可以通過TLS向您的一個Swarm管理器節點發出API請求。接收節點使用機密信息的名稱和明文材料，並在集群的加密Raft日誌中創建了一個新記錄。在Docker 1.13中，Master節點之間共享的資料庫被單獨加密。這裡重點強調， Docker的機密信息永遠不會寫入磁碟，從不通過網路發送。

OSS Docker缺少的是操作員RBAC和強大的審核日誌。每個機密信息有一個500kb的文件大小限制，但這可能不會是一個問題。

DC/OS by Mesosphere

DC/OS（Mesosphere）是開源項目（Apache-2）的集合，一個被一群真正了解自己在做什麼的人整合出來的優秀產品。從1.8開始，它們在企業版的Marathon中包含了機密信息管理API。

Mesosphere還使用TLS 1.2連接，這意味著對PKI的依賴。Mesosphere集群為此建立了內置的證書頒發機構。

在發送到ZooKeeper存儲之前，機密信息被加密（使用AES-GCM）。這意味著它們在傳輸過程中加密。用於加密原始機密數據的密鑰使用啟封密鑰（4096位GPG）在初始化時進行加密。

Mesosphere似乎不會保留任何加密的機密信息訪問或生命周期審核日誌。然而，它確實有一個內置的用戶認證和RBAC系統來控制對機密信息的訪問。該系統可用於實現每個機密信息級別的訪問控制（這是非常好的）。您還應該注意，單個機密信息限制為1MB。

Rancher and Cattle (1.4.0)

Rancher可以用來配置不同種類的平台，包括Docker，Mesos和Kubernetes。名為「Cattle」的默認工作負載管理器是開放源代碼的，它包含在任何Rancher安裝中。 Rancher 1.4包括實驗性的機密信息管理實施。

Rancher機密信息管理實現與Docker和Mesosphere的實現是一樣的。如果您正在考慮在生產環境中使用它，您一定要帶上您自己的Vault伺服器並進行集成。

Kubernetes (1.5.2 and earlier)

在Kubernetes中，認證，授權和TLS都是可選的。Kubernetes並不加密機密信息，Etcd默認情況下不加密網路通信。Kubernetes將與所有用戶分享您的機密信息。我在2017年的建議是跳過Kubernetes的機密信息管理。如果必須使用Kubernetes，可以集成一個真正的機密信息管理器。

小結

Docker，DC/OS和Rancher的機密信息管理都是比較新的。DC/OS企業版中有比較完善的機密信息管理方案，在OSS版本中需要自行集成。

文章來源：

https://medium.com/on-docker/secrets-and-lie-abilities-the-state-of-modern-secret-management-2017-c82ec9136a3d

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！