在K8s集群中存儲和部署證書/密鑰，核心是避免明文存儲和版本控制泄露，推薦以下3種安全且常用的方案，按“輕量到企業級”排序： 

1. 基礎方案：用K8s原生的Secret資源（無額外組件） 

這是最輕量的方式，適合中小集群或簡單場景，直接利用K8s內置能力管理密鑰。 

- 存儲邏輯：將證書/密鑰（如TLS證書、API密鑰）以 Secret 資源形式存儲在K8s集群中，數據會被Base64編碼（注意：非加密，需配合RBAC權限控制訪問）。 
? 
- 部署方式： 
? 
1. 手動創建：通過 kubectl create secret 命令，例如創建TLS證書： 
 kubectl create secret tls my-tls-secret --cert=path/to/tls.crt --key=path/to/tls.key 。 
? 
2. 配置文件創建：寫 Secret 的YAML文件（避免提交到GitHub），通過 kubectl apply -f secret.yaml 部署。 
? 
- 使用方式：Pod通過“環境變量注入”或“文件掛載”使用Secret，例如在Deployment中指定 secretMounts 掛載證書到容器內路徑。 

2. 進階方案：用Sealed Secrets（適合GitOps流程） 

如果需要將密鑰配置納入Git版本控制（配合GitOps工具如ArgoCD/Flux），Sealed Secrets能解決“密鑰明文存Git”的風險。 

- 核心原理：通過“密封密鑰”機制——將K8s Secret用集群唯一的公鑰加密成 SealedSecret （加密后的數據可安全存Git），集群內的 sealed-secrets-controller 組件用私鑰解密，自動生成原生Secret。 
? 
- 部署步驟： 
? 
1. 在K8s集群部署 sealed-secrets-controller （通過Helm或YAML部署）。 
? 
2. 在本地安裝 kubeseal 工具，用集群公鑰加密原始Secret： 
 kubectl create secret generic my-secret --from-literal=key=value --dry-run=client -o yaml | kubeseal --format=yaml > sealed-secret.yaml 。 
? 
3. 將 sealed-secret.yaml 提交到Git，GitOps工具同步到集群后，控制器自動解密生成Secret。 

3. 企業級方案：集成外部KMS（適合高安全需求） 

如果對密鑰安全要求極高（如金融、政務場景），需用獨立的密鑰管理系統（KMS）存儲根密鑰，避免密鑰泄露風險。 

- 支持的KMS：主流有HashiCorp Vault、AWS KMS、Azure Key Vault、GCP KMS，或開源的Vault（最常用）。 
? 
- 存儲與部署邏輯： 
? 
1. 在集群外部署KMS（如Vault服務器），將核心證書/密鑰存儲在KMS中，K8s不直接存原始密鑰。 
? 
2. 在K8s集群部署KMS客戶端插件（如Vault Agent Injector），通過插件向Pod動態注入密鑰（無需在集群內持久化密鑰）。 
? 
- 優勢：KMS提供密鑰生命周期管理（生成、輪換、銷毀）、細粒度權限控制和審計日志，安全性遠高于原生Secret。 

關鍵注意事項 

- 禁止將任何明文密鑰、 Secret 的YAML文件（未密封）提交到GitHub，可在 gitignore 中排除 secret/ 目錄或 *.secret.yaml 文件。 
? 
- 無論用哪種方案，都需配置K8s RBAC權限，限制 Secret 的訪問（僅授權必要的Pod/ServiceAccount讀取）。 
? 
- 定期輪換密鑰：原生Secret需手動或寫腳本輪換，Sealed Secrets/KMS支持自動輪換，降低密鑰泄露風險。