多云自管K8s集群下基于自有KMS加密动态置备PVC的实现方案咨询

1. GCP官方PD CSI的PVC层面密钥支持限制 #

首先明确结论：
你当前使用的官方GCP持久盘CSI驱动（pd.csi.storage.gke.io）原生设计上完全不支持从PVC层面透传自定义加密密钥，也不兼容对接非GCP KMS的加密流程。
具体原因：

• 驱动代码的加密逻辑是硬编码的：磁盘加密的KMS密钥值只从StorageClass的disk-encryption-kms-key参数读取，没有预留从PVC注解、自定义扩展参数中动态取值的逻辑，哪怕你在PVC里添加自定义注解传密钥，驱动也不会识别读取
• 驱动的KMS客户端是硬编码对接GCP KMS专属API的，不存在配置端点指向第三方自建KMS的可能，强行替换参数会直接触发驱动的参数校验失败
  所以你想靠修改现有StorageClass配置、在PVC里传值的方式用这个驱动实现需求，是没有可行路径的。

2. 多云场景下符合约束的成熟落地方案 #

方案完全匹配你的约束：自有集群仅使用云厂商计算/网络资源、不依赖云托管K8s服务、不使用云厂商原生KMS、支持PVC层面动态匹配客户密钥、跨GCP/AWS/Azure行为统一。

整体架构思路 #

核心是把加密逻辑从云厂商原生CSI驱动中解耦，在集群侧构建独立的存储编排和加密层，所有和密钥相关的操作全部走你自建的KMS，云厂商的块存储资源只作为无加密的底层块设备使用。

模块组成 #

• CSI前置代理层：部署在集群内，作为统一的块存储置备入口，完全兼容CSI标准接口。它会拦截所有PVC的创建请求：
  • 从PVC的自定义注解中读取用户指定的客户密钥标识（比如cust-encryption.example.com/cmk-id）
  • 把块存储的实际置备请求透传给对应云厂商的原生CSI驱动（GCP PD、AWS EBS、Azure Disk），只申请无原生加密的空块设备
  • 将置备好的空块设备传递给节点侧的加密模块完成整盘加密后，再返回给集群生成PV
• 自建KMS承载层：部署在你自有的跨云计算节点上，采用高可用架构，完全独立于云厂商的KMS服务。所有客户的CMK、数据加密密钥全部保存在KMS的安全存储区，支持自定义密钥轮换、访问控制、操作审计，所有API接口不依赖云厂商生态。
• 节点侧加密模块：利用Linux原生的dm-crypt能力，在块设备挂载到Pod之前完成整盘的透明加密，加密过程使用从自建KMS获取的密钥材料，完全不依赖云厂商的加密能力。

配置示例 #

调整原来的StorageClass，不再硬编码密钥到类参数中：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: custcmk-unified-sc
provisioner: internal-csi-proxy.example.com
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  # 透传给底层云块存储的参数，根据后端云的类型自动适配
  disk-type: pd-standard
  encryption-provider: self-hosted-kms

用户创建PVC时，只需要通过注解传入当前PVC需要绑定的客户密钥标识，即可实现每次置备流程匹配不同的客户密钥：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cust-tenant-a-pvc
  annotations:
    cust-encryption.example.com/cmk-id: tenant-a-prod-cmk
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: custcmk-unified-sc

方案优势 #

• 完全满足合规要求：所有密钥的存储、使用、轮换流程全部由你自主管控，全程不调用云厂商的KMS接口，不依赖云托管的K8s控制面
• 跨云体验一致：因为加密逻辑和PVC参数透传逻辑全部在集群侧实现，不管后端是GCP、AWS还是Azure的块存储，上层的使用流程完全没有差异
• 维护成本可控：不需要修改云厂商原生CSI驱动的核心代码，后续升级云CSI版本时只需要更新代理层的透传逻辑即可，不存在硬改代码带来的升级障碍

内容的提问来源于stack exchange，提问作者C. Derx