眾所周知，Kubernetes secret 只是以 base64 編碼的字符串，存儲在集群的其余狀態旁邊的 etcd 中。自 2015 年引入 secret 以來，安全專家就一直在嘲笑這一決定，并尋求其他替代方案。我認為這些人沒有抓住要點。

譯自Plain Kubernetes Secrets are fine。

密鑰 API 的設計可以追溯到 Kubernetes v0.12 之前。在最初的設計文檔之前的一個討論中，有一行字暗示了為什么人們可能會對密鑰感到困惑:

沒有威脅模型，很難評估這些替代方案

這正是問題所在。保護軟件的天真方法是盲目實施安全功能清單。但是更深入地了解安全性會很快發現，完美的安全是不可能的；您必須做出權衡并優先考慮最有可能的場景。創建威脅模型可以幫助您做出這些決定。讓我們為 Kubernetes 密鑰創建一個簡單的威脅模型，看看會出現什么。

我們在保護什么？

Secret通常用于存儲數據庫密碼和私鑰，這意味著它們是一個高價值目標。

安全失敗看起來像什么？

如果攻擊者能夠讀取Secret，他們可以使用它執行進一步的攻擊，例如竊取數據、修改/刪除/勒索數據，或者獲得授權執行諸如開采加密貨幣的 Pod 等操作。通常，我們會使用類似DREAD的東西來對不同攻擊的嚴重性進行排名，但暴露Secret有點雙重的，除非我們有一個特定的Secret。

如何偷竊Secret(會出什么問題)？

至少，Secret需要以純文本的形式存在于需要它的任何應用程序的內存中，在同一節點上的另一個進程可以(幾乎)總是通過足夠的毅力來偷竊它。我們還需要在某個持久的地方存儲Secret。在我們的例子中，Secret存儲在 etcd 中，可以從 Kubernetes API 訪問。

由于Secret必須存在于這兩個地方，所以它們可以通過以下任何方式被竊取:

1. 同一節點上的惡意進程(掃描內存，如果不強制安全上下文，直接從 /proc 或 CRI 讀取)
2. 控制平面節點的根訪問(讀取 etcd 的內存，讀取磁盤轉儲，或竊取客戶端證書并直接連接)
3. 工作節點的根訪問(竊取 kubelet 的客戶端證書并從 API 服務器讀取Secret，或直接讀取Secret文件/環境變量)
4. 控制平面節點物理服務器的訪問(將硬盤連接到另一臺計算機并讀取 etcd 數據或轉儲 RAM)
5. 未來意外攻擊(這是一個總括，有助于我們選擇具有更小攻擊面積的解決方案)

一些更古怪的黑客攻擊，如社會工程、惡意內部人員、人為錯誤/配置錯誤或硬件供應鏈攻擊當然是可能的，但在 Kubernetes 可以現實主義地解決的范圍之外。

我們如何防止這些攻擊？

對于攻擊#1：從內存中竊取Secret是我們不得不容忍的風險。應用程序可以使用自動過期令牌或多重身份驗證，但由于這些功能依賴于特定應用程序，因此不在范圍內。

對于攻擊#2和#3：節點的根訪問是一個巨大的問題。這可以通過常規的服務器加固、修補和防止特權 Pod 運行來減輕，但這是一個非常復雜的威脅要解決。

對于攻擊#4：對物理服務器的訪問在一定程度上可以通過加密靜態磁盤來減輕。至關重要的是，加密密鑰必須存儲在單獨的安全域中才能獲得任何安全性好處。但由于物理訪問通常意味著游戲結束，所以你只需要一些嚴密的物理安全性。

對于攻擊#5：在這里，我們不得不賭一把未來是否會出現零天漏洞。我們可以通過選擇更簡單和經過良好測試的方法來提高我們的機會，沒有比普通 Kubernetes Secret 更簡單的了。

威脅模型的啟示

威脅模型揭示了一個不方便的事實，即存儲Secret很難，因為明文版本必須存在某個地方(與例如密碼哈希形成對比)。這只是可逆加密的問題。

任何改進現有Secret實現的方法都必須減輕更多的攻擊，但是我認為沒有一種替代plain Kubernetes Secret的方案提供足夠的額外安全性來值得麻煩。

Kubernetes 密鑰的替代方案

讓我們看看一些存在的替代方案，看看它們的測量結果如何。

etcd 靜態加密

我很震驚這個仍然是 #1 推薦的替代方案，考慮到它的作用有多荒謬。

etcd 靜態加密涉及使用存儲在 etcd 本身相同文件系統上的密鑰加密 etcd 中的所有Secret。因此，我們的威脅模型中的四種攻擊都沒有得到緩解。甚至“物理訪問”攻擊也不行，因為密鑰存儲在同一磁盤上! 或者至少是另一個磁盤，可以從同一主機訪問(文檔中甚至沒有提到的選項)。

通過 KMS 加密 etcd

您可以使用來自您最喜歡的云提供商的密鑰管理服務(KMS)替換上述方法中的加密密鑰。

雖然這被列為“最強”的方法，但根據我們的威脅模型，它基本上與普通 Kubernetes 密鑰一樣不安全。能夠訪問節點的攻擊者可以像 etcd 那樣解密Secret，然后再將它們竊取出去。至少，這可以減輕對磁盤的物理訪問，如果且僅當 KMS 客戶端使用自動輪換的多重身份驗證令牌向云提供商進行身份驗證時。

使用此選項需要對云提供商進行硬依賴，需要大量的復雜性，并且如果它曾經中斷，會有很大的故障半徑。如果您被迫加密靜態Secret以符合合規性，盡管它實際上沒有改善您的安全態勢，但這確實是您最好的選擇。

Bitnami Sealed Secrets

Sealed Secrets真的不是Secret的替代品，但我見過人們認為它們是。Sealed Secrets允許您將加密的Secret存儲在版本控制中。當您將 SealedSecretkubectl apply到集群時，它會自動被解密并轉換為普通 Kubernetes Secret 的 Sealed Secrets 控制器。

由于 SealedSecrets 會變成普通的Secret，我們的威脅模型中的任何攻擊都沒有得到緩解。如果您沒有其他安全地方存儲Secret，SealedSecrets 是不錯的選擇，但是我們的威脅模型認為集群外部的Secret存儲在范圍之外。

Vault Sidecar 注入器

這是人們指向的大問題。從本質上說，Vault 只是一個帶有一些關鍵功能的鍵值存儲:

1. 一個聰明的Shamir 密封進程，人們很快會禁用它，而使用自動解封，這就像 etcd 通過 KMS 加密一樣消除了密封的好處。
2. 一個豐富的策略語言，很少有人會去學習。
3. 很好的審計，沒有人監控。

因此，從根本上說，除非您為托管 Vault 實例或公司內 Vault 專家團隊支付費用，否則 Vault 只是一個鍵值存儲。我曾在一家擁有整個團隊運行 HSM 支持的企業版 Vault 的公司工作過，但那東西仍然經常宕機。

但是，讓我們假設您有足夠的財力維護一個不可能完美的 Vault 實例。您剛剛在 Kubernetes 集群中安裝了Vault Sidecar 注入器。您能從這個復雜的安排中獲得足夠的安全性嗎? 我認為不能。

sidecar 注入器的工作原理是修改 pod 以包含 Vault 客戶端 sidecar，該 sidecar 向您的 Vault 服務器進行身份驗證，下載Secret，并將其存儲在您的應用程序可以像常規文件一樣訪問的共享內存卷中。

對于攻擊#1：由于Secret仍在內存中，因此攻擊者仍然可以從節點中竊取它。

對于攻擊#2和#3：如果攻擊者入侵任何節點(工作程序或控制平面)，他們可以運行任何具有正確 Vault 注釋的 pod 并竊取Secret。

對于攻擊#4：如果有人訪問物理節點，他們無法從磁盤獲取Secret，但他們可以獲取與普通Secret相關的服務帳戶的保險庫憑據，并且如果您在 Kubernetes 內運行 Vault，則可以這樣竊取Secret。

但是，您仍然必須擔心 Vault 運行所在服務器的物理訪問。Vault 在“密封”時會對靜態數據進行加密，但是如果您使用自動解封，則攻擊者可以使用磁盤上的云憑據模擬該過程。該死的，有物理訪問權限的人無需麻煩地讀取您的磁盤；如果您有一個可用的 PCI 插槽，他們可以直接轉儲 RAM。

對于攻擊#5：運行 Vault 的復雜性極大地增加了您的攻擊面。我比大多數公司都更相信 HashiCorp 會抓住問題，但更多的運動部件總是更多的風險。有時候這種風險是值得的(是的，散列密碼比不散列更復雜，但優點顯然大于缺點)，但是只有在緩解了其他 4 種攻擊的情況下才值得。

因此，根據我們的威脅模型，使用 Vault 引入了一些間接層，但最終并沒有解決比普通 Kubernetes Secrets 更多的攻擊。使用加密磁盤并將密鑰存儲在安全的地方會以更簡單、更便宜的方式提供相同級別的安全性。

結論

通過創建一個包括你想要緩解的攻擊類型的威脅模型，很明顯，安全地管理機密信息非常困難。問題不在于機密信息只是 base64 編碼；這從未被設計成一個安全功能。這個問題也不能簡單地通過軟件/云提供商及其花哨的文檔來回避。

對于如此安全敏感和困難的存儲機密信息，應從威脅模型開始。如果根據威脅模型，多個解決方案具有類似的安全性，選擇更簡單的一個來減少整體攻擊面。