数据加密和密钥管理

数据加密

云盘加密建议

• 开启云盘加密特性

  对业务数据静态加密是安全的最佳实践，具体操作，请参见加密云盘存储卷。

• 定期轮换CMK

  您可以通过密钥版本化和定期轮转来加强密钥使用的安全性，实现数据保护的安全策略和最佳实践。具体操作，请参见自动轮转密钥。

使用KMS中的指定密钥对指定云盘存储卷进行加密

阿里云ACK集群适用于有高安全性或合规性要求的应用场景，您无需自建和维护密钥管理基础设施，通过加密保护存储在阿里云ECS上的数据就能保护数据的隐私性和自主性。更多信息，请参见加密云盘存储卷。

本文以配置加密云盘数据卷为例，在创建存储资源实例时，您可以使用KMS中的指定密钥对指定云盘存储卷进行加密。

1. 配置StorageClass参数。

   1. 将以下内容复制到sc-kms.yaml文件中。

      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: csi-disk
      provisioner: diskplugin.csi.alibabacloud.com
      parameters:
          fsType: ext4
          type: cloud_ssd
          encrypted: "true"
          kmsKeyId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      reclaimPolicy: Delete

   2. 执行以下命令创建StorageClass。

      kubectl create -f sc-kms.yaml

2. 创建PVC。

   1. 将以下内容复制到sc-pvc.yaml文件中。

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: disk-pvc
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
        storageClassName: csi-disk

   2. 执行以下命令创建PVC。

      kubectl create -f sc-pvc.yaml

密钥管理

Kubernetes作为编排引擎为应用开发者提供了Secrets模型，用于在应用Pod中加载和使用敏感信息，例如数据库密码、应用证书、认证Token等。Secrets相关概念如下。

• Secrets是一个Namespace维度的模型，结合K8s RBAC访问控制可以实现集群内Namespace维度的读写隔离。

• Secrets可以通过文件或环境变量的形式挂载到Pod容器中使用。

• Secrets中的敏感数据以Tmpfs格式存储在节点文件系统中。

• 集群APIServer以Base64明文编码的形式将Secrets存储在集群etcd中。

• Secrets单个实例的大小限制在1 MB内。

K8s Secrets作为K8s应用处理敏感信息的载体和桥梁，但并不能保证敏感信息的安全性，在使用过程中可能会遇到以下问题。

• 一些关键的密钥信息，需要开发者和安全管理人员在应用系统实施前确定密钥管理的安全方案，明确如何存储应用密钥。

• 如何在不破坏密钥可加载和使用的前提下，保护其读写和传输阶段的安全性？

• 云服务商有哪些安全方案可以帮助保护应用密钥？

• 在K8s环境中，您可以采取哪些安全措施帮助管理和使用密钥？

下文从云服务商提供的密钥管理安全方案和面向应用开发者的密钥管理最佳安全实践两个维度帮您解决以上问题。

安全方案

基于云上安全责任共担模型，云服务商有责任保护管控侧配置和敏感信息的安全性，同时提供密钥管理的安全方案，可以帮助您提升应用密钥的安全水位，推荐的安全方案如下。

• 使用云上密钥管理服务

  云服务商都会提供密钥管理服务。例如，阿里云KMS密钥管理服务提供专业的密钥生命周期管理和数据加解密，可以帮助您简化应用系统接入流程。关于阿里云KMS密钥管理服务的更多信息，请参见什么是密钥管理服务。

  在应用系统开发部署的供应链流程中，任何一个环节对敏感密钥的硬编码都有可能导致泄露风险。通过使用云上密钥管理服务，您可以在应用开发、测试、构建等生命周期流程中使用统一方式进行密钥的读写，避免硬编码出现。同时，云上的密钥管理服务支持自动化的密钥轮转能力，进一步降低了敏感信息泄露传播的安全风险，同时也可帮助企业应用满足合规需求。

• 使用Secret Store CSI driver

  应用消费密钥的方式通常是从指定文件系统路径或是从环境变量读取，使用Secret Store CSI driver可以帮您解决如何将云上KMS服务中的密钥信息导入到应用Pod容器内的指定路径的问题。

  K8s社区基于CSI存储标准扩展实现了secrets-store-csi-driver，用于将存储在外部密钥管理服务中的密钥以Volume存储卷的形式挂载到应用Pods中。当Volume完成attach挂载后，密钥信息将以文件系统的形式在容器中使用，无需创建K8s Secret实例。从而避免了etcd中出现明文Secret信息，避免大规模场景下的Secret堆积，同时应用可以保持原先的文件路径方式读取密钥，避免通过KMS服务接口形式获取密钥带来的额外改造代价。

  基于该插件机制，各云服务商可以实现自己的Provider对接不同的后端密钥管理服务，例如，阿里云的secrets-store-csi-driver-provider-alibabacloud，在集群中部署该插件，可以方便地将阿里云KMS凭据管家中保存的密钥凭据以文件或K8s Secrets实例两种方式同步到应用容器中，同时支持后端凭据修改后的同步更新能力，保证业务容器中密钥信息的实时性。为解决最后一把密钥的问题，由于插件需要调用KMS凭据管家服务的权限，您可以通过使用RRSA方案，保护插件对KMS服务请求的凭据，RRSA方案将KMS凭据的请求权限绑定在插件使用的独立ServiceAccount上，避免将权限泄露给应用Pod。

• 开启etcd落盘加密

  etcd是K8s集群默认的后端存储系统，Secrets在etcd中以Base64明文编码的形式存储，存在一定的安全风险。尤其在云服务商提供的托管集群形态下，etcd维护在云服务商侧，基于云上安全零信任原则和很多应用场景下的合规要求，推荐您使用K8s提供的etcd落盘加密，选择使用阿里云KMS服务中管理的密钥在Secret数据落盘流程中以信封加密的形式加密数据，同时在读取Secret信息时自动解密。配合使用自动轮转密钥可进一步提升数据安全性。

• 使用机密计算容器

  对于对数据安全性有严格要求的场景，例如金融支付、隐私认证或涉及知识产权的核心数据计算，除了保证这些核心敏感信息在读写和传输过程中的安全性，还需要保证机密信息在云上节点内存运算和存储过程中的安全可信。在此场景下推荐使用阿里云ACK-TEE机密计算集群，ACK-TEE可以基于底层硬件加密技术在容器应用实现一个可信执行加密环境，保证机密信息在云端代码使用过程中的完整性，实现数据全生命周期的安全可信。同时，应用系统核心密钥也可以存储在可信的隔离环境Enclave中，实现类似KMS HSM的能力，减少密钥传输链路。

最佳安全实践

基于云服务商提供的密钥管理安全方案，应用开发运维人员需要负责自身业务密钥的安全性。以下为业务侧推荐实施的密钥管理最佳安全实践。

• RBAC访问控制

  Secrets作为K8s系统中的基础模型，通过RBAC实现对Secrets实例的访问权限控制是基本且必要的安全要求，在集群的日常运维开发中应该遵循权限最小化原则进行授权，避免在下发凭证中绑定全局Secret读写权限，并及时吊销可能泄露的集群访问凭证。

• Pod安全加固

  容器逃逸是针对K8s集群常见的攻击方式，对于一个已经逃逸到容器主机的攻击，可以轻松获取节点上相关Secrets的明文信息，同时也可以发起进一步的攻击，获取整个集群的访问权限，从而造成集群内敏感信息的泄露。

  K8s提供了多种安全配置，帮助应用开发者加固容器安全，应用开发者应当根据实际业务需要最小化Pod的Capabilities，避免使用Privileged或其他共享主机网络、文件系统等特权配置。通过使用安全策略，可以在应用部署过程中时刻有效拦截不符合安全策略约束的违规特权部署。另外，部署和使用Network Policy，可以限制应用Pod内的东西向网络访问，进一步收敛攻击者入侵后实施下一步横向攻击的安全风险。

• 节点安全加固

  集群基础设施安全是保证上层应用安全的基础。首先应尽量选择私有网络，同时使用安全组ACL规则控制出入网流量。对于集群节点自身，推荐使用经过基于等保或阿里云OS加固等安全合规规范，加固后的基础镜像作为集群节点OS，可以帮助在基础设施层身份鉴别、访问控制、安全审计、入侵防范等多个维度提升基础安全性，降低攻击者从主机侧攻击窃取敏感信息的风险。关于等保加固的更多信息，请参见ACK等保加固使用说明。

  K8s集群自身组件的配置对上层应用系统的安全性起到至关重要的作用，可通过基线巡检功能及时发现集群中的不当安全配置，封堵漏洞。

• 供应链安全加固

  关于密钥的读取使用会贯穿应用制品生命周期的各阶段，需要在组织流程上加强对密钥安全的风险意识，规范密钥使用，严禁在应用模板、代码仓库、配置文件中硬编码敏感信息。在制品供应链生命周期中统一使用密钥管理服务进行管理，同时，企业内部安全管理运维团队可针对供应链各环节增加自动化安全扫描卡点，从源头上防止敏感信息的传播和泄露。

• 审计和监控

  在企业应用系统中，涉及密钥生命周期管理和读写使用的所有操作均应接入审计日志，保证针对敏感信息的操作可溯源，同时接入运行时刻监控机制，例如，针对应用中存储敏感信息的路径设置可疑读写监控告警，对云账号AK设置泄露告警等安全设置。当发生密钥泄露时，日志和告警可以帮助企业运维快速定位问题，判断影响面，同时及时进行相关止血措施。

• 使用临时凭证，定期或自动轮转密钥

  请勿在应用系统中使用例如账号AK的固定密钥，推荐使用临时凭据。当密钥发生泄露时，获得临时凭据的攻击者只有一个短暂的窗口期进行下一步的探查和攻击，这无疑增加了攻击难度，也给系统运维人员提供了封堵和修复系统漏洞的机会，试想如果凭据是永久的，可能应用系统的彻底修复需要成倍的难度。同样的道理，当您使用云上KMS密钥管理服务中的密钥时，推荐定期轮转或开启密钥自动轮转特性，提升应用安全防御能力。

• 使用信封加密并保护好最后一把密钥

  信封加密和直接使用云上管理服务提供的密钥进行直接加解密明文数据的方式不同，信封加密使用一个独立的数据加密密钥，并将其加密后封入信封中传递使用，业务侧的敏感信息可以在本地实现离线的加解密，避免上传云端传输过程中的泄露，同时解决了云服务商不信任问题。同时，对于数据量较大的加解密场景，离线的计算过程也避免了云上传输和计算的开销，有效提升计算性能并降低成本。关于信封机密的更多信息，请参见使用KMS信封加密在本地加密和解密数据。

  最后一把密钥的安全问题是KMS加解密场景中的普遍问题，在信封加密过程中，同样需要在云上放置一把KEK密钥用于加解密数据密钥，此时通用的方案是使用类似RAM的访问控制服务，在最小化授权的前提下保证密钥安全性。在应用侧，需要限制读取云上密钥的RAM凭证的可见范围，同时使用可自动轮转的临时凭证，推荐在容器应用中使用类似RRSA应用维度的隔离机制保护RAM凭证的安全性。关于RRSA的更多信息，请参见RRSA。