Kubernetes中怎么選Secrets管理器

Kubernetes中怎么選Secrets管理器，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

Secrets是Kubernetes中一種對(duì)象類(lèi)型，用來(lái)保存密碼、私鑰、口令等敏感信息。那么在Kubernetes中，如何實(shí)現(xiàn)對(duì)Secrets的有效管理，以保障這些機(jī)密數(shù)據(jù)的安全呢？

Kubernetes內(nèi)置的Secrets管理

Kubernetes提供了一種內(nèi)置機(jī)制，用于存儲(chǔ)用戶(hù)希望保密的配置值。 它們可以對(duì)特定名稱(chēng)空間進(jìn)行訪問(wèn)控制，默認(rèn)情況下，它們的內(nèi)容不會(huì)顯示在kubectl get或 describe 輸出中。 它們是base64編碼的，因此即使直接從 kubectl 中提取內(nèi)容，內(nèi)容也不會(huì)立即顯現(xiàn)。

這些 secrets 以 plaintext 形式存儲(chǔ)在集群的etcd服務(wù)器上，除非將etcd配置為使用TLS加密通信，否則當(dāng)etcd集群同步時(shí)，這些機(jī)密在線上可見(jiàn)。 此外，擁有或可以獲得集群中任何節(jié)點(diǎn)的root訪問(wèn)權(quán)限的任何人，都可以通過(guò)模擬 kubelet 來(lái)讀取所有機(jī)密數(shù)據(jù)。

因此，除非您的安全要求非常低，否則建議使用第三方解決方案來(lái)保護(hù)機(jī)密數(shù)據(jù)。

來(lái)自第三方的Secrets管理器

Kubernetes中有3種基本類(lèi)別的Secrets管理解決方案，如果您的要求超出了內(nèi)置Secrets功能設(shè)置的極低條件，您應(yīng)該考慮這些類(lèi)別：

• 來(lái)自云供應(yīng)商的Secrets管理解決方案；

• 自己運(yùn)行的開(kāi)源解決方案，無(wú)論是在集群中還是在周?chē)?/p>

• 來(lái)自各種供應(yīng)商的專(zhuān)有解決方案。

1、云管平臺(tái)的Secrets商店

如果您在其中一個(gè)主要的公有云中運(yùn)行，并且已經(jīng)購(gòu)買(mǎi)其Secrets管理服務(wù)，或者您只是想快速創(chuàng)建并且不考慮潛在的供應(yīng)商鎖定，那么云托管解決方案是一個(gè)不錯(cuò)的選擇，比如AWS Secrets Manager。

2、開(kāi)源的Secrets管理器

如果使用裸機(jī)，想要避免云供應(yīng)商鎖定，擔(dān)心云供應(yīng)商解決方案的安全性，或者需要與現(xiàn)有企業(yè)標(biāo)準(zhǔn)集成，您可能需要選擇一個(gè)軟件解決方案。

1）Vault

到目前為止，Kubernetes中使用最廣泛，最受歡迎且功能最豐富的Secrets管理器是Vault。Vault比云管理的解決方案功能更豐富且能保持一致性，可與EKS，GKE，本地群集以及可能運(yùn)行Kubernetes的任何位置完美配合。人們對(duì)基于Vault的云管理存儲(chǔ)也存在爭(zhēng)議，主要是由于很難設(shè)置和配置高性能的HA Vault集群，不過(guò)可以通過(guò)內(nèi)置的自動(dòng)化和支持來(lái)緩解。

它還提供了幾個(gè)獨(dú)特的功能：

• 完全私有的Cubbyholes，Token 令牌是唯一可以訪問(wèn)數(shù)據(jù)的人。

• 動(dòng)態(tài)secrets。 Vault可以在數(shù)據(jù)庫(kù)和云IAM中自動(dòng)創(chuàng)建帳戶(hù)和憑據(jù)。

• PKI證書(shū)和SSH證書(shū)生成引擎，允許使用單個(gè)API調(diào)用生成和存儲(chǔ)證書(shū)。

• 跨區(qū)域、跨云、跨數(shù)據(jù)中心復(fù)制，支持過(guò)濾器以限制不應(yīng)跨群集傳輸?shù)臄?shù)據(jù)。

• 支持各種身份驗(yàn)證方法，并在需要時(shí)支持MFA。

2）Sealed Secrets

Kubernetes樣式編排的一個(gè)好處是配置基于一組聲明性json或yaml文件，可以很容易地存儲(chǔ)在版本控制中，可以基于Git將操作變更自動(dòng)化為單一事實(shí)。 這意味著，負(fù)載配置的每個(gè)更改都可以與應(yīng)用程序代碼進(jìn)行相同的拉取請(qǐng)求和同行評(píng)審過(guò)程。

但是，像Vault這樣的傳統(tǒng)Secrets管理方法，以及上述所有云存儲(chǔ)都為在Git之外管理的Secrets數(shù)據(jù)引入了第二個(gè)真實(shí)來(lái)源——在集群中引入了另一個(gè)完全獨(dú)立跟蹤的潛在變更/故障源。 這可能會(huì)使故障排除變得復(fù)雜，也會(huì)導(dǎo)致所有集群配置更改的審核日志記錄變得復(fù)雜。

Sealed Secrets專(zhuān)為解決這一問(wèn)題而設(shè)計(jì)。 它的工作原理是在Kubernetes集群中運(yùn)行一個(gè)帶有機(jī)密數(shù)據(jù)和公鑰的控制器，并提供一個(gè)可以在標(biāo)準(zhǔn)配置文件中使用的加密字符串，并且只能由包含該私鑰的控制器解密。

也就是說(shuō)，可以將安全憑證直接存儲(chǔ)在Git中的配置文件，和所有需要訪問(wèn)它的人共享Git存儲(chǔ)庫(kù)，但這些用戶(hù)都不能訪問(wèn)這些憑據(jù)。這可用于創(chuàng)建基于GitOps的安全工作流。

看完上述內(nèi)容，你們掌握Kubernetes中怎么選Secrets管理器的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！