本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

数据加密和机密管理

静态加密

您可以在 Kubernetes 中使用三种不同的 AWS-native 存储选项：EBS 、E F S 和 FSx for Lustre。所有三者都使用服务托管式密钥或客户主密钥（CMK）进行静态加密。对于 EBS，您可以使用树内存储驱动程序或 EBS CSI 驱动程序。两者都包含用于加密卷和提供 CMK 的参数。对于 EFS，您可以使用 E FS CSI 驱动程序，但是，与 EBS 不同，EFS CSI 驱动程序不支持动态配置。如果要将 EFS 与 EKS 一起使用，则需要在创建 PV 之前为文件系统预置和配置静态加密。有关 EFS 文件加密的更多信息，请参阅加密静态数据。除了提供静态加密外，适用于 Lustre 的 EFS 和 FSx 还包括对传输中的数据进行加密的选项。默认情况下，fsX for Lustre 会执行此操作。对于 EFS，您可以通过在 PV mountOptions 中添加tls参数来添加传输加密，如以下示例所示：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  mountOptions:
    - tls
  csi:
    driver: efs.csi.aws.com
    volumeHandle: <file_system_id>

FSx CSI 驱动程序支持 Lustre 文件系统的动态配置。默认情况下，它使用服务管理的密钥加密数据，尽管可以选择提供您自己的 CMK，如以下示例所示：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fsx-sc
provisioner: fsx.csi.aws.com
parameters:
  subnetId: subnet-056da83524edbe641
  securityGroupIds: sg-086f61ea73388fb6b
  deploymentType: PERSISTENT_1
  kmsKeyId: <kms_arn>

加密静态数据

对静态数据进行加密被认为是一种最佳实践。如果您不确定是否需要加密，请加密您的数据。

定期轮换 CMK

配置 KMS 以自动轮换您的 CMK。这将每年轮换一次您的密钥，同时无限期保存旧密钥，这样您的数据仍然可以解密。有关更多信息，请参阅轮换客户主密钥

使用 EFS 接入点简化对共享数据集的访问

如果您拥有具有不同 POSIX 文件权限的共享数据集，或者想要通过创建不同的挂载点来限制对部分共享文件系统的访问，请考虑使用 EFS 接入点。要了解有关使用接入点的更多信息，请参阅https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html.今天，如果您想使用接入点 (AP)，则需要在 PV 的volumeHandle参数中引用 AP。

密钥管理

Kubernetes 密钥用于存储敏感信息，例如用户证书、密码或 API 密钥。它们作为 base64 编码的字符串保存在 etcd 中。在 EKS 上，etcd 节点的 EBS 卷使用 EBS 加密进行加密。容器可以通过引用 Kubernetes 中的密钥来检索 Kubernetes 机密对象。podSpec这些密钥可以映射到环境变量，也可以作为卷装载。有关创建密钥的更多信息，请参阅 https://kubernetes.io/docs/concepts/configuration/secret/.

使用 AWS KMS 对 Kubernetes 密钥进行信封加密

这允许您使用唯一的数据加密密钥 (DEK) 加密您的机密。然后，使用 AWS KMS 的密钥加密密钥 (KEK) 对 DEK 进行加密，该密钥可以定期自动轮换。使用适用于 Kubernetes 的 KMS 插件，所有 Kubernetes 密钥都以密文而不是纯文本存储在 etcd 中，并且只能由 Kubernetes API 服务器解密。有关其他详细信息，请参阅使用 EKS 加密提供商支持进行深度防御

审计 Kubernetes Secrets 的使用情况

在 EKS 上，打开审核日志记录并创建 CloudWatch 指标筛选器和警报，以便在使用密钥时提醒您（可选）。以下是 Kubernetes 审计日志的指标筛选器示例。{($.verb="get") && ($.objectRef.resource="secret")}您还可以在 L CloudWatch og Insights 中使用以下查询：

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| stats count(*) by objectRef.name as secret
| filter verb="get" and objectRef.resource="secrets"

上述查询将显示在特定时间范围内访问机密的次数。

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| filter verb="get" and objectRef.resource="secrets"
| display objectRef.namespace, objectRef.name, user.username, responseStatus.code

此查询将显示密钥，以及尝试访问密钥的用户的命名空间和用户名以及响应代码。

定期轮换你的秘密

Kubernetes 不会自动轮换密钥。如果您必须轮换密钥，请考虑使用外部密钥存储库，例如 Vault 或 AWS 密钥管理器。

使用单独的命名空间作为隔离不同应用程序的机密信息的一种方式

如果您的密钥无法在命名空间中的应用程序之间共享，请为这些应用程序创建一个单独的命名空间。

使用音量挂载代替环境变量

环境变量的值可能会无意中出现在日志中。以卷形式挂载的密钥被实例化为 tmpfs 卷（支持 RAM 的文件系统），删除 pod 时会自动从节点中移除。

使用外部密钥提供商

除了使用 Kubernetes 密钥之外，还有几种可行的替代方案，包括 AWS Secrets Manager 和 Hashicorp 的 Vault。https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/这些服务提供 Kubernetes Secrets 所不具备的精细访问控制、高度加密和密钥自动轮换等功能。Bitnami的密封机密是另一种使用非对称加密创建 “密封机密” 的方法。公钥用于加密密钥，而用于解密密钥的私钥保存在集群中，这使您可以安全地将密封的密钥存储在 Git 等源代码控制系统中。有关更多信息，请参阅使用密封密钥在 Kubernetes 中管理密钥部署。

随着外部密钥存储库的使用增加，将它们与 Kubernetes 集成的需求也随之增加。Secret Store CSI 驱动程序是一个社区项目，它使用 CSI 驱动程序模型从外部密钥存储库中获取机密。目前，该驱动程序支持 AWS Secrets Manager 、Azure、Vault 和 GCP。AWS 提供商支持 AWS Secrets Manager 和 AWS 参数存储。它还可以配置为在密钥到期时轮换，并且可以将 AWS 密钥管理器密钥同步到 Kubernetes 密钥。当您需要将密钥作为环境变量引用而不是从卷中读取它们时，密钥同步可能很有用。

有关 AWS 机密和配置提供商 (ASCP) 的更多信息，请参阅以下资源：

外部机密是在 Kubernetes 中使用外部密钥存储库的另一种方式。与 CSI 驱动程序一样，外部机密适用于各种不同的后端，包括 AWS 密钥管理器。区别在于，external-secrets 不是从外部密钥存储库中检索机密，而是将这些后端的秘密作为密钥复制到 Kubernetes。这使您可以使用首选的密钥存储库管理密钥，并以 Kubernetes-native 某种方式与密钥进行交互。

工具和资源