인증서 관리자 및 Let's EKS Encrypt를 사용하여 Amazon에서 애플리케이션에 대한 end-to-end 암호화를 설정합니다. - AWS 권장 가이드
요약사전 조건 및 제한 사항아키텍처도구에픽관련 리소스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

인증서 관리자 및 Let's EKS Encrypt를 사용하여 Amazon에서 애플리케이션에 대한 end-to-end 암호화를 설정합니다.

작성자: 마헨드라 레바나시다파 () 와 바산스 제야라즈 () AWS AWS

코드 리포지토리: Amazon의 E nd-to-end 암호화 EKS

환경: PoC 또는 파일럿

기술: DevOps; 컨테이너 및 마이크로서비스, 보안, ID, 규정 준수

워크로드: 기타 모든 워크로드

AWS서비스: 아마존EKS, 아마존 Route 53

요약

end-to-end 암호화를 구현하는 것은 복잡할 수 있으며 마이크로서비스 아키텍처의 각 자산에 대한 인증서를 관리해야 합니다. Network Load Balancer 또는 Amazon API Gateway를 사용하여 Amazon Web Services (AWS) 네트워크 에지에서 전송 계층 보안 () 연결을 종료할 수 있지만 일부 조직에서는 암호화가 필요합니다 end-to-end . TLS

이 패턴은 NGINX 인그레스 컨트롤러를 인그레스에 사용합니다. Kubernetes 인그레스를 생성할 때 인그레스 리소스가 Network Load Balancer를 사용하기 때문입니다. Network Load Balancer는 클라이언트 인증서 업로드를 허용하지 않습니다. 따라서 쿠버네티스 인그레스와는 TLS 상호 작용을 이룰 수 없습니다.

이 패턴은 애플리케이션의 모든 마이크로서비스 간에 상호 인증이 필요한 조직을 위한 것입니다. 뮤추얼은 사용자 이름이나 비밀번호를 관리하는 부담을 TLS 줄이고 턴키 보안 프레임워크를 사용할 수도 있습니다. 이 패턴의 접근 방식은 조직에 연결된 디바이스 수가 많거나 엄격한 보안 지침을 준수해야 하는 경우에 적합합니다.

이 패턴은 Amazon Elastic Kubernetes Service (Amazon) 에서 실행되는 애플리케이션에 대한 end-to-end 암호화를 구현하여 조직의 보안 태세를 강화하는 데 도움이 됩니다. EKS 이 패턴은 Amazon EKS 리포지토리의 GitHub E nd-to-end 암호화 샘플 애플리케이션과 코드를 제공하여 Amazon에서 end-to-end 암호화를 사용하여 마이크로 서비스가 실행되는 방식을 보여줍니다. EKS 이 패턴의 접근 방식은 Let's Encrypt를 인증 기관(CA)으로 사용하는 Kubernetes의 추가 기능인 cert-manager를 사용합니다. Let's Encrypt는 인증서 관리를 위한 비용 효율적인 솔루션으로 90일 동안 유효한 무료 인증서를 제공합니다. Cert-manager는 새 마이크로서비스가 Amazon에 배포될 때 온디맨드 프로비저닝 및 인증서 교체를 자동화합니다. EKS  

수강 대상

이 패턴은 쿠버네티스TLS, Amazon Route 53 및 도메인 이름 시스템 () 을 사용해 본 경험이 있는 사용자에게 권장됩니다. DNS

사전 조건 및 제한 사항

사전 조건 

  • 활성 상태의 AWS 계정.

  • 기존 아마존 EKS 클러스터.

  • AWS명령줄 인터페이스 (AWSCLI) 버전 1.7 이상, macOS, Linux 또는 Windows에서 설치 및 구성됨

  • Amazon EKS 클러스터에 액세스하도록 설치 및 구성된 kubectl 명령줄 유틸리티. 이에 대한 자세한 내용은 Amazon EKS설명서의 kubectl 설치를 참조하십시오.

  • 애플리케이션을 테스트하기 위한 기존 DNS 이름. 이에 대한 자세한 내용은 Amazon Route 53 설명서의 Amazon Route 53을 사용하여 도메인 이름 등록을 참조하세요. 

  • 로컬 컴퓨터에 설치된 Helm 최신 버전. 이에 대한 자세한 내용은 Amazon EKS 설명서 및 Helm EKS 리포지토리의 Amazon에서 GitHub Helm 사용하기 섹션을 참조하십시오. 

  • Amazon EKS 리포지토리의 GitHub E nd-to-end 암호화는 로컬 시스템에 복제됩니다. 

  • Amazon EKS 리포지토리의 복제된 GitHub E nd-to-end 암호화에 있는 policy.json 및 trustpolicy.json 파일의 다음 값을 대체하십시오.

    • <account number>— 솔루션을 배포하려는 계정의 AWS 계정 ID로 대체하십시오. 

    • <zone id>-도메인 이름의 Route 53 영역 ID로 바꿉니다. 

    • <node_group_role>— Amazon EKS 노드와 관련된 AWS Identity 및 Access Management (IAM) 역할의 이름으로 대체하십시오.

    • <namespace>— NGINX 인그레스 컨트롤러와 샘플 애플리케이션을 배포하는 Kubernetes 네임스페이스로 대체하십시오.

    • <application-domain-name>— Route 53의 DNS 도메인 이름으로 대체합니다.

제한 사항

  • 이 패턴은 인증서를 교체하는 방법을 설명하지 않으며 Amazon의 마이크로서비스에서 인증서를 사용하는 방법만 보여줍니다. EKS  

아키텍처

다음 다이어그램은 이 패턴의 워크플로 및 구성 요소를 보여 줍니다.

인증서 관리자 및 Let's EKS Encrypt를 사용하여 Amazon에서 애플리케이션에 대한 암호화를 설정하는 워크플로입니다.

이 다이어그램은 다음 워크플로를 보여줍니다.

  1. 클라이언트가 해당 이름으로 애플리케이션에 액세스하라는 요청을 보냅니다. DNS

  2. Route 53 레코드는 CNAME 네트워크 로드 밸런서의 a입니다.

  3. Network Load Balancer는 리스너로 구성된 NGINX 인그레스 컨트롤러에 요청을 전달합니다. TLS NGINX인그레스 컨트롤러와 Network Load Balancer HTTPS 간의 통신은 프로토콜을 따릅니다.

  4. NGINX인그레스 컨트롤러는 애플리케이션 서비스에 대한 클라이언트의 요청을 기반으로 경로 기반 라우팅을 수행합니다.

  5. 애플리케이션 서비스는 애플리케이션 포드로 요청을 전달합니다. 애플리케이션은 보안 암호를 호출하여 동일한 인증서를 사용하도록 설계되었습니다.

  6. 포드는 cert-manager 인증서를 사용하여 샘플 애플리케이션을 실행합니다. NGINX인그레스 컨트롤러와 포드 간의 통신은 다음을 사용합니다. HTTPS

참고: Cert-manager는 자체 네임스페이스에서 실행됩니다. Kubernetes 클러스터 역할을 사용하여 인증서를 특정 네임스페이스에 보안 암호로 프로비저닝합니다. 이러한 네임스페이스를 애플리케이션 포드 및 인그레스 컨트롤러에 연결할 수 있습니다. NGINX

도구

AWS서비스

  • Amazon Elastic Kubernetes Service (EKSAmazon) 는 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치, 운영 및 유지 관리할 필요 없이 AWS 쿠버네티스를 실행하는 데 사용할 수 있는 관리형 서비스입니다.

  • Elastic Load Balancing은 여러 대상, 컨테이너 및 IP 주소에 걸쳐 수신되는 트래픽을 자동으로 분산합니다.

  • AWSIdentity and Access Management (IAM) 를 사용하면 리소스 인증 및 사용 권한을 부여받은 사용자를 제어하여 AWS 리소스에 대한 액세스를 안전하게 관리할 수 있습니다.

  • Amazon Route 53은 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.

기타 도구

  • cert-manager는 인증서를 요청하고 Kubernetes 컨테이너에 배포하며 인증서 갱신을 자동화하는 Kubernetes의 추가 기능입니다.

  • NGINXIngress Controller는 쿠버네티스 및 컨테이너식 환경의 클라우드 네이티브 앱을 위한 트래픽 관리 솔루션입니다.

에픽

작업설명필요한 기술

Route 53에서 퍼블릭 호스팅 영역을 생성합니다.

AWS관리 콘솔에 로그인하고 Amazon Route 53 콘솔을 열고 호스팅 영역을 선택한 다음 호스팅 영역 생성을 선택합니다. 퍼블릭 호스팅 영역을 생성하고 영역 ID를 기록합니다. 이에 대한 자세한 내용은 Amazon Route 53 설명서의 퍼블릭 호스팅 영역 생성을 참조하세요.

참고: ACME DNS 01은 DNS 공급자를 통해 cert-manager가 인증서를 발급하도록 이의를 제기합니다. 이 챌린지는 해당 도메인 이름 아래의 TXT 레코드에 특정 값을 입력하여 도메인 이름을 제어할 수 있음을 증명하도록 요청합니다. DNS Let's Encrypt가 ACME 클라이언트에게 토큰을 제공한 후 클라이언트는 해당 토큰과 계정 키에서 파생된 TXT 레코드를 생성하여 해당 레코드를 저장합니다. _acme-challenge.<YOURDOMAIN> 그러면 Let's Encrypt가 해당 레코드를 쿼리합니다DNS. 일치하는 항목을 찾으면 인증서 발급을 진행할 수 있습니다.

AWS DevOps
작업설명필요한 기술

cert-manager에 대한 IAM 정책을 생성합니다.

Route 53 도메인을 소유하고 있는지 확인할 수 있는 권한을 인증서 관리자에게 제공하려면 IAM 정책이 필요합니다. policy.json샘플 IAM 정책은 Amazon EKS 리포지토리의 복제된 GitHub E nd-to-end 암호화 1-IAMRole 디렉터리에 제공됩니다.

다음 명령을 AWS CLI 입력하여 IAM 정책을 생성합니다.

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

인증서 관리자의 IAM 역할을 생성합니다.

IAM정책을 생성한 후에는 역할을 IAM 생성해야 합니다. trustpolicy.json샘플 IAM 역할은 1-IAMRole 디렉터리에 제공됩니다.

에 다음 명령을 입력하여 IAM 역할을 생성합니다. AWS CLI 

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

책을 역할에 연결합니다.

IAM정책을 IAM 역할에 AWS CLI 연결하려면 다음 명령을 입력합니다. AWS계정의 AWS_ACCOUNT_ID 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 구성을 수정할 수 있습니다. 이 패턴은 주석이 달린 내부 Network Load Balancer를 사용하며 이를 5-Nginx-Ingress-Controller 디렉터리에서 사용할 수 있습니다. 

디렉터리에서 다음 Helm 명령을 실행하여 NGINX 인그레스 컨트롤러를 설치합니다. 5-Nginx-Ingress-Controller

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. 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 파일에서 사용할 수 있습니다. 에 다음 명령을 입력하여 NGINX VirtualServer 리소스를 생성합니다. kubectl

kubectl apply -f  nginx_virtualserver.yaml

중요: nginx_virtualserver.yaml 파일에서 애플리케이션 도메인 이름, 인증서 보안 암호 및 애플리케이션 서비스 이름을 업데이트해야 합니다.

AWS DevOps

NGINX VirtualServer 생성되었는지 확인하십시오.

다음 명령을 kubectl 입력하여 NGINX VirtualServer 리소스가 성공적으로 생성되었는지 확인합니다.

kubectl get virtualserver

참고: Host 열이 애플리케이션의 도메인 이름과 일치하는지 확인하세요.

AWS DevOps

TLS활성화된 상태로 NGINX 웹 서버를 배포합니다.

이 패턴은 TLS 활성화된 NGINX 웹 서버를 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리소스

기타 리소스