在受监管机构上理解 Amazon EKS 的秘密管理 安全博客

• 2026-01-27 13:39:57

亚马逊 EKS 上的秘密管理解析：为受监管机构提供解决方案

关键要点

AWS 的受监管行业客户，例如金融服务或医疗保健行业，需满足相应的合规要求。本文探讨如何通过 Amazon Elastic Kubernetes 服务 (EKS) 进行秘密管理，以满足数据保护与操作安全的需求，特别是针对金融服务行业 (FSI) 客户的决策要点。此外，还讨论了 AWS 共享责任模型以及三种主要的秘密管理解决方案。

在受监管行业运营的 AWS 客户，尤其是在金融服务行业FSI或医疗保健行业的客户，需满足一系列合规和监管义务，例如 支付卡行业数据安全标准 (PCI DSS) 或 健康保险流动性与责任法案 (HIPAA)。

AWS 提供工具和指导，以及 第三方审计报告，以帮助客户满足合规性要求。受监管行业的客户在采用云服务时，通常需要逐项服务的审批流程，以确保每项采用的服务符合其监管义务和风险承受能力。相关指导可参见 金融机构如何批准用于高度保密数据的 AWS 服务。在本文中，我们将讨论受监管客户，特别是 FSI 客户如何在 Amazon Elastic Kubernetes 服务 (EKS) 上进行秘密管理，以满足数据保护和操作安全要求。Amazon EKS 提供在 AWS 云或本地启动、运行和扩展 Kubernetes 应用程序的灵活性。

应用程序通常需要敏感信息，如密码、API 密钥和令牌，以连接到外部服务或系统。Kubernetes 提供了秘密对象来管理这些敏感信息。然而，随着工具和方法的发展，Kubernetes Secrets 也面临着合规要求的挑战。其中一个主要原因是原生 Kubernetes Secrets 的值并未加密，而是以 base64 字符串进行编码，意味着如果攻击者获取 API 访问权限或能够在包含秘密的命名空间中创建 pod，便可以解码这些值。可以使用 GoDaddy Kubernetes External Secrets、 AWS Secrets and Configuration Provider (ASCP) for the Kubernetes Secrets Store CSI Driver、 Hashicorp Vault 和 Bitnami Sealed Secrets 等工具来提高秘密的安全性、管理和可审计性。

在本文中，我们将讨论在为 FSI 客户选择 External Secrets Operator (ESO)、 Sealed Secrets 和 ASCP 作为 Kubernetes Secrets Store Container Storage Interface (CSI) Driver 时的一些关键决策，这些决策同样适用于其他受监管行业的客户。

AWS 共享责任模型

安全性和合规性是 AWS 和客户之间的共同责任。AWS 共享责任模型 将此描述为云的安全和云中的安全：

AWS 的责任 云的安全：AWS 负责保护运行 AWS 云服务的基础设施。对于 Amazon EKS，AWS 负责 Kubernetes 控制平面，包括控制平面节点和 etcd 数据库。Amazon EKS 已通过多个合规程序认证，适用于受监管和敏感应用程序。安全控制措施的有效性定期接受第三方审计，以符合 AWS 合规程序。客户的责任 云中的安全：客户负责在 AWS 上配置和部署的系统和服务的安全性和合规性。这包括在其 Amazon EKS 集群中安全部署、配置和管理 ESO 的责任。客户的责任根据所选的工作节点和集群配置而有所不同，如图 1 所示。以 Amazon Elastic Compute Cloud (Amazon EC2) 主机进行 Amazon EKS 部署的情况下，客户的责任包括： 数据平面的安全配置，包括允许流量从 Amazon EKS 控制平面进入客户虚拟私有云 (VPC) 的安全组配置。节点及其容器的配置。节点操作系统，包括更新和安全补丁。其他相关应用软件：设置和管理防火墙规则等网络控制。管理平台级身份和访问管理，可以使用或补充 AWS 身份和访问管理 (IAM)。数据的敏感性，如个人可识别信息 (PII)、密钥、密码和令牌。客户有责任执行访问控制以保护其数据和秘密。客户负责监控和记录与秘密管理相关的活动，包括审计访问、检测异常和响应安全事件。公司的要求、适用法律和法规。在使用 AWS Fargate 时，客户的运营开销降低到以下几个方面：客户无需负责更新或修补主机系统。Fargate 会管理容器的放置和缩放。

作为共享责任模型作用的一个示例，考虑一个典型的 FSI 工作负载，该工作负载接受或处理支付卡交易，需遵守 PCI DSS 的要求。PCI DSS v40 的第 3 条要求专注于保护静态和传输中的持卡人数据的指南：

控制 ID控制描述36保护存储账户数据的加密密钥。3612将用于加密和解密持卡人数据的秘密和私钥存储在以下一种或多种形式中： 使用至少与数据加密密钥强度相同的密钥加密密钥加密，并且与数据加密密钥分开存储。 存储在安全加密设备 (SCD) 内，如硬件安全模块 (HSM) 或 PTS 认证的交互设备。 具有至少两个完整密钥组件或密钥共享，符合行业认可的方法。注意：公钥不要求以这些形式存储。3613明文加密密钥组件的访问限制在必要的最少数目内。

FSI 客户也普遍采用 NIST 框架和控制措施。NIST 网络安全框架 (NIST CSF) 和 NIST SP 80053信息系统和组织的安全与隐私控制包括适用于秘密的以下控制：

监管或框架控制 ID控制描述NIST CSFPRAC1为有权的设备、用户和过程发放、管理、验证、撤销和审计身份和凭据。NIST CSFPRDS1保护静态的数据。NIST 80053r5AC2(1) AC3(15)秘密应该启用自动轮换。删除未使用的秘密。

基于前面的目标，秘密管理可以分为两个大类：

快鸭免费加速官网身份和访问管理确保权限分离和最小特权访问。使用专用加密设备的强加密在秘密数据和密钥之间引入安全边界，同时保持对加密密钥的适当管理。

选择您的秘密管理提供商

为了帮助选择一个秘密管理提供商并有效应用补偿控制，接下来我们将根据 PCI DSS 和 NIST 控制目标以及操作开销、高可用性、弹性和开发者或操作员体验等其他考虑因素，评估三种不同的选项。

架构和工作流

以下架构和组件描述突显了每种解决方案组件的不同架构方法和职责，这些组件包括控制器、操作员、命令行界面 (CLI) 工具、自定义资源，以及 CSI 驱动在 Kubernetes 环境中协作以促进安全的秘密管理。

External Secrets Operator (ESO) 通过自定义资源定义 (CRD) 扩展了 Kubernetes API 以实现秘密检索。ESO 使您可以与外部秘密管理系统如 AWS Secrets Manager、HashiCorp Vault、Google Secrets Manager、Azure Key Vault、IBM Cloud Secrets Manager 及其他系统集成。ESO 监视外部秘密存储的更改并保持 Kubernetes 秘密的同步。这些服务提供了原生 Kubernetes Secrets 中未提供的功能，如细粒度的访问控制、强加密和秘密的自动轮换。通过使用这些专门设计的工具，而不在 Kubernetes 集群内，您可以更好地管理风险，并从多个 Amazon EKS 集群中实现秘密的集中管理。有关更多信息，请参阅使用 ESO 将 Secrets Manager 的秘密同步到 Amazon EKS Fargate 集群的 详细操作指南。

ESO 由一个集群侧控制器组成，该控制器会自动对 Kubernetes 集群内的状态进行协调，并在外部 API 的秘密发生更改时更新相关秘密。

Sealed Secrets 是 Bitnami 的一个开源项目，由 Kubernetes 控制器和客户侧 CLI 工具组成，旨在安全地将秘密存储在 Git 中。Sealed Secrets 将您的 Kubernetes 秘密加密为 SealedSecret，您也可以使用 kubectl 将其部署到 Kubernetes 集群。有关更多信息，请参阅使用 Sealed Secrets 开源项目中的工具在 Amazon EKS 集群中管理秘密的 详细操作指南。

Sealed Secrets 由三个主要组件组成：首先，是部署到 Kubernetes 集群中的控制器，负责解密您的秘密；其次是名为 Kubeseal 的 CLI 工具，用于加密秘密；第三是 CRD。您创建的是 SealedSecrets 而不是常规秘密，SealedSecrets 是在 Kubernetes 中定义的 CRD，这样控制器就知道何时在您的 Kubernetes 集群内执行解密过程。

在启动时，控制器查找集群范围内的私有和公有密钥对，如果不存在则生成新的 4096 位 RSA 公私钥对。私钥保存在与控制器同一命名空间的秘密对象中。公钥部分对任何希望在该集群中使用 Sealed Secrets 的人公开。

AWS Secrets Manager 和配置提供程序 (ASCP) 是 AWS 的一个开源工具，允许 Secrets Manager 和 Parameter Store 中的秘密作为文件挂载到 Amazon EKS pods 中。它使用一个被称为 SecretProviderClass 的 CRD 来指定要挂载哪些秘密或参数。在 pod 启动或重启时，CSI 驱动程序从 AWS 检索秘密或参数并将其写入挂载在 pod 中的 tmpfs 卷。当 pod 被删除时，该卷会自动清理，从而确保秘密未被持久化。有关更多信息，请参阅关于如何设置和配置 ASCP 以与 Amazon EKS 一起工作的 详细操作指南。

ASCP 由一个集群侧控制器组成，作为提供程序，允许来自 Secrets Manager 的秘密和来自 Parameter Store 的参数以文件的形式挂载到 Kubernetes pods 中。Secrets Store CSI 驱动程序是一个 DaemonSet，包含三个容器： nodedriverregistrar，它将 CSI 驱动程序注册到 Kubelet； secretsstore，它实现用于挂载和卸载卷的 CSI 节点服务 gRPC 服务；以及 livenessprobe，它监控 CSI 驱动程序的健康状况并报告给 Kubernetes，以便自动检测问题并重启 pod。

接下来的部分，我们将讨论 FSI 客户为满足其监管和合规需求而选择使用 ESO、Sealed Secrets 或 ASCP 时涉及的一些关键决策。

比较 ESO、Sealed Secrets 和 ASCP 目标

这三种解决方案解决了安全秘密管理的不同方面，旨在帮助 FSI 客户满足监管合规要求，同时保护 Kubernetes 环境中的敏感数据。

ESO 从外部 API 同步秘密到 Kubernetes，目标定位于集群操作员和应用开发者。集群操作员负责设置 ESO 并管理访问策略。应用程序开发员则负责定义外部秘密和应用程序配置。

Sealed Secrets 在将 Kubernetes 秘密存储在版本控制系统如公共 Git 存储库之前进行加密。这是因为，如果您决定将 Kubernetes 清单检查到 Git 存储库中，则将向任何可以访问 Git 存储库的人授予对敏感秘密的访问权限。这正是 Sealed Secrets 创建的原因，只有在目标集群中运行的控制器才能解密密封的秘密。

使用 ASCP，您可以安全地在 Secrets Manager 中存储和管理秘密，并通过在 Kubernetes 上运行的应用程序检索它们，而无须编写自定义代码。Secrets Manager 提供的轮换、审计和访问控制等功能，可以帮助 FSI 客户满足监管合规要求并维护强大的安全姿态。

安装

接下来的部署和配置细节突显了每种解决方案集成 Kubernetes 和外部秘密存储的不同方法和资源，以满足容器化环境中安全秘密管理的特定需求。

ESO 提供了 Helm charts，以便于操作员部署。External Secrets 提供诸如 SecretStore 和 ExternalSecret 的自定义资源，以配置所需的同步外部秘密到集群的操作功能。例如，集群操作员可以使用 SecretStore 连接到 AWS Secrets Manager，以拉取秘密所需的适当凭证。

要安装 Sealed Secrets，您可以将 Sealed Secrets 控制器部署到 Kubernetes 集群。您可以单独部署清单，也可以使用 Helm chart 来为您部署 Sealed Secrets 控制器。在控制器安装后，您可以使用客户侧工具 Kubeseal 通过使用非对称加密来加密秘密。如果您尚未安装 Kubeseal CLI，请参见 安装说明。

ASCP 提供 Helm charts 以协助操作员部署。ASCP 操作员提供诸如 SecretProviderClass 的自定义资源，以提供特定于提供程序的参数给 CSI 驱动程序。在 pod 启动和重启期间，CSI 驱动程序将通过 gRPC 与提供程序通信以检索在