使用 cert-manager 和 Let's Encrypt 為 Amazon EKS 上的應用程式設定end-to-end加密

PDF

由 Mahendra Revanasiddappa (AWS) 和 Vasanth Jeyaraj (AWS) 建立

Summary

實作end-to-end加密可能很複雜，您需要管理微服務架構中每個資產的憑證。雖然您可以使用 Network Load Balancer 或 Amazon API Gateway 在 Amazon Web Services (AWS) 網路的邊緣終止 Transport Layer Security (TLS) 連線，但某些組織需要end-to-end加密。

此模式使用 NGINX 傳入控制器進行傳入。這是因為當您建立 Kubernetes 輸入時，輸入資源會使用 Network Load Balancer。Network Load Balancer 不允許上傳用戶端憑證。因此，您無法透過 Kubernetes 輸入達成相互 TLS。

此模式適用於在其應用程式中的所有微服務之間需要相互身分驗證的組織。相互 TLS 可減少維護使用者名稱或密碼的負擔，也可以使用統包安全架構。如果您的組織有大量連線裝置，或必須符合嚴格的安全準則，則此模式的方法是相容的。

此模式透過對在 Amazon Elastic Kubernetes Service (Amazon EKS) 上執行的應用程式實作end-to-end加密，協助提高組織的安全狀態。此模式在 Amazon EKS 儲存庫上的 GitHub 端對端加密中提供範例應用程式和程式碼，以顯示微型服務如何在 Amazon EKS 上使用end-to-end加密來執行。 End-to-end 模式的方法使用 cert-manager，這是 Kubernetes 的附加元件，並以 Let's Encrypt 做為憑證授權單位 (CA)。Let's Encrypt 是一種經濟實惠的解決方案，可用來管理憑證，並提供 90 天內有效的免費憑證。在 Amazon EKS 上部署新的微服務時，Cert-manager 會自動進行隨需佈建和輪換憑證。 

目標對象

具有 Kubernetes、TLS、Amazon Route 53 和網域名稱系統 (DNS) 經驗的使用者，建議使用此模式。

先決條件和限制

先決條件

• 作用中的 AWS 帳戶

• 現有 Amazon EKS 叢集。

• AWS Command Line Interface (AWS CLI) 1.7 版或更新版本，在 macOS、Linux 或 Windows 上安裝和設定。

• kubectl 命令列公用程式，已安裝並設定為存取 Amazon EKS 叢集。如需詳細資訊，請參閱《Amazon EKS 文件》中的安裝 kubectl。

• 用來測試應用程式的現有 DNS 名稱。如需詳細資訊，請參閱《Amazon Route 53 文件》中的使用 Amazon Route 53 註冊網域名稱。 Amazon Route 53  

• 安裝在本機電腦上的最新 Helm 版本。如需詳細資訊，請參閱 Amazon EKS 文件和 GitHub Helm 儲存庫中的搭配使用 Helm 與 Amazon EKS。 GitHub  

• Amazon EKS 儲存庫上的 GitHub 端對端加密，複製到您的本機機器。 End-to-end  

• 取代 中的下列值，policy.json以及來自 Amazon EKS 儲存庫上複製之 GitHub 端對端加密trustpolicy.json的檔案： End-to-end

  • <account number> – 將 取代為您要部署解決方案之帳戶的 AWS 帳戶 ID。 

  • <zone id> – 將 取代為網域名稱的 Route 53 區域 ID。 

  • <node_group_role> – 將 取代為與 Amazon EKS 節點相關聯的 AWS Identity and Access Management (IAM) 角色名稱。

  • <namespace> – 將 取代為您部署 NGINX 輸入控制器和範例應用程式的 Kubernetes 命名空間。

  • <application-domain-name> – 將 取代為 Route 53 的 DNS 網域名稱。

限制

• 此模式不會說明如何輪換憑證，而只會示範如何在 Amazon EKS 上使用憑證與微服務。 

架構

下圖顯示此模式的工作流程和架構元件。

該圖顯示以下工作流程：

1. 用戶端傳送存取應用程式至 DNS 名稱的請求。

2. Route 53 記錄是 Network Load Balancer 的 CNAME。

3. Network Load Balancer 會將請求轉送至使用 TLS 接聽程式設定的 NGINX 輸入控制器。NGINX 輸入控制器與 Network Load Balancer 之間的通訊遵循 HTTPS 通訊協定。

4. NGINX 輸入控制器會根據用戶端對應用程式服務的請求執行路徑型路由。

5. 應用程式服務會將請求轉送至應用程式 Pod。應用程式旨在透過呼叫秘密來使用相同的憑證。

6. Pod 會使用 cert-manager 憑證執行範例應用程式。NGINX 輸入控制器與 Pod 之間的通訊使用 HTTPS。

注意 Cert-manager 會在自己的命名空間中執行。它使用 Kubernetes 叢集角色將憑證佈建為特定命名空間中的秘密。您可以將這些命名空間連接至應用程式 Pod 和 NGINX 輸入控制器。

工具

AWS 服務

• Amazon Elastic Kubernetes Service (Amazon EKS) 是一種受管服務，可讓您在 AWS 上執行 Kubernetes，而不需要安裝、操作和維護您自己的 Kubernetes 控制平面或節點。

• Elastic Load Balancing 會自動將傳入的流量分散到多個目標、容器和 IP 地址。

• AWS Identity and Access Management (IAM) 可透過控制已驗證並獲授權使用的人員，協助您安全地管理對 AWS 資源的存取。

• Amazon Route 53 是一種可用性高、可擴展性強的 DNS Web 服務。

其他工具

• cert-manager 是 Kubernetes 的附加元件，可請求憑證、將憑證分發至 Kubernetes 容器，以及自動化憑證續約。

• NGINX 輸入控制器是 Kubernetes 和容器化環境中雲端原生應用程式的流量管理解決方案。

史詩

使用 Route 53 建立和設定公有託管區域

任務	描述	所需的技能
在 Route 53 中建立公有託管區域。	登入 AWS 管理主控台，開啟 Amazon Route 53 主控台，選擇託管區域，然後選擇建立託管區域。建立公有託管區域並記錄區域 ID。如需詳細資訊，請參閱《Amazon Route 53 文件》中的建立公有託管區域。 注意 ACME DNS01 使用 DNS 提供者發佈挑戰，讓 cert-manager 發出憑證。此挑戰要求您證明，在 TXT 記錄中該網域名稱下放置特定值，以控制網域名稱的 DNS。在 Let’s Encrypt 為您的 ACME 用戶端提供字符之後，您的用戶端會建立衍生自該字符和您帳戶金鑰的 TXT 記錄，並將該記錄放在 _acme-challenge.<YOURDOMAIN>。然後，讓我們加密查詢該記錄的 DNS。如果找到相符項目，您可以繼續發出憑證。	AWS DevOps

使用 Route 53 建立和設定公有託管區域

任務	描述	所需的技能
在 Route 53 中建立公有託管區域。	登入 AWS 管理主控台，開啟 Amazon Route 53 主控台，選擇託管區域，然後選擇建立託管區域。建立公有託管區域並記錄區域 ID。如需詳細資訊，請參閱《Amazon Route 53 文件》中的建立公有託管區域。 注意 ACME DNS01 使用 DNS 提供者發佈挑戰，讓 cert-manager 發出憑證。此挑戰要求您證明，在 TXT 記錄中該網域名稱下放置特定值，以控制網域名稱的 DNS。在 Let’s Encrypt 為您的 ACME 用戶端提供字符之後，您的用戶端會建立衍生自該字符和您帳戶金鑰的 TXT 記錄，並將該記錄放在 _acme-challenge.<YOURDOMAIN>。然後，讓我們加密查詢該記錄的 DNS。如果找到相符項目，您可以繼續發出憑證。	AWS DevOps

設定 IAM 角色以允許 cert-manager 存取公有託管區域

任務	描述	所需的技能
建立 cert-manager 的 IAM 政策。	需要 IAM 政策才能提供 cert-manager 許可，以驗證您擁有 Route 53 網域。policy.json 範例 IAM 政策會在複製的 GitHub End-to-end加密的1-IAMRole目錄中提供。 在 AWS CLI 中輸入下列命令來建立 IAM 政策。 aws iam create-policy \ --policy-name PolicyForCertManager \ --policy-document file://policy.json	AWS DevOps
建立 cert-manager 的 IAM 角色。	建立 IAM 政策後，您必須建立 IAM 角色。trustpolicy.json 範例 IAM 角色提供於 1-IAMRole目錄中。 在 AWS CLI 中輸入下列命令來建立 IAM 角色。 aws iam create-role \ --role-name RoleForCertManager \ --assume-role-policy-document file://trustpolicy.json	AWS DevOps
將政策連接到角色。	在 AWS CLI 中輸入下列命令，將 IAM 政策連接至 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

設定 IAM 角色以允許 cert-manager 存取公有託管區域

任務	描述	所需的技能
建立 cert-manager 的 IAM 政策。	需要 IAM 政策才能提供 cert-manager 許可，以驗證您擁有 Route 53 網域。policy.json 範例 IAM 政策會在複製的 GitHub End-to-end加密的1-IAMRole目錄中提供。 在 AWS CLI 中輸入下列命令來建立 IAM 政策。 aws iam create-policy \ --policy-name PolicyForCertManager \ --policy-document file://policy.json	AWS DevOps
建立 cert-manager 的 IAM 角色。	建立 IAM 政策後，您必須建立 IAM 角色。trustpolicy.json 範例 IAM 角色提供於 1-IAMRole目錄中。 在 AWS CLI 中輸入下列命令來建立 IAM 角色。 aws iam create-role \ --role-name RoleForCertManager \ --assume-role-policy-document file://trustpolicy.json	AWS DevOps
將政策連接到角色。	在 AWS CLI 中輸入下列命令，將 IAM 政策連接至 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

在 Amazon EKS 中設定 NGINX 輸入控制器

任務	描述	所需的技能
部署 NGINX 傳入控制器。	nginx-ingress 使用 Helm 安裝最新版本的 。您可以在部署之前，根據您的需求修改nginx-ingress組態。此模式使用註釋的面向內部的 Network Load Balancer，該模式可在 5-Nginx-Ingress-Controller目錄中使用。  從 5-Nginx-Ingress-Controller目錄執行下列 Helm 命令，安裝 NGINX 輸入控制器。 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 輸入控制器建立的 Network Load Balancer。 取得 Network Load Balancer 的 DNS 名稱。如需說明，請參閱取得 ELB 負載平衡器的 DNS 名稱。 在 Amazon Route 53 主控台上，選擇託管區域。 選取您要在其中建立記錄的公有託管區域，然後選擇建立記錄。 輸入記錄的名稱。  在記錄類型中，選擇 A - 將流量路由到 IPv4 和一些 AWS 資源。   啟用別名。 在路由流量目的地中，執行下列動作： 選擇別名至 Network Load Balancer。 選擇部署 Network Load Balancer 的 AWS 區域。 輸入 Network Load Balancer 的 DNS 名稱。 選擇建立記錄。	AWS DevOps

在 Amazon EKS 中設定 NGINX 輸入控制器

任務	描述	所需的技能
部署 NGINX 傳入控制器。	nginx-ingress 使用 Helm 安裝最新版本的 。您可以在部署之前，根據您的需求修改nginx-ingress組態。此模式使用註釋的面向內部的 Network Load Balancer，該模式可在 5-Nginx-Ingress-Controller目錄中使用。  從 5-Nginx-Ingress-Controller目錄執行下列 Helm 命令，安裝 NGINX 輸入控制器。 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 輸入控制器建立的 Network Load Balancer。 取得 Network Load Balancer 的 DNS 名稱。如需說明，請參閱取得 ELB 負載平衡器的 DNS 名稱。 在 Amazon Route 53 主控台上，選擇託管區域。 選取您要在其中建立記錄的公有託管區域，然後選擇建立記錄。 輸入記錄的名稱。  在記錄類型中，選擇 A - 將流量路由到 IPv4 和一些 AWS 資源。   啟用別名。 在路由流量目的地中，執行下列動作： 選擇別名至 Network Load Balancer。 選擇部署 Network Load Balancer 的 AWS 區域。 輸入 Network Load Balancer 的 DNS 名稱。 選擇建立記錄。	AWS DevOps

在 Amazon EKS 上設定 NGINX VirtualServer

任務	描述	所需的技能
部署 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
驗證應用程式。	將 取代<application-domain-name>為您先前建立的 Route53 DNS 名稱，以輸入下列命令。 curl --verbose https://<application-domain-name> 確認您可以存取應用程式。	AWS DevOps

在 Amazon EKS 上設定 NGINX VirtualServer

任務	描述	所需的技能
部署 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
驗證應用程式。	將 取代<application-domain-name>為您先前建立的 Route53 DNS 名稱，以輸入下列命令。 curl --verbose https://<application-domain-name> 確認您可以存取應用程式。	AWS DevOps

相關資源

AWS 資源

• 使用 Amazon Route 53 主控台建立記錄 (Amazon Route 53 文件）

• 在 Amazon EKS 上使用 Network Load Balancer 搭配 NGINX 輸入控制器 (AWS 部落格文章）

其他資源

• Route 53 (cert-manager 文件）

• 設定 DNS01 挑戰提供者 (cert-manager 文件）

• 讓我們加密 DNS 挑戰 （讓我們的加密文件）