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

譯自Plain Kubernetes Secrets are fine。

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

沒(méi)有威脅模型，很難評(píng)估這些替代方案

這正是問(wèn)題所在。保護(hù)軟件的天真方法是盲目實(shí)施安全功能清單。但是更深入地了解安全性會(huì)很快發(fā)現(xiàn)，完美的安全是不可能的；您必須做出權(quán)衡并優(yōu)先考慮最有可能的場(chǎng)景。創(chuàng)建威脅模型可以幫助您做出這些決定。讓我們?yōu)?Kubernetes 密鑰創(chuàng)建一個(gè)簡(jiǎn)單的威脅模型，看看會(huì)出現(xiàn)什么。

我們?cè)诒Ｗo(hù)什么？

Secret通常用于存儲(chǔ)數(shù)據(jù)庫(kù)密碼和私鑰，這意味著它們是一個(gè)高價(jià)值目標(biāo)。

安全失敗看起來(lái)像什么？

如果攻擊者能夠讀取Secret，他們可以使用它執(zhí)行進(jìn)一步的攻擊，例如竊取數(shù)據(jù)、修改/刪除/勒索數(shù)據(jù)，或者獲得授權(quán)執(zhí)行諸如開(kāi)采加密貨幣的 Pod 等操作。通常，我們會(huì)使用類似DREAD的東西來(lái)對(duì)不同攻擊的嚴(yán)重性進(jìn)行排名，但暴露Secret有點(diǎn)雙重的，除非我們有一個(gè)特定的Secret。

如何偷竊Secret(會(huì)出什么問(wèn)題)？

至少，Secret需要以純文本的形式存在于需要它的任何應(yīng)用程序的內(nèi)存中，在同一節(jié)點(diǎn)上的另一個(gè)進(jìn)程可以(幾乎)總是通過(guò)足夠的毅力來(lái)偷竊它。我們還需要在某個(gè)持久的地方存儲(chǔ)Secret。在我們的例子中，Secret存儲(chǔ)在 etcd 中，可以從 Kubernetes API 訪問(wèn)。

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

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

一些更古怪的黑客攻擊，如社會(huì)工程、惡意內(nèi)部人員、人為錯(cuò)誤/配置錯(cuò)誤或硬件供應(yīng)鏈攻擊當(dāng)然是可能的，但在 Kubernetes 可以現(xiàn)實(shí)主義地解決的范圍之外。

我們?nèi)绾畏乐惯@些攻擊？

對(duì)于攻擊#1：從內(nèi)存中竊取Secret是我們不得不容忍的風(fēng)險(xiǎn)。應(yīng)用程序可以使用自動(dòng)過(guò)期令牌或多重身份驗(yàn)證，但由于這些功能依賴于特定應(yīng)用程序，因此不在范圍內(nèi)。

對(duì)于攻擊#2和#3：節(jié)點(diǎn)的根訪問(wèn)是一個(gè)巨大的問(wèn)題。這可以通過(guò)常規(guī)的服務(wù)器加固、修補(bǔ)和防止特權(quán) Pod 運(yùn)行來(lái)減輕，但這是一個(gè)非常復(fù)雜的威脅要解決。

對(duì)于攻擊#4：對(duì)物理服務(wù)器的訪問(wèn)在一定程度上可以通過(guò)加密靜態(tài)磁盤(pán)來(lái)減輕。至關(guān)重要的是，加密密鑰必須存儲(chǔ)在單獨(dú)的安全域中才能獲得任何安全性好處。但由于物理訪問(wèn)通常意味著游戲結(jié)束，所以你只需要一些嚴(yán)密的物理安全性。

對(duì)于攻擊#5：在這里，我們不得不賭一把未來(lái)是否會(huì)出現(xiàn)零天漏洞。我們可以通過(guò)選擇更簡(jiǎn)單和經(jīng)過(guò)良好測(cè)試的方法來(lái)提高我們的機(jī)會(huì)，沒(méi)有比普通 Kubernetes Secret 更簡(jiǎn)單的了。

威脅模型的啟示

威脅模型揭示了一個(gè)不方便的事實(shí)，即存儲(chǔ)Secret很難，因?yàn)槊魑陌姹颈仨毚嬖谀硞€(gè)地方(與例如密碼哈希形成對(duì)比)。這只是可逆加密的問(wèn)題。

任何改進(jìn)現(xiàn)有Secret實(shí)現(xiàn)的方法都必須減輕更多的攻擊，但是我認(rèn)為沒(méi)有一種替代plain Kubernetes Secret的方案提供足夠的額外安全性來(lái)值得麻煩。

Kubernetes 密鑰的替代方案

讓我們看看一些存在的替代方案，看看它們的測(cè)量結(jié)果如何。

etcd 靜態(tài)加密

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

etcd 靜態(tài)加密涉及使用存儲(chǔ)在 etcd 本身相同文件系統(tǒng)上的密鑰加密 etcd 中的所有Secret。因此，我們的威脅模型中的四種攻擊都沒(méi)有得到緩解。甚至“物理訪問(wèn)”攻擊也不行，因?yàn)槊荑€存儲(chǔ)在同一磁盤(pán)上! 或者至少是另一個(gè)磁盤(pán)，可以從同一主機(jī)訪問(wèn)(文檔中甚至沒(méi)有提到的選項(xiàng))。

通過(guò) KMS 加密 etcd

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

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

使用此選項(xiàng)需要對(duì)云提供商進(jìn)行硬依賴，需要大量的復(fù)雜性，并且如果它曾經(jīng)中斷，會(huì)有很大的故障半徑。如果您被迫加密靜態(tài)Secret以符合合規(guī)性，盡管它實(shí)際上沒(méi)有改善您的安全態(tài)勢(shì)，但這確實(shí)是您最好的選擇。

Bitnami Sealed Secrets

Sealed Secrets真的不是Secret的替代品，但我見(jiàn)過(guò)人們認(rèn)為它們是。Sealed Secrets允許您將加密的Secret存儲(chǔ)在版本控制中。當(dāng)您將 SealedSecretkubectl apply到集群時(shí)，它會(huì)自動(dòng)被解密并轉(zhuǎn)換為普通 Kubernetes Secret 的 Sealed Secrets 控制器。

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

Vault Sidecar 注入器

這是人們指向的大問(wèn)題。從本質(zhì)上說(shuō)，Vault 只是一個(gè)帶有一些關(guān)鍵功能的鍵值存儲(chǔ):

1. 一個(gè)聰明的Shamir 密封進(jìn)程，人們很快會(huì)禁用它，而使用自動(dòng)解封，這就像 etcd 通過(guò) KMS 加密一樣消除了密封的好處。
2. 一個(gè)豐富的策略語(yǔ)言，很少有人會(huì)去學(xué)習(xí)。
3. 很好的審計(jì)，沒(méi)有人監(jiān)控。

因此，從根本上說(shuō)，除非您為托管 Vault 實(shí)例或公司內(nèi) Vault 專家團(tuán)隊(duì)支付費(fèi)用，否則 Vault 只是一個(gè)鍵值存儲(chǔ)。我曾在一家擁有整個(gè)團(tuán)隊(duì)運(yùn)行 HSM 支持的企業(yè)版 Vault 的公司工作過(guò)，但那東西仍然經(jīng)常宕機(jī)。

但是，讓我們假設(shè)您有足夠的財(cái)力維護(hù)一個(gè)不可能完美的 Vault 實(shí)例。您剛剛在 Kubernetes 集群中安裝了Vault Sidecar 注入器。您能從這個(gè)復(fù)雜的安排中獲得足夠的安全性嗎? 我認(rèn)為不能。

sidecar 注入器的工作原理是修改 pod 以包含 Vault 客戶端 sidecar，該 sidecar 向您的 Vault 服務(wù)器進(jìn)行身份驗(yàn)證，下載Secret，并將其存儲(chǔ)在您的應(yīng)用程序可以像常規(guī)文件一樣訪問(wèn)的共享內(nèi)存卷中。

對(duì)于攻擊#1：由于Secret仍在內(nèi)存中，因此攻擊者仍然可以從節(jié)點(diǎn)中竊取它。

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

對(duì)于攻擊#4：如果有人訪問(wèn)物理節(jié)點(diǎn)，他們無(wú)法從磁盤(pán)獲取Secret，但他們可以獲取與普通Secret相關(guān)的服務(wù)帳戶的保險(xiǎn)庫(kù)憑據(jù)，并且如果您在 Kubernetes 內(nèi)運(yùn)行 Vault，則可以這樣竊取Secret。

但是，您仍然必須擔(dān)心 Vault 運(yùn)行所在服務(wù)器的物理訪問(wèn)。Vault 在“密封”時(shí)會(huì)對(duì)靜態(tài)數(shù)據(jù)進(jìn)行加密，但是如果您使用自動(dòng)解封，則攻擊者可以使用磁盤(pán)上的云憑據(jù)模擬該過(guò)程。該死的，有物理訪問(wèn)權(quán)限的人無(wú)需麻煩地讀取您的磁盤(pán)；如果您有一個(gè)可用的 PCI 插槽，他們可以直接轉(zhuǎn)儲(chǔ) RAM。

對(duì)于攻擊#5：運(yùn)行 Vault 的復(fù)雜性極大地增加了您的攻擊面。我比大多數(shù)公司都更相信 HashiCorp 會(huì)抓住問(wèn)題，但更多的運(yùn)動(dòng)部件總是更多的風(fēng)險(xiǎn)。有時(shí)候這種風(fēng)險(xiǎn)是值得的(是的，散列密碼比不散列更復(fù)雜，但優(yōu)點(diǎn)顯然大于缺點(diǎn))，但是只有在緩解了其他 4 種攻擊的情況下才值得。

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

結(jié)論

通過(guò)創(chuàng)建一個(gè)包括你想要緩解的攻擊類型的威脅模型，很明顯，安全地管理機(jī)密信息非常困難。問(wèn)題不在于機(jī)密信息只是 base64 編碼；這從未被設(shè)計(jì)成一個(gè)安全功能。這個(gè)問(wèn)題也不能簡(jiǎn)單地通過(guò)軟件/云提供商及其花哨的文檔來(lái)回避。

對(duì)于如此安全敏感和困難的存儲(chǔ)機(jī)密信息，應(yīng)從威脅模型開(kāi)始。如果根據(jù)威脅模型，多個(gè)解決方案具有類似的安全性，選擇更簡(jiǎn)單的一個(gè)來(lái)減少整體攻擊面。