EKS使用证书管理器和 Let's Encrypt 为亚马逊上的应用程序设置 end-to-end加密 - AWS Prescriptive Guidance
摘要先决条件和限制架构工具操作说明相关资源

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

EKS使用证书管理器和 Let's Encrypt 为亚马逊上的应用程序设置 end-to-end加密

由 Mahendra Revanasiddappa () 和 Vasanth Jeyaraj () 创作 AWS AWS

摘要

实施 end-to-end加密可能很复杂，您需要管理微服务架构中每项资产的证书。尽管您可以使用网络负载均衡器或 Amazon G API ateway 终止在 Amazon Web Services (AWS) 网络边缘的传输层安全 () 连接，但有些组织需要 end-to-end加密。TLS

此模式使用NGINX入口控制器进行入口。这是因为当您创建 Kubernetes 入口时，入口资源使用网络负载均衡器。网络负载均衡器不允许上传客户端证书。因此，你无法通过 Kubernetes 入口实现TLS互动。

这种模式旨在针对需要在其应用程序中所有微服务之间相互认证的组织。Mut TLS ual 减轻了维护用户名或密码的负担，还可以使用交钥匙安全框架。如果您的组织具有大量连接的设备或必须遵守严格的安全指南，则此模式的方法是兼容的。

这种模式通过对在 Amazon Elastic Kubernetes Service（亚马逊）上运行的应用程序实施 end-to-end加密，有助于提高组织的安全状况。EKS此模式在 Amazon EKS 存储库中的 GitHub End-to-end 加密中提供了一个示例应用程序和代码，以显示微服务如何在 Amazon EKS 上以 end-to-end加密方式运行。该模式的方法使用 cert-manager（Kubernetes 的附加组件），将 Let 's Encrypt 作为证书颁发机构 (CA)。Let's Encrypt 是一款经济实惠的证书管理解决方案，它提供有效期为 90 天的免费证书。在亚马逊上部署新的微服务时，Cert-Manager 会自动按需配置和轮换证书。EKS 

目标受众

建议有使用 Kubernetes、、TLS Amazon Route 53 和域名系统 () 经验的用户使用此模式。DNS

先决条件和限制

先决条件

  • 一个活动的 AWS 账户。

  • 现有的 Amazon EKS 集群。

  • AWS命令行界面 (AWSCLI) 版本 1.7 或更高版本，已在 macOS、Linux 或 Windows 上安装和配置。

  • kubectl命令行实用工具，已安装并配置为访问 Amazon EKS 集群。有关这方面的更多信息，请参阅亚马逊EKS文档中的安装 kubectl。

  • 用于测试应用程序的现有DNS名称。有关更多信息，请参阅 Amazon Route 53 文档中的使用 Amazon Route 53 注册域名。 

  • 最新 Helm 版本，安装在您的本地计算机上。有关这方面的更多信息，请参阅亚马逊EKS文档和 Helm 存储库EKS中的将 Hel GitHub m 与 Amazon 配合使用。 

  • Amazon EKS 存储库上的 GitHub End-to-end 加密，克隆到您的本地计算机。 

  • 替换 Amazon EKS 存储库中克隆 GitHub End-to-end 加密的policy.json和trustpolicy.json文件中的以下值：

    • <account number>— 替换为您要在其中部署解决方案的帐户的帐户 ID。AWS 

    • <zone id> — 替换为域名的 Route 53 区域 ID。 

    • <node_group_role>— 替换为与亚马逊EKS节点关联的 Ident AWS ity and Access Management (IAM) 角色的名称。

    • <namespace>— 替换为部署NGINX入口控制器和示例应用程序的 Kubernetes 命名空间。

    • <application-domain-name>— 替换为 Route 53 中的DNS域名。

限制

  • 此模式不描述如何轮换证书，仅演示如何在 Amazon EKS 上的微服务中使用证书。 

架构

下图显示了此模式的工作流和体系结构组件。

EKS使用证书管理器和 Let's Encrypt 为亚马逊上的应用程序设置加密的工作流程。

图表显示了以下工作流：

  1. 客户端向应用程序发送访问该DNS名称的请求。

  2. Route 53 的记录是 Network L CNAME oad Balancer 的记录。

  3. Network Load Balancer 将请求转NGINX发到配置了侦听器的入口控制器。TLSNGINX入口控制器和 Network Load Balancer 之间的通信遵循HTTPS协议。

  4. NGINXIngress 控制器根据客户端对应用程序服务的请求执行基于路径的路由。

  5. 应用程序服务将请求转发至应用程序容器组（pod）。该应用程序旨在通过调用秘密使用相同的证书。

  6. 容器组（pod）使用证书管理器证书运行示例应用程序。NGINX入口控制器与 pod 之间的通信使用HTTPS。

注意

证书管理器在自己的命名空间中运行。它使用 Kubernetes 集群角色来提供特定名称空间中的秘密证书。你可以将这些命名空间附加到应用程序 pod 和 NGINX Ingress Controller。

工具

AWS 服务

其他工具

操作说明

任务描述所需技能

在 Route 53 中创建一个公有托管区。

登录AWS管理控制台，打开 Amazon Route 53 控制台，选择托管区域，然后选择创建托管区域。创建公共托管区域，并记录区域 ID。有关更多信息，请参阅 Amazon Route 53 文档中的创建公有托管区。

注意

ACMEDNS01 使用DNS提供者发布质疑，要求证书管理器颁发证书。本挑战要求您通过在DNS域名下方的TXT记录中输入特定值来证明自己控制了域名。在 Let's Encryp ACME t 向您的客户提供令牌后，您的客户会创建TXT一条从该令牌和您的账户密钥派生的记录，并将该记录放在_acme-challenge.<YOURDOMAIN>。然后 Let's Encrypt 查询该DNS记录。如找到匹配项，则可以继续颁发证书。

AWS DevOps
任务描述所需技能

为证书管理器创建IAM策略。

需要通过IAM策略向证书管理员提供验证您是否拥有 Route 53 域的权限。policy.json示例IAM策略在 Amazon EKS 存储库中的克隆 GitHub End-to-end 加密1-IAMRole目录中提供。

在中输入以下命令AWSCLI以创建IAM策略。

aws iam create-policy \
  --policy-name PolicyForCertManager \
  --policy-document file://policy.json
AWS DevOps

为证书管理器创建IAM角色。

创建IAM策略后，必须创建一个IAM角色。trustpolicy.json示例IAM角色在1-IAMRole目录中提供。

在中输入以下命令AWSCLI来创建IAM角色。

aws iam create-role \
  --role-name RoleForCertManager \
  --assume-role-policy-document file://trustpolicy.json
AWS DevOps

将 策略附加到该角色。

在中输入以下命令将IAM策略附加AWSCLI到IAM角色。AWS_ACCOUNT_ID用您的AWS账户 ID 替换。

aws iam attach-role-policy \
  --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \
  --role-name RoleForCertManager
AWS DevOps
任务描述所需技能

部署入NGINX口控制器。

使用 Helm 安装最新版nginx-ingress。在部署 nginx-ingress 配置之前，您可以根据自己的要求对其进行修改。此模式使用带注释的、面向内部的网络负载均衡器，该网络负载均衡器可在 5-Nginx-Ingress-Controller 目录中找到。 

通过在5-Nginx-Ingress-Controller目录中运行以下 Helm 命令来安装 NGINX Ingress 控制器。

helm install test-nginx nginx-stable/nginx-ingress  -f  5-Nginx-Ingress-Controller/values_internal_nlb.yaml

AWS DevOps

确认已安装NGINX入口控制器。

输入 helm list命令。输出应显示NGINX入口控制器已安装。

AWS DevOps

创建 Route 53 A 记录。

A 记录指向 NGINX Ingress Controller 创建的 Network Load Balancer。

  1. 获取 Network Load Balancer 的DNS名称。有关说明，请参阅获取负ELB载均衡器的DNS名称。

  2. 在 Amazon Route 53 控制台，选择托管区域。

  3. 选择要在其中创建记录的公共托管区域，然后选择创建记录。

  4. 输入记录的名称。 

  5. 在记录类型中，选择 A-将流量路由到IPv4和一些AWS资源。  

  6. 启用别名。

  7. 在流量路由目标，执行以下操作：

    1. 选择网络负载均衡器的别名。

    2. 选择部署 Network Load Balancer 的AWS区域。

    3. 输入 Network Load Balancer 的DNS名称。

  8. 选择创建记录。

AWS DevOps
任务描述所需技能

部署 NGINX VirtualServer。

该NGINX VirtualServer 资源是一种负载平衡配置，可以替代入口资源。创建NGINX VirtualServer 资源的配置可在6-Nginx-Virtual-Server目录中的nginx_virtualserver.yaml文件中找到。在中输入以下命令kubectl以创建NGINX VirtualServer 资源。

kubectl apply -f  nginx_virtualserver.yaml

重要

确保更新nginx_virtualserver.yaml文件中的应用程序域名、证书密钥和应用程序服务名称。

AWS DevOps

验证NGINX VirtualServer 是否已创建。

在中输入以下命令kubectl以验证NGINX VirtualServer 资源是否已成功创建。

kubectl get virtualserver

注意

验证该Host列是否与您的应用程序的域名相匹配。

AWS DevOps

在TLS启用状态下部署 NGINX Web 服务器。

此模式使用TLS启用的 NGINX Web 服务器作为测试 end-to-end加密的应用程序。部署测试应用程序所需配置文件可在 demo-webserver 目录中找到。 

在 kubectl 中输入以下命令以部署测试应用程序。

kubectl apply -f nginx-tls-ap.yaml

AWS DevOps

验证测试应用程序资源是否已创建。

在 kubectl 中输入以下命令，以验证是否为测试应用程序创建了所需资源：

  • kubectl get deployments

    注意

    验证Ready列和Available列。

  • kubectl get pods | grep -i example-deploy

    注意

    Pod 应处于running状态。

  • kubectl get configmap 

  • kubectl get svc 

AWS DevOps

验证应用程序。

  1. 输入以下命令，将替换为您之前创建的 Route53 DNS 名称。<application-domain-name>

    curl --verbose https://<application-domain-name>

  2. 验证您是否可访问应用程序。

AWS DevOps

相关资源

AWS 资源

其他资源