GKE(GCP)与EKS(AWS)客户密钥加密PV的内部实现机制问询

1. 数据加密密钥（DEK）的生成与存储位置 #

KMS系统仅负责存储和使用密钥加密密钥（KEK），不会存储DEK，两款托管K8s服务的DEK逻辑完全一致：

• 生成位置：DEK由云存储服务（GCP Persistent Disk / AWS Elastic Block Store）在服务侧生成，不会流入K8s集群的任何组件（包括etcd、kubelet、CSI驱动、KMS插件等）
• 存储规则：明文DEK仅在云存储服务的内存中瞬时存在，用于磁盘数据的实时加解密，不会落地持久化；密文DEK会和对应云磁盘资源绑定存储，不会同步到K8s集群侧存储。

2. 加密逻辑实现位置与开源情况 #

• 加密逻辑不在KMS插件中实现：该加密能力属于云存储服务的原生功能，集群侧的CSI驱动仅负责将StorageClass中配置的KMS KEK ID传递给云存储服务，本身不参与任何数据加解密运算；KMS服务仅负责用指定KEK完成DEK的加解密封装，也不碰用户的实际存储数据。
  你可以通过以下StorageClass配置示例看到，仅需要传递KMS ID参数即可开启加密：
  GKE PD CSI存储类示例

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: pd-encrypted-csi
  provisioner: pd.csi.storage.gke.io
  parameters:
    type: pd-standard
    disk-encryption-kms-key: 你的Cloud KMS密钥完整路径
  

  EKS EBS CSI存储类示例

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: ebs-encrypted-csi
  provisioner: ebs.csi.aws.com
  parameters:
    type: gp3
    encrypted: "true"
    kmsKeyId: 你的AWS KMS密钥ARN
  

• 开源情况：
  • GKE PD CSI驱动、EKS EBS CSI驱动均属于kubernetes-sigs社区的开源项目，KMS ID参数传递的相关逻辑都可以在公开源码中查到
  • 云侧存储服务（PD/EBS）的DEK生成、数据加解密逻辑，以及KMS服务的核心加密实现属于云厂商的闭源业务逻辑，未对外开放源码。

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