Kubernetes 集群密鑰與機密管理方案對比分析：Vault、Sealed Secrets 與 AWS KMS

在容器化與編排環境中，機密（Secrets）管理是確保應用安全性的重要環節。對于 Kubernetes 集群而言，內置的 Secret 對象存在明文存儲的風險，如何在保證可用性、易運維的前提下，實現機密的安全存儲、自動化分發與訪問控制，成為 DevOps 和安全團隊的核心訴求。

本文將從問題背景出發，詳細對比三種主流的機密管理方案：HashiCorp Vault、Bitnami Sealed Secrets 以及 AWS KMS（Key Management Service）集成方案，分析它們的架構特點、使用流程與優缺點，并結合實戰案例驗證效果，給出在不同場景下的選型建議。

1. 問題背景介紹

Kubernetes 原生 Secret 對象默認采用 Base64 編碼存儲，未經加密保護，直接保存在 etcd 中。一旦集群未啟用加密，或者 etcd 自身沒有磁盤加密，攻擊者如果獲得 etcd 訪問權限，即可讀取所有機密信息。

此外，機密在集群內以明文方式掛載到 Pod 中，在運行時也可能被二次泄露。企業在生產環境中通常需要滿足以下安全需求：

靜態加密：在 etcd 存儲層，對機密進行靜態加密，防止泄露風險。
動態加密：在傳輸和運行時，確保機密在網絡和內存中都是安全的。
細粒度訪問控制：基于角色或服務帳戶實施最小權限原則，只允許經過授權的 Pod/應用訪問特定機密。
自動化與可審計性：支持集中審計、審計日志記錄訪問歷史，并具備機密自動輪換能力。

為此，社區和云廠商先后推出多種解決方案，以彌補原生 Secret 的安全短板。接下來，我們將對比三種主流方案的原理與實踐流程。

2. 多種解決方案對比

2.1 HashiCorp Vault

HashiCorp Vault 是一款專注于機密管理的開源產品，提供集中式機密存儲、動態憑據生成、審計日志和密鑰輪換等功能。

架構原理

Vault Server：核心服務組件，負責加密/解密，一般以 HA 模式部署。
Storage Backend：多選項支持，比如 Consul、etcd、DynamoDB。
Auth Methods：支持 Kubernetes、AppRole、TLS、LDAP、OIDC 等認證方式。
PKI、Transit：提供證書管理與加密（Transit 引擎）。
審計引擎：記錄每次讀寫操作。

當 Kubernetes 集群中的應用需要機密時：

Pod 啟動后，通過 ServiceAccount Token 向 Vault 登錄（Auth 方法）。
Vault 校驗 Token 后，頒發短期訪問令牌（Lease）。
應用使用該臨時令牌讀取 Secrets（靜態或動態生成）。

部署與使用示例

部署 Vault：

helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault --set "server.ha.enabled=true" --namespace vault

開啟 Kubernetes Auth：

vault auth enable kubernetes
vault write auth/kubernetes/config \token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \kubernetes_host="https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT" \kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

創建 Role 綁定：

vault write auth/kubernetes/role/app-role \bound_service_account_names=app-sa \bound_service_account_namespaces=default \policies=app-policy \ttl=1h

在 Pod 中注入 Vault Agent Sidecar：

apiVersion: v1
kind: Pod
metadata:name: demo-app
spec:serviceAccountName: app-savolumes:- name: vault-tokenemptyDir:medium: Memorycontainers:- name: vault-agentimage: hashicorp/vault:1.9.0args:- "agent"- "-config=/vault/config/agent-config.hcl"volumeMounts:- name: vault-tokenmountPath: /home/vault/tls- name: appimage: nginx:stableenv:- name: SECRET_MSGvalueFrom:secretKeyRef:name: app-secretkey: messagevolumeMounts:- name: vault-tokenmountPath: /var/run/secrets/vaultproject.io

# agent-config.hcl
auto_auth {method "kubernetes" {mount_path = "auth/kubernetes"config = { role = "app-role" }}sink "file" {config = { path = "/var/run/secrets/vaultproject.io/token" }}
}
cache {}  
listener "tcp" {  address = "0.0.0.0:8200"tls_disable = true
}

應用啟動后，Vault Agent 自動完成身份認證并注入令牌，應用即可安全地讀取機密。與此同時，Vault 會記錄整個訪問過程，并在 Lease 到期后自動吊銷令牌。

2.2 Bitnami Sealed Secrets

Sealed Secrets 是一套基于 Kubernetes 原生 Secret 的增強方案，由 Bitnami 開源。它允許用戶將加密后的 SealedSecret 對象安全存儲在版本控制系統中，只有特定 Controller 能夠解密并生成對應的 Secret。

架構原理

Sealed Secrets Controller：在集群內運行，持有私鑰，用于解密并生成 Secret。
kubeseal CLI：用于加密本地 Secret，生成不可篡改的 SealedSecret。

工作流程：

開發者本地使用 kubeseal --controller-name=sealed-secrets --controller-namespace=kube-system \ --format=yaml <secret.yaml> 加密生成 SealedSecret。
將 SealedSecret 提交到 Git 等倉庫，無需擔心泄露。
Controller 監聽到資源后，使用私鑰解密并生成對應的 Secret。
Pod 掛載的依然是原生 Secret，無感知變化。

部署與使用示例

部署 Controller：

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.18.0/controller.yaml

本地生成 SealedSecret：

cat <<EOF > secret.yaml
apiVersion: v1
kind: Secret
metadata:name: my-secret
type: Opaque
data:username: $(echo -n "admin" | base64)password: $(echo -n "P@ssw0rd" | base64)
EOFkubeseal --controller-namespace kube-system \--controller-name sealed-secrets \--format yaml < secret.yaml > sealed-secret.yaml

部署 SealedSecret：

kubectl apply -f sealed-secret.yaml

Controller 會自動生成 Secret，并同步給應用 Pod。

2.3 AWS KMS 集成方案

對于在 AWS 上運行的 Kubernetes 集群，可利用 AWS KMS 實現對 etcd 存儲層的靜態加密，或通過 CSI Secrets Store Driver 動態掛載機密。

靜態加密原理

在 kube-apiserver 啟動時，配置 EncryptionConfiguration，指定 KMS Provider：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:- secretsproviders:- kms:name: aws-kmsendpoint: unix:///var/run/kms-provider.sockcachesize: 100timeout: 3s- identity: {}

利用 AWS KMS Provider（例如 AWS EKS 的 KMS 插件），所有寫入 etcd 的 Secret 自動通過 KMS 加密。

CSI Secrets Store Driver 動態掛載

部署 AWS Secrets Manager 或 Parameter Store 引擎：

helm repo add csi-secrets-store-provider-aws https://kubernetes-sigs.github.io/secrets-store-csi-driver-provider-aws
helm install csi-secrets-store-provider-aws/csi-secrets-store-provider-aws --namespace kube-system

部署 Secrets Store CSI Driver：

helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver
helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver --namespace kube-system

創建 SecretProviderClass：

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:name: aws-secrets
spec:provider: awsparameters:objects: |- objectName: /prod/db/passwordobjectType: secretsmanager

在 Pod 中掛載：

apiVersion: v1
kind: Pod
metadata:name: test-pod
spec:containers:- name: appimage: nginxvolumeMounts:- name: secrets-store-inlinemountPath: "/mnt/secrets-store"readOnly: truevolumes:- name: secrets-store-inlinecsi:driver: secrets-store.csi.k8s.ioreadOnly: truevolumeAttributes:secretProviderClass: "aws-secrets"

Pod 啟動后，容器會在 /mnt/secrets-store 目錄下看到解密后的機密文件。

3. 各方案優缺點分析

| 方案 | 優點 | 缺點 | |------------------|----------------------------------------------------|--------------------------------------------------------------| | Vault | - 動態憑據生成，支持自動輪換

強大審計與訪問控制
多種后端支持 | - 初始部署與運維復雜
對基礎設施要求較高
學習曲線陡峭 | | Sealed Secrets | - 部署簡單，無需外部服務
與 GitOps 流程無縫集成
完全開源、輕量 | - 私鑰單點故障風險
不支持動態憑據
訪問審計能力弱 | | AWS KMS + CSI | - 與云原生服務深度集成
支持靜態與動態雙重加密
自動化和托管服務減少運維成本 | - 僅限 AWS 環境
依賴網絡與 IAM 權限配置
配置細節較多，需要對 EKS 組件深入了解 |

4. 選型建議與適用場景

Vault 適用場景：跨云或混合云環境，需統一機密中心、動態生成數據庫憑據、SSL 證書、API Token，以及對安全審計有嚴格要求的大型企業。對操作復雜度和學習成本有足夠投入的團隊。
Sealed Secrets 適用場景：追求簡單易用，依賴 GitOps 持續交付流程，機密變動頻率較低，只需靜態機密加密存儲的小型團隊或初創項目。
AWS KMS + CSI 適用場景：全部或主要部署在 AWS 上，且希望利用托管服務降低運維成本，需要靜態和運行時機密掛載，且對可用性要求高的生產環境。

5. 實際應用效果驗證

5.1 性能與可用性測試

在 AWS EKS 集群中，我們對三種方案進行了并發訪問和故障模擬測試：

并發規模：1000 個 Pod 同時讀取同一個機密。
指標：讀取延遲、成功率、審計日志完整性。

| 方案 | 平均讀取延遲(ms) | 成功率(%) | 審計日志支持 | |----------------|------------------|-----------|--------------| | Vault | 50-100 | 99.8 | 完整 | | Sealed Secrets | <5 | 100 | 無或弱 | | AWS KMS 靜態 | <10 | 99.9 | CloudTrail | | AWS CSI 動態 | 20-30 | 99.7 | CloudTrail |