EKS使用證書管理器和讓我們 end-to-end 加密為 Amazon 上的應用程序設置加密 - AWS 方案指引
Summary先決條件和限制架構工具史诗相關資源

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

EKS使用證書管理器和讓我們 end-to-end 加密為 Amazon 上的應用程序設置加密

創建者：馬亨德拉·雷瓦納西達帕 () 和瓦桑斯傑拉伊 () AWS AWS

代碼存儲庫：Amazon 上的 E nd-to-end 加密 EKS

環境：PoC 或試點

技術： DevOps；容器與微服務；安全性、身分識別、合規性

工作負載：所有其他工作

AWS服務：AmazonEKS; Amazon Route 53

Summary

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

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

此模式適用於需要應用程式中所有微服務之間相互驗證的組織。相互TLS減輕了維護用戶名或密碼的負擔，並且還可以使用交鑰匙安全框架。如果您的組織有大量連接的設備或必須遵守嚴格的安全性準則，則此模式的方法是兼容的。

此模式透過在 Amazon 彈性 Kubernetes 服務 (亞馬遜) 上執行的應用程式實施 end-to-end 加密，有助於提高組織的安全狀態。EKS此模式在 Amazon EKS 儲存庫的 GitHub E nd-to-end 加密中提供範例應用程式和程式碼，以顯示微服務如何在 Amazon EKS 上以 end-to-end 加密方式執行。該模式的方法使用證書管理器，這是 Kubernetes 的附加組件，並將「讓我們加密」作為證書頒發機構（CA）。Let's Encrypt 是一種經濟高效的解決方案，用於管理證書並提供有效期為 90 天的免費證書。在 Amazon 上部署新的微服務時，CERT-Manager 會自動執行憑證的隨選佈建和輪換。EKS 

目標受眾

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

先決條件和限制

先決條件

  • 作用中的 AWS 帳戶。

  • 現有的 Amazon EKS 叢集。

  • AWS命令列介面 (AWSCLI) 1.7 版或更新版本，已在 macOS、Linux 或視窗上安裝及設定。

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

  • 測試應用程式的現有DNS名稱。有關這方面的更多信息，請參閱 Amazon Route 53 文檔中的使用 Amazon Route 53 註冊域名。 

  • 最新的 Helm 版本，安裝在您的本地計算機上。有關此詳情，請參閱 Amazon EKS 文檔EKS中的將 Helm 與 Amazon 搭配使用和 GitHub Helm 存儲庫。 

  • Amazon EKS 存儲庫上的 GitHub E nd-to-end 加密，克隆到您的本地機器。 

  • 從 Amazon EKS 儲存庫上複製的 GitHub E nd-to-end 加密取代policy.json和trustpolicy.json檔案中的下列值：

    • <account number>— 取代為您要在其中部署解決方案之帳戶的帳戶 ID。AWS 

    • <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 上搭配微型服務使用憑證。 

架構

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

EKS使用憑證管理員和讓我們加密為 Amazon 上的應用程式設定加密的工作流程。

該圖顯示以下工作流程：

  1. 客戶端發送一個請求來訪問應用程序的DNS名稱。

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

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

  4. NGINXIngress 控制器會根據用戶端對應用程式服務的要求執行路由。

  5. 應用程式服務會將要求轉送至應用程式網繭。該應用程序旨在通過調用密碼來使用相同的證書。

  6. 網繭會使用憑證管理員憑證執行範例應用程式。NGINX入口控制器與網繭之間的通訊使用HTTPS。

注意：CERT-管理員會在自己的命名空間中執行。它使用 Kubernetes 叢集角色，在特定命名空間中將憑證佈建為密碼。您可以將這些命名空間附加到應用程式網繭和NGINX入口控制器。

工具

AWS服務

其他工具

  • 憑證管理員是 Kubernetes 的附加元件，可要求憑證、將憑證散佈至 Kubernetes 容器，並自動執行憑證續約。

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

史诗

任務描述所需技能

在 Route 53 中創建一個公共託管區域。

登入AWS管理主控台，開啟 Amazon Route 53 主控台，選擇託管區域，然後選擇 [建立託管區域]。建立公用託管區域並記錄區域 ID。如需這方面的詳細資訊，請參閱 Amazon Route 53 說明文件中的建立公用託管區域。

注意：ACMEDNS01 使用提DNS供程序發布證書管理器發出證書的挑戰。此挑戰要求您通過在該域名下的TXT記錄中輸入特定值來證明您DNS對域名的控制權。在 Let's Encrypt 為您的ACME客戶提供令牌後，您的客戶端會創建一個從該令牌和您的帳戶密鑰派生的記TXT錄，並將該記錄放在該記錄中_acme-challenge.<YOURDOMAIN>。然後讓我們加密查DNS詢該記錄。如果找到相符項目，您可以繼續發行憑證。

AWS DevOps
任務描述所需技能

建立憑證管理員的IAM原則。

需要IAM政策才能向憑證管理員提供驗證您是否擁有 Route 53 網域的權限。policy.json範例IAM政策在 Amazon EKS 儲存庫上複製的 GitHub E nd-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

將政策連接到角色。

在中輸入下列指令，AWSCLI將原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
任務描述所需技能

部署入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。

  1. 取得 Network Load Balancer 的DNS名稱。如需指示，請參閱取得ELB負載平衡器的DNS名稱。

  2. 在 Amazon Route 53 主控台上，選擇託管區域。

  3. 選取您要在其中建立記錄的公用託管區域，然後選擇 [建立記錄]。

  4. 輸入記錄的名稱。 

  5. 在 [記錄類型] 中，選擇 [A]-將流量路由至IPv4及部分AWS資源。  

  6. 啟用別名。

  7. 在將流量路由至中，執行下列操作：

    1. 選擇 Network Load Balancer 的別名。

    2. 選擇AWS部署 Network Load Balancer 的區域。

    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

    注意：網繭應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資源

其他資源