Kubernetes中怎么選Secrets管理器

Kubernetes中怎么選Secrets管理器，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

Secrets是Kubernetes中一種對象類型，用來保存密碼、私鑰、口令等敏感信息。那么在Kubernetes中，如何實現對Secrets的有效管理，以保障這些機密數據的安全呢？

Kubernetes內置的Secrets管理

Kubernetes提供了一種內置機制，用于存儲用戶希望保密的配置值。 它們可以對特定名稱空間進行訪問控制，默認情況下，它們的內容不會顯示在kubectl get或 describe 輸出中。 它們是base64編碼的，因此即使直接從 kubectl 中提取內容，內容也不會立即顯現。

這些 secrets 以 plaintext 形式存儲在集群的etcd服務器上，除非將etcd配置為使用TLS加密通信，否則當etcd集群同步時，這些機密在線上可見。 此外，擁有或可以獲得集群中任何節點的root訪問權限的任何人，都可以通過模擬 kubelet 來讀取所有機密數據。

因此，除非您的安全要求非常低，否則建議使用第三方解決方案來保護機密數據。

來自第三方的Secrets管理器

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

• 來自云供應商的Secrets管理解決方案；

• 自己運行的開源解決方案，無論是在集群中還是在周圍；

• 來自各種供應商的專有解決方案。

1、云管平臺的Secrets商店

如果您在其中一個主要的公有云中運行，并且已經購買其Secrets管理服務，或者您只是想快速創建并且不考慮潛在的供應商鎖定，那么云托管解決方案是一個不錯的選擇，比如AWS Secrets Manager。

2、開源的Secrets管理器

如果使用裸機，想要避免云供應商鎖定，擔心云供應商解決方案的安全性，或者需要與現有企業標準集成，您可能需要選擇一個軟件解決方案。

1）Vault

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

它還提供了幾個獨特的功能：

• 完全私有的Cubbyholes，Token 令牌是唯一可以訪問數據的人。

• 動態secrets。 Vault可以在數據庫和云IAM中自動創建帳戶和憑據。

• PKI證書和SSH證書生成引擎，允許使用單個API調用生成和存儲證書。

• 跨區域、跨云、跨數據中心復制，支持過濾器以限制不應跨群集傳輸的數據。

• 支持各種身份驗證方法，并在需要時支持MFA。

2）Sealed Secrets

Kubernetes樣式編排的一個好處是配置基于一組聲明性json或yaml文件，可以很容易地存儲在版本控制中，可以基于Git將操作變更自動化為單一事實。 這意味著，負載配置的每個更改都可以與應用程序代碼進行相同的拉取請求和同行評審過程。

但是，像Vault這樣的傳統Secrets管理方法，以及上述所有云存儲都為在Git之外管理的Secrets數據引入了第二個真實來源——在集群中引入了另一個完全獨立跟蹤的潛在變更/故障源。 這可能會使故障排除變得復雜，也會導致所有集群配置更改的審核日志記錄變得復雜。

Sealed Secrets專為解決這一問題而設計。 它的工作原理是在Kubernetes集群中運行一個帶有機密數據和公鑰的控制器，并提供一個可以在標準配置文件中使用的加密字符串，并且只能由包含該私鑰的控制器解密。

也就是說，可以將安全憑證直接存儲在Git中的配置文件，和所有需要訪問它的人共享Git存儲庫，但這些用戶都不能訪問這些憑據。這可用于創建基于GitOps的安全工作流。

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