将您的本地 Kubernetes 集群连接到 AWS API，使用 IAM Roles Anywhe

在本地 Kubernetes 集群使用 IAM Roles Anywhere 连接 AWS API

关键要点

在本篇文章中，我们探讨了如何通过 AWS IAM Roles Anywhere，安全地将本地 Kubernetes 工作负载与 AWS 服务连接。该方法无需长期访问密钥或公开 Kubernetes API 服务器，确保了更好的安全性和管理简化。具体内容包括短期 X509 证书的使用、自动化证书管理、以及无须修改现有工作负载 Docker 文件的无缝集成方法。

许多客户希望无缝集成其本地 Kubernetes 工作负载与 AWS 服务，实现混合工作负载或迁移至 AWS。过去，创建长期访问密钥是常见做法，但这带来了安全风险，因此不再推荐。虽然 Kubernetes 密钥库和第三方选项存在，但它们未能有效解决根本问题。

与 AWS API 连接本地 Kubernetes 工作负载的一个选择是使用 服务账户签发者发现 功能。此功能允许 Kubernetes API 服务器充当 OpenID Connect (OIDC) 身份提供者，并与 AWS 身份与访问管理 (IAM) 进行联合。然而，此方法要求 Kubernetes API 服务器具有公共互联网访问，这可能并不适合某些客户。

为了消除使用长期访问密钥或将 Kubernetes API 服务器公开到公共互联网的需求，AWS 推出了 AWS IAM Roles Anywhere。此功能可实现在本地 Kubernetes 工作负载与 AWS 服务之间的安全、无缝集成，推动稳健的安全实践，并降低与长期凭证或公共暴露相关的潜在风险。

IAM Roles Anywhere 使得 AWS 外部的工作负载能够通过交换 X509 绑定身份获取临时 AWS 凭证。通过 IAM Roles Anywhere，您可以使用与 AWS 工作负载相同的 IAM 角色和策略来访问 AWS 资源，从而促进一致性。

IAM Roles Anywhere 可与标准公钥基础设施解决方案一起使用。在本博文中，我们使用了 AWS 私有证书认证机构，这相较于使用自签名证书认证机构 (CA) 具有多个优势。首先，它减少了运营和管理开销，因为 AWS 为您管理 CA。其次，加密密钥材料可以存储在硬件安全模块中，或至少进行加密存储，从而帮助您保护私人 CA 免受密钥泄露。此外，证书可以是短期有效的，这与通常比传统服务器生命周期更短的 Kubernetes 环境的动态特性相符。

我们还展示了如何在不修改现有工作负载 Docker 文件的情况下集成 IAM Roles Anywhere，并如何使用 certmanager 和 AWS 私有证书 CA 后端以短期证书模式自动化 X509 证书生命周期。通过这些功能，您可以无缝集成本地 Kubernetes 工作负载与 AWS 服务，促进稳健的安全实践，降低与长期凭证相关的风险，确保流畅且一致的访问管理体验。

本篇文章适用于在 AWS 之外运行 Kubernets 集群的客户，且不适用于 Amazon EKS Anywhere。如果您使用 Amazon 弹性 Kubernetes 服务 (Amazon EKS)，可以改用 IAM 角色服务账户 或 Amazon EKS Pod 身份。

背景

“我为什么应该偏爱 X509 证书而不是 IAM 访问密钥？”访问密钥是长期凭证，必须定期 rotating 以减少未授权访问的风险。它们需要安全部署到托管应用程序的服务器上，并要求对临时副本的安全传输和删除程序。随着应用程序和访问密钥数量的增加，跟踪和管理变得令人挑战。

相对而言，X509 证书使用公钥基础设施 (PKI)。私钥直接在应用程序服务器上生成，并不会离开它。只有不包含秘密的证书签名请求被发送给 CA 进行签名并返回证书。这减少了传输秘密密钥的需要。

然而，您可以争辩说，X509 证书也是长期凭证。这个担忧是有效的，但并不一定正确。正如 Let’s Encrypt 等项目所示，通过实现证书更新的自动化，可以将证书有效期从数年缩小到数月。在此机制建立后，证书有效期可以进一步限制为数天甚至数小时。

在本篇文章中，我们介绍了相互认证的传输层安全性 (mTLS)，它使用证书进行高保障的双向身份验证。证书用于建立客户端和服务器之间的信任，确保双发均被认证并授权以安全进行通信。通过实施 mTLS，您可以在通信渠道中实现更高的安全性和信任度，降低未授权访问或中间人攻击的潜在风险。在此，我们实施与 Pods 生命周期相关联的短期证书。当 Pod 启动时，会自动生成证书，并在短时间后过期，除非它正被 Pod 使用，在这种情况下由 certmanager 自动续期。这种方法验证证书仅在 Pod 存在期间有效，从而降低长期凭证相关的潜在风险。此外，IAM Roles Anywhere 支持证书撤销列表 (CRL) 检查，允许您在需要时执行证书的显式撤销。此功能提供额外的安全层，使您能够在凭证被损坏或其他安全问题发生时迅速撤销访问。

在整篇文章中，我们假设您对 IAM Roles Anywhere 具有基本了解。更多信息请参见 这篇博客文章。此外，我们假设您熟悉 Kubernetes、kubectl、Helm，和 certmanager 的使用。

解决方案概述

本解决方案假定您有一个在 AWS 外部运行的现有 Kubernetes 集群。

图 1 显示了我们解决方案的高层架构。本地 Kubernetes 集群通过使用 IAM Roles Anywhere 和在短期证书模式中由 AWS 私有 CA 签发的 X509 证书来访问 AWS API。

图 1 本地 Kubernetes 访问 AWS API 的高层架构

以下是解决方案的工作原理，如图 1 所示：

让我们更详细地探讨架构的不同部分。

AWS Private CA 短期凭证

AWS Private CA 提供短期证书，有效期有限为 7 天或更短。您可以参见 这个 AWS 博客 学习如何使用 AWS Private CA 短期证书。此 新模式 可以用于为 Kubernetes Pods 签发证书，并享受更低的运营成本。通过将证书生命周期与 Pod 生命周期同步，您可以最小化本解决方案的运营开销。为了满足审计和透明度的要求，您可以使用 审计报告功能 列出以机器可读格式签发的证书。

IAM Roles Anywhere

图 2 显示了与 IAM Roles Anywhere 进行身份验证相关组件的详细 概述。

图 2 IAM Roles Anywhere 的组件

IAM Roles Anywhere 使您能够为运行在 AWS 之外的工作负载获取临时安全凭证。您的工作负载必须使用受信任的 PKI CA 签发的证书进行身份验证。通过创建一个信任锚，您在 IAM Roles Anywhere 和您的 CA 之间建立信任。

certmanager

图 3 显示了此篇文章使用的 certmanager 设置的详细概述，包括 AWS Private CA 的 awsprivatecaissuer 插件。

图 3 certmanager 设置的详细概述

certmanager 是用于 Kubernetes 中管理 X509 证书的工具。正如图 3 所示，certmanager 将确保证书有效且最新，并在过期前尝试续期。通过使用插件，您可以配置不同的后端来签发 X509 证书。在本篇文章中，我们探索了如何通过使用 awsprivatecaissuer 插件将 certmanager 与 AWS Private CA 集成。awsprivatecaissuer 插件定义了两个自定义资源，AWSPCAIssuer 和 AWSPCAClusterIssuer，用于配置与 AWS Private CA 的连接。它们类似于 certmanager 附带的 Issuer 和 ClusterIssuer 资源，但特定于 awsprivatecaissuer。

在 AWSPCAIssuer 或 AWSPCAClusterIssuer 可用后，awsprivatecaissuer 使用从 IAM Roles Anywhere 获取的临时安全凭证对 AWS API 进行身份验证。certmanager 监视引用 AWSPCAIssuer 的证书资源，而后者又引用 AWS Private CA。awsprivatcaissuer 从 AWS Private CA 请求证书。自动生成的私钥和签名证书被存储在 Kubernetes 密钥中。

使用证书和密钥

certmanager 支持多种与 Kubernetes 工作负载集成的方式。您可以使用证书资源，该资源表示证书签名请求 (CSR) 的人类可读定义，并包含证书的生命周期和续期时间信息。当使用证书时，自动生成的私钥和签名证书被存储在 Kubernetes 密钥中。

使用此选项，可以手动签发 X509 证书并保存为密钥。配置 PKI 作为签发者后，创建证书资源以自动化证书的续期。通过证书资源，证书的生命周期与使用它们的 Pods 的生命周期解耦。这使您能够在受信任的 PKI 部署之前启动 X509 证书。

使用 CSI 驱动程序

与 certmanager 集成的另一种方法是使用 CSI 驱动程序。在这种情况下，证书生命周期与 Pod 的生命周期相关联。X509 证书和私钥被挂载到工作负载可读取的预定义文件夹中。在 Pod 创建时，certmanager 自动生成私钥，并根据给定属性请求与受信任的 PKI 的证书。当 Pod 被删除时，私钥和证书也将被删除，并因未被 certmanager 续期而变得无效。

在本篇文章中，我们使用 CSI 驱动程序方法来为 IAM Roles Anywhere 的工作负载创建短期证书。

工作负载配置

图 4 显示了如何使用侧车容器配置 Pods 以使用 IAM Roles Anywhere，而无需更改底层的 Docker 镜像，侧车容器提供 IMDSv2 端点，以模拟 Amazon 弹性计算云 (Amazon EC2) 实例元数据端点的行为。

图 4 使用侧车的 Pod 配置

如图 4 所示，使用证书资源时，自动生成的私钥和签名证书被存储在 Kubernetes 密钥中并挂载到 Pod 中。当使用 CSI 驱动程序时，私钥在本地针对 Pod生成，基于给定属性请求来自 certmanager 的证书，由 AWSPCAIssuer 签发，并直接挂载到 Pod 中，无需创建中间密钥。

IAM Roles Anywhere 使用 CreateSession API 通过使用私钥及其关联的 X509 证书进行身份验证请求，并使用 SigV4a 签名。此交换提供了 IAM 角色会话凭证，仿佛您已经假设了 IAM 角色。提供了 awssigninghelper 二进制文件 以从命令行调用 CreateSession API。在本篇文章中，使用一个侧车容器为工作负载容器提供 IMDSv2 端点。此容器使用 awssigninghelper 二进制文件，并使用其 serve 命令。

这样，使用 AWS SDK 的应用程序可以使用 AWSEC2METADATASERVICEENDPOINT 环境变量将实例元数据端点设置为 localhost 接口上的正确端口。X509 证书和私钥以文件形式提供给侧车容器。

解决方案部署

在本节中，我们将展示在您的 AWS 账户中部署解决方案所需的步骤。

前提条件

要在本篇文章中部署解决方案，请确保您具备以下条件：

注意 作为使用 AWS CLI 的替代方案，您可以使用 AWS 控制器 for Kubernetes (ACK) 服务控制器，在您的 Kubernetes 集群中直接创建和管理 CertificateAuthority、Certificate 和 CertificateAuthorityActivation 资源。在使用 ACK 控制器建立 CA 层次结构后，您可以继续进行后续步骤，包括 IAM Roles Anywhere 集成、awsprivatecaissuer 和 certmanager，如本篇文章所述。

步骤 1 AWS Private CA

在 AWS Private CA 中设置根 CA，负责为您的 Pods 签发短期证书。在本示例中，您仅使用一个 CA；对于生产环境，您应查看有关 CA 层次结构设计 的注意事项。首先使用 AWS CLI 创建一个配置。

jsoncat ltltEOF gt caconfigjson{ KeyAlgorithmRSA2048 SigningAlgorithmSHA256WITHRSA Subject{ CountryDE OrganizationExample Corp OrganizationalUnitSREs StateHE LocalityFRANKFURT CommonNameBlogpost CA }}EOF

创建 AWS Private CA，选择短期证书模式。

bashaws acmpca createcertificateauthority certificateauthorityconfiguration file//caconfigjson certificateauthoritytype ROOT usagemode SHORTLIVEDCERTIFICATE

此命令返回一个 CertificateAuthorityArn，您将其用于后续命令，因此

四人因美国政府IT贿赂丑闻认罪

2026-01-27 13:23:10