共計 1742 個字符，預計需要花費 5 分鐘才能閱讀完成。

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 管理器的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！